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

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <address@hidden>
>> Cc: address@hidden
>> Date: Sun, 14 Dec 2014 22:40:41 +0100
>> >   . This is true for merges from local branches as well.  Therefore,
>> >     using this option is not advisable for local branches, because
>> >     doing that would mean trouble when I next merge from master into
>> >     my local branch -- I will get the same commits back again.
>> 
>> Do you mean you have a long-living local branch which you regularly
>> merge to master?
>
> No.  But when I work on a feature branch that takes weeks, sometimes
> months, to complete, I merge from master near the end of the
> development, to make sure landing the feature will not introduce
> regressions.  Sometimes there's more than one such merge, especially
> if I discover subtle issues as result of merging.

I see. I guess you could avoid those problems by merging origin/master
instead. But actually, instead of merging master into your feature
branch, I'd rather recommend rebasing it *onto* master, but explicitly
and not as a side effect of pull. I'm not a big fan of 'pull --rebase';
it works nice until it doesn't. As you've seen, this combination of
pull+rebase can lead to pretty surprising results, and the '=preserve'
simply changes what kind of surprise you're getting.

For local feature branches, I would recommend the following (not saying
this is "the right way" or anything, but maybe you find something useful
in there):

- Instead of merging master into my feature branch, I rebase it
  explicitly by doing

  git checkout featurebranch
  git rebase master

- I only merge feature branches into master when they are finished and I
  plan to push directly afterwards.

- Before merging to master, I rebase onto it one last time so that the
  merge has no conflicts, then I merge with '--no-ff' and push.

- If the push fails because there are new commits upstream, instead of
  using 'pull --rebase=preserve', I rather delete the merge so that I
  get a "normal" fast-forward pull and merge again. If I'm really
  unlucky, this new commit from upstream causes a conflict now, in which
  case I usually just resolve it, simply hoping that the push will work
  next time.

Of course, for *public* branches like emacs-24, one must not use
'rebase' in any way but do a normal merge. If the push fails, do a
regular 'pull' so that the new commits are merged and push again.

>> Isn't flattening of the history precisely what you want when you have
>> merges of local branches, so that they appear like they were made on
>> master?
>
> No.  When development was on a branch, I generally want to preserve
> that branch in the history, not flatten it.  My commits on a feature
> branch follow some logic that is important to me (and documented in
> the commit log messages), so that long after the job is done these
> commits make it easier to understand why something was done the way it
> was, and also find the reasons for bugs or misfeatures.

I agree. I misunderstood your statement that your commits should not
look like they were made on another branch, but if I understand you
correctly now, you mean you don't want to have merge commits from master
before pushing, but you rather prefer to rebase (to which I agree as
well).

-David