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

[David Engster]

Stephen J. Turnbull writes:
> David Engster writes:
>
>  > up anew. If HEAD is your merge commit, this would mean doing
>  > 
>  >   git branch -D branchname
>  >   git branch branchname HEAD^2
>  > 
>  > (You have to delete with '-D', since Git won't see your non-rebased
>  > branch as merged...).
>
> Aside: can't you do this in one operation with "git branch -f
> branchname HEAD^2"?

Yes, thanks.

> (Real question, I don't understand your reference
> to "seeing ... branch as merged".  The docs seem to indicate it should
> work.)

I posted a script which will set up a few repositories where you can
test this:

  http://article.gmane.org/gmane.emacs.devel/180043

Simply enter the 'ted' repository, do 'git pull --rebase=preserve' and
then do 'git branch -d stable'. It won't work.

>  > 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 don't see a conflict here.  What I do see is an ambiguity in the
> discription of entry conditions.

I don't know what that means. But I can show you how it should *not*
look. Simply set up the above test repositories again, now go into
'ted' and do 'git pull', which will merge origin/master. Now do 'git log
--first-parent' and you'll see something like this:

82d09a7 Merge branch 'master' of MERGE_REBASE_TEST/upstream
0da1327 merge stable
1f487c9 second commit on master
106847b first commit on master

Note how the commit with subject "New commit on master" is not visible
anymore, although it was previously (go to 'eli' and type the same log
command there, then pull, do it again). AFAIU, this is what Eli wants to
avoid.

> To push to public:
>
>     git checkout master
>     git push                # public mainline is preserved
>     git checkout feature-1  # #### these three commands are error-prone
>
> AFAICS this is what you need to do for emacs-24, too.  The problems
> are (1) a convenient discipline for those last three commands and (2)
> recovery from failed push due to concurrent development.

(2) is the problem we are talking about.

>  > 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),
>
> All bzr fans are aware of it though.

There are not many. (FTR, I'm not actually seeing myself as a "bzr
fan". I do think however that the bad reputation it got around here was
undeserved.)

> It's an important part of Bazaar's identity in VCS space.  The problem
> will be git users who are used to a spaghetti DAG.

Yes, as I've written: "most are not aware of this issue". From my
experience, many Git users don't even recognize the problem (and when
they do, it's usually answered with 'just use gitk', which is kinda
sad).

>  > One could implement a git hook that checks for a linear git history
>  > of mainline and that rejects pushes otherwise, but I guess Stefan
>  > isn't very inclined to agree to that.
>
> My impression is that Stefan is not inclined to encourage work on this
> problem; he thinks it's a waste of time.  I think he'd come around
> quickly if presented with either another problem that would be solved
> by the same workflow that preserves linear mainline, or a
> "sufficiently convenient" workflow that preserves linear mainline.  I
> don't intend to speak for Stefan, just to encourage you to not give up
> on the idea of a hook before you've clarified the point with him.

On further thought, I think such a hook that rejects pushes because of
"non-linear mainline" would confuse people to no end. I don't know any
project which would do this, and as I've written above, many Git users
do not recognize the problem, which makes it hard to fix for them...

-David