Re: master c6f03ed: Fix a problem in url.el without GnuTLS

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <address@hidden>
>> Date: Sat, 13 Dec 2014 15:13:25 +0100
>> 
>> Never rebase commits that are upstream. Rebasing will always create new
>> commits (in case if you wondering, 'pull --rebase=preserve' doesn't
>> change that; it will keep a merge commit, but that will not merge
>> origin/emacs-24 anymore but a new set of commits).
>
> English, please: what does that mean?

When you rebase a commit, it becomes a new one. Therefore, you can only
safely rebase "local" commits (meaning: commits only *you* have).

> The documentation seems to suggest that "pull --rebase=preserve" is
> exactly the right thing in this situation.

The name "preserve" is misleading. It does not mean that you have the
same merge after the rebase. That's not possible, since the commits
change during this operation.

It helps to think of a rebase simply as a series of cherry-picks. Any
conflicts you resolved in a merge commit are now resolved commit by
commit. If you do 'rebase=preserve', what git does is: it tries to
re-create(!)  the merge commit with the rebased commits afterwards. This
merge commit is pure metadata now, since there are no conflicts to
resolve.

So practically, 'rebase=preserve' is only meant for *unpushed* local
branches you have merged, and you want to keep the metadata of this
local merge.

>> Instead, simply merge master into your tree. Despite what others may
>> say, this is still a perfectly valid thing to do in Git. :-) This what
>> 'git pull' will do by default (unless you configured it otherwise).
>
> Yes, but then my commits will appear as merge-commits, won't they?

Not sure what you mean. This is equivalent to the merge-based workflow
we had with Bazaar.

-David