On Sat, Aug 26, 2017 at 12:37:55PM +0200, Marc Haber wrote: > Hi, > > whenever I think that I have finally understood how merging and rebasing > in git works, something happens and I am confused as before. > > The git history (obtained with git log --graph --oneline --decorate > --all) pasted below shows a git repository containing my ssh > configuration, with a master branch that is shared between machines, and > a local branch, fan, containing changes that are needed to use ssh on > fan. Althouth both branches have diverged at the bottom of the history, > the entire diff is tiny. > > 128 [4/4984]mh@fan:~ $ git diff master..fan | diffstat > head/00_dist_defaults | 1 + > mh/5_dist_swivel | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > [5/4985]mh@fan:~ $ > > 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. [...]
Isn't this the case covered by this bit from the git-merge(1) manual page? | With the strategies that use 3-way merge (including the default, recursive), | if a change is made on both branches, but later reverted on one of the | branches, that change will be present in the merged result; some people | find this behavior confusing. It occurs because only the heads and the merge | base are considered when performing a merge, not the individual commits. | The merge algorithm therefore considers the reverted change | as no change at all, and substitutes the changed version instead. I don't have a clear idea of how to deal with this properly. 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. You could also try exploring whether "ours" or "theirs" modifiers to the merge strategy would do what yo're after, like with $ git merge -s recursive -X ours ... -- 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.
