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

[Eli Zaretskii]

Thanks for taking the time to explain and make suggestions.

> From: David Engster <address@hidden>
> Cc: address@hidden
> Date: Mon, 15 Dec 2014 21:39:58 +0100
> 
> >     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.

Sorry, I don't understand: doesn't origin/master have the same commits
as master (modulo the local commits I did on master since the last
pull)?  If so, how would merging origin/master help me?

Once again, the problem is in this situation:

 . My work on a feature branch is almost finished, so I merge from
   master to make sure my feature doesn't break anything and isn't
   broken by development on master.

 . I then merge from the feature branch to master and attempt to push,
   but the push is rejected.

 . I then pull --rebase=preserve and push again

It's the last step that causes trouble, and the "trouble" here is that
commits I merged from master before merging back might be merged again
in the future, if I need for some reason to continue working on that
feature branch again.

Where will origin/master help in this situation?

> But actually, instead of merging master into your feature
> branch, I'd rather recommend rebasing it *onto* master, but explicitly

That'd lose too much information, so I'd like to avoid that if
possible.  It might also cause complications if I have more than 1
active feature branch, and want to compare or merge between them.  It
is also a bad idea when the branch is a public one, as you point out.

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

If "merge --no-ff" and aborting the merge when a push is rejected are
to be used anyway, why do I need to rebase the feature branch onto
master?  That doesn't seem necessary.  I could use normal merges, no?

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

I would like to have the same workflow for both local branches and
public ones, such as emacs-24, if at all possible.  That will relieve
the "memory pressure" and reduce the probability of errors.

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

I actually don't mind merge commits, as long as they reflect what was
actually done, as opposed to being generated by Git out of thin air.

What I certainly want to avoid is any kind of rebasing, cherry-picking
or similar things that will then put me at risk of having the same
commits merged again, because the original commits are rewritten or
not recorded in the DAG.