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

[Eli Zaretskii]

> From: David Engster <address@hidden>
> Cc: address@hidden
> 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?

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

I didn't mean the name, I meant its documentation.  It says:

  locally committed merge commits will not be flattened by running
  'git pull'

"locally committed" seems to fit the scenario we are discussing, no?

> It does not mean that you have the same merge after the
> rebase. That's not possible, since the commits change during this
> operation.

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.

> 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.

Sorry, I still don't understand.  Which commits from what branches
does Git merge after 'rebase=preserve'?

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'?

> >> 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.

But I didn't work on a separate branch, I worked in master.
Therefore, I'd like to avoid merge-commits if possible, and I thought
using 'rebase=preserve' does that, and also lets me merge branches,
whether my local branches or the emacs-24 release branch.