Eli Zaretskii writes: >> From: David Engster >> Cc: emacs-devel@gnu.org >> Date: Sat, 13 Dec 2014 20:44:18 +0100 >> >> When you rebase a commit, it becomes a new one. Therefore, you can only >> safely rebase "local" commits (meaning: commits only *you* have). > > If "safely" here means "while preserving the commit's sha1", then it's > quite obvious. But why would that matter in this scenario? And why > does that cause the merged versions appear as if they were not merged > at all, even when rebase=preserve was/is used? I think we really have to discuss this on an actual example. I've attached a small script which will create three directories underneath a directory called "MERGE_REBASE_TEST": 'upstream', 'ted' and 'eli'. There are two branches, 'master' and 'stable', which Ted sets up and pushes. I put some sleeps in there just so that the commits have different time stamps. Ted merges 'stable' into 'master', but does not push yet. Then Eli makes a new commit on 'master' and pushes. This is where the script ends. Now go to 'ted' and do 'gitk --all' to see the situation. If you try to push with 'git push origin master', then this will fail because there's this new commit from Eli. Now do 'git pull --rebase=preserve', and then again do 'gitk --all'. You'll see that the 'stable' branch was rebased onto 'origin/master'. This changed the SHA1 of those two commits on 'stable', as they now descend from a different parent. You *have* a merge, but it is *not* a merge from origin/stable, but from a new (unnamed) branch that was created by rebasing origin/stable. Simply delete the MERGE_REBASE_TEST directory and run the script again to try the alternatives for Ted. 'git pull --rebase' will do the same as '--rebase=preserve' but will simply drop the merge commit ("flatten the history"). Again, this will *not* merge the two commits from origin/stable (a 'git log stable ^master' will list all commits that are in stable but not in master). If you simply do 'git pull', this will merge origin/master into your tree. If you push this, everything will be OK. The above log command will show nothing, just as it should after a succesful merge. > I didn't say I want to have the same merge. All I want is to have > _some_ indication there was a merge from the other branch, including > when that branch is a public branch. You seem to say it's not > possible with Git. You can't at the same time move a branch onto a new parent (which is what rebase does) and then merge it, so that it looks like you've merged the original one which had another parent. > Sorry, I still don't understand. Which commits from what branches > does Git merge after 'rebase=preserve'? It merges the branch that is implicitly created by moving 'origin/emacs-24' to a newer parent. > And how do conflicts enter this picture? Suppose there were no > conflicts at all during the original merge -- would the merge still > disappear after 'rebase=preserve'? I guess it's better to forget conflicts. I was hoping it would make clearer how rebase works, but it just complicates things. -David