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

[Eli Zaretskii]

> From: David Engster <address@hidden>
> Cc: address@hidden
> Date: Wed, 17 Dec 2014 21:37:06 +0100
> 
> >> 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.

> What kind of information do you mean here? I'm guessing you want to see
> the merges from master and how you reacted to them?

Yes, that's right.

> Therefore, I think a purely merge-based workflow is really the only
> option for you, which however brings us to
> 
> . You want to keep a clear history of 'mainline', meaning you want to
>   achieve a similar log view to that from Bazaar, using 'git log
>   --first-parent'.
> 
> This conflicts with how Git orders the parents of a merge. The first
> parent is always the tip of the branch you're currently on. And since
> you do 'git pull' while being on your local master, that will be the
> first parent. 
> 
> I happen to dislike that about Git as well, but I agree with Stefan that
> this is not something we should worry about. Probably the easiest way
> without resorting to rebase you've already said yourself: delete the
> merge, do a fast-forward pull, merge again.

But if we follow Stefan and stop worrying about the linearity of
mainline, then just "git pull" followed by another push is enough,
right?

> Of course, while *you* can take care in keeping the correct ordering of
> mainline, others won't do that (I guess most are not even aware of this
> issue), so I'm afraid you will be greeted with git's usual spaghetti
> history soon enough.

Again, if we don't care about the mainline being linear, this
spaghetti is nothing to worry about, right?  It's just a "normal" Git
DAG, right?

What really worries me about all this is that I _know_ some of the
more-or-less veteran contributors do have long-living branches, where
they do all their work, and from where they merge to master before
pushing.  For those people, using "pull --rebase" might be trouble
waiting to happen at the most inopportune moment.