4

I am using git for a large legacy project which has two branches - v1.0 and v2.0. The source for each branch is very different in places, identical in others. When I make a bug fixes to the v1.0 branch I have to add them to the v2.0 branch using git cherry-pick as a git merge 1.0 would basically trash large parts of the v2.0 source.

However, new development has stopped on v1.0 and using git cherry-pick to copy fixes to the v2.0 branch is cumbersome. I would prefer to somehow be able to tell git that when I do a git merge from 1.0 -> 2.0 to only merge starting from a specific point in the 1.0 commit history (i.e. when new development stopped). Is this possible? It would allow me to make multiple fixes to the v1.0 source and merge the changes into v2.0 in one hit instead of using multiple cherry-picks.

Rob
  • 76,700
  • 56
  • 158
  • 197
  • But if the code from 2.0 is newer, then the code from 1.0 will never trash the newer code, right? – citizen conn Jul 21 '11 at 08:42
  • The problem is that both branches were actively developed at once and in the some areas the code is very different. This was before we moved to git. – Rob Jul 21 '11 at 09:24

1 Answers1

3

From 2.0 branch execute

git merge --strategy=ours v1.0

I didn't tested it myself so try it first on something not important, but from docs it is exactly what you need.

From documentation:

This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the recursive merge strategy.

Ivan Danilov
  • 14,287
  • 6
  • 48
  • 66
  • I don't think this is recommended anymore. There's an email from Linus Torvalds about that somewhere. – citizen conn Jul 21 '11 at 08:41
  • I'm curious why is that? From my understanding what this command does in terms of plumbing commands is just creating new commit in the current branch with one additional parent and same tree. Btw if there's really some problems with this command - manually executing such commands would be another solution. Somewhat cumbersome though. – Ivan Danilov Jul 21 '11 at 08:44
  • Your way probably works I just remember reading that there is now a better way. I just spent 10 mins looking for the manifest to no avail. – citizen conn Jul 21 '11 at 08:59
  • Well, if you find it finally - I'd be grateful if you send me a link :) – Ivan Danilov Jul 21 '11 at 09:00
  • @citizen: I know about criticism from Junio C. Hamano about the merge -s theirs (as mentioned in http://stackoverflow.com/q/1910444/6309), but not for the -s ours. – VonC Jul 21 '11 at 09:03
  • Hm. According to http://www.kernel.org/pub/software/scm/git/docs/git-merge.html there's only `merge -s recursive -X theirs`. `merge -s theirs` should be an error... – Ivan Danilov Jul 21 '11 at 09:06
  • For the sake of completeness. Post by Junio Hamano that you're referring to is here http://marc.info/?l=git&m=121637513604413&w=2 isn't it? – Ivan Danilov Jul 21 '11 at 09:14
  • Wow it must be late. Sorry for the confusion ... yeah that was the email. Not same situation though... git reset --hard is what I was thinking. But that would best assimilate theirs, not ours. – citizen conn Jul 21 '11 at 09:21
  • Fantastic. This is going to be a great help. – Rob Jul 21 '11 at 09:22
  • @Ivan: not sure if the "Post by Junio Hamano that you're referring to" was addressed to me (you didn't put any `@xxx` in your comment, meaning you notified nobody), but yes, it is the post I had in mind. – VonC Jul 28 '11 at 06:51