On Mon, Aug 28, 2017 at 12:28:57PM +0200, Marc Haber wrote: > > > But when I try to git rebase fan upon master, I get the same file that > > > is even in the diff between msater and fan over and over again. I guess > > > that git rebase goes back to commit 2357bcc where fan was branched off > > > master and tries to reapply all changes one by one, most of which have > > > been rolled back since then or have already been done in master. I have > > > merged msater into fan multiple times in the hope that this would make > > > rebasing possible again, but to no avail. [...] > > One way would be to merge with --no-commit then manually fixing up the > > results (by picking the correct contents for particular files using > > `git checkout`) and then staging the changes and comitting. > > Only the issue is that I don't want to merge, I want to rebase.
Sorry, I was in a hurry and misread your actual problem statement :-( For rebasing, one way to attack the problem is to "be explicit" about both the range of commits to rebase and the point to rebase them onto. You specify the range as usually -- by using the hash name of the immediate parent of the "bottom" commit in the range, and use the "--onto" command-line option to tell the rebase where you want to plant that range on. Another possibility is to identify which commit really make "fan" different from "master", reset "fan" to point to "master" and then cherry-pick those commits from the old state of "fan". Since you were about to rebase "fan" anyway, there's no problem with keeping the "fan" history untouched, I reckon. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
