1

Context: I have an experimental branch crazy-idea where I did some wild things in a dedicated sub-dir madness/{src,docs}. A ton of commits, with notes, pictures, hacky scripts to create plots. Now that I have fully understood what I'm doing it's time to edit the actual source files in src/ by adding new functions and alter existing ones.

Since the mess in crazy-idea would clutter the history of master, a new branch good-idea was created to merge the changes in src/ into master. Convince suggests that I alter the files in src/ still being in crazy-idea and then cherry-pick the commits from within good-idea.

Now my question: Given that good-idea was merged into master and some commits were done in master after this event. When I go back to crazy-idea to further iron out some other aspect of my idea, is there trouble to be expected in src/ while rebasing to master?

The alternative is to leave src/ within crazy-idea alone, make a copy of the sub-dir and look at my notes this way while coding directly in good-idea.

What do you guys suggest is smarter?

EDIT Well, as expected I got conflicts during 

git rebase master

in crazy-idea. In future I will introduce changes only in exactly one branch and use cherry-picking only when I know that it's more or less abandoned.

EDIT I solved my situation as follows: There have been N commits with changes in src/. Lets say the last non src/ changing commit had the message 'foobar'. After the rebase failed:

$ git rebase --abort
$ git reset --hard HEAD^
HEAD is now at ...
# more hard resets, I think actually N
HEAD is now at ... foobar
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying ..
...

Done. This evidently isn't as straight forward as I hoped, but not too bad either. I think I will go this route instead of copying madness/.

Maik Beckmann
  • 5,637
  • 1
  • 23
  • 18

1 Answers1

2

Git should not have very much trouble reconciling the cherry-picks. When rebasing, Git will ignore any commits (and even hunks within a commit's diff) that introduce change that has already been introduced on the target branch.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
  • Nice. My guess/hope was that git ignores where to commit comes from and just looks at the content when rebasing. Btw, have you actually used git the way I described or are you just confident that it will cope fine. – Maik Beckmann Aug 28 '11 at 18:28
  • I have done some pretty complicated rebases and I've seen it correctly drop whole commits that had already been integrated. – cdhowie Aug 28 '11 at 18:42
  • Sounds awesome. I will go ahead and mark your answer in a day or two if it worked out :P Thanks! – Maik Beckmann Aug 28 '11 at 18:45
  • Odd. For really complex branching/patching patterns it can have a bit of trouble reconciling things and you'll just have to fix the merge conflicts. – cdhowie Aug 31 '11 at 02:14