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

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <address@hidden>

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

Yes, that is always safe.

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

Yes.

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

Yes, although for local branches, really the worst that can happen is
that you merge rebased commits, leading to a duplication of those
commits in the history, which might be ugly and confusing, but it
actually does no "real" harm. I'm not sure, but I think Git detects that
those commits are identical through the patch-id, so you won't get
conflicts. Also, you can delete those duplicates with another
(interactive) rebase.

-David