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

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

[Leo Liu]

On 2014-12-11 15:57 +0000, Lars Ingebrigtsen wrote:
> +  (when (and (fboundp 'gnutls-available-p)
> +	     (gnutls-available-p))

Does this defeat the purpose of gnutls-available-p? BTW, why aren't all
these -available-p functions replaced by features?

Leo

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

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Fri, 12 Dec 2014 00:47:48 +0800
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>
> 
> why aren't all these -available-p functions replaced by features?

Because the feature might be available, but inoperable (e.g., if some
underlying library is missing).  This happens all the times in the
Windows build, where optional shared libraries are loaded dynamically
only when needed, even though Emacs itself was compiled with support
for that library.  We will see more of that once we support some kind
of dynamic modules.

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

[Ted Zlatanov]

On Thu, 11 Dec 2014 20:08:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Leo Liu <sdl.web@gmail.com>
>> Date: Fri, 12 Dec 2014 00:47:48 +0800
>> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>
>> 
>> why aren't all these -available-p functions replaced by features?

EZ> Because the feature might be available, but inoperable (e.g., if some
EZ> underlying library is missing).  This happens all the times in the
EZ> Windows build, where optional shared libraries are loaded dynamically
EZ> only when needed, even though Emacs itself was compiled with support
EZ> for that library.  We will see more of that once we support some kind
EZ> of dynamic modules.

I made a fix for this one in the emacs-24 branch, and the discussion of
bug#19346 has the details. I don't know if it will DTRT for W32 as Eli
describes, sorry.

For the dynamic modules, it will definitely have to be a general facility.

Ted

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

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 11 Dec 2014 18:00:55 -0500
> 
> On Thu, 11 Dec 2014 20:08:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> >> From: Leo Liu <sdl.web@gmail.com>
> >> Date: Fri, 12 Dec 2014 00:47:48 +0800
> >> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>
> >> 
> >> why aren't all these -available-p functions replaced by features?
> 
> EZ> Because the feature might be available, but inoperable (e.g., if some
> EZ> underlying library is missing).  This happens all the times in the
> EZ> Windows build, where optional shared libraries are loaded dynamically
> EZ> only when needed, even though Emacs itself was compiled with support
> EZ> for that library.  We will see more of that once we support some kind
> EZ> of dynamic modules.
> 
> I made a fix for this one in the emacs-24 branch, and the discussion of
> bug#19346 has the details. I don't know if it will DTRT for W32 as Eli
> describes, sorry.

Your change works for w32, but I've pushed a slightly better fix for
that.  In general, it is undesirable to have more than a single DEFUN
or DEFVAR for the same symbol, so we try to have just one, unless it's
impractical.  If nothing else, it keeps all the code and the doc
strings in one place.

Thanks.

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

[Ted Zlatanov]

On Fri, 12 Dec 2014 11:23:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> Your change works for w32, but I've pushed a slightly better fix for
EZ> that.  In general, it is undesirable to have more than a single DEFUN
EZ> or DEFVAR for the same symbol, so we try to have just one, unless it's
EZ> impractical.  If nothing else, it keeps all the code and the doc
EZ> strings in one place.

Thanks.  I'll keep that in mind.

It should get merged into master soon.  I can attempt another merge of
the emacs-24 branch... with fear :)

Ted

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

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 12 Dec 2014 08:24:58 -0500
> 
> I can attempt another merge of the emacs-24 branch... with fear :)

No need to fear, just remember to review what "git show" displays,
after the merge and before you push.  If it doesn't look OK to you,
you can always reset to cancel the merge.

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

[Stefan Monnier]

>> I can attempt another merge of the emacs-24 branch... with fear :)

Don't forget to use gitmerge.el.


        Stefan

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

[Ted Zlatanov]

On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> No need to fear, just remember to review what "git show" displays,
EZ> after the merge and before you push.  If it doesn't look OK to you,
EZ> you can always reset to cancel the merge.

Yup.  I did it, carefully.

On Fri, 12 Dec 2014 11:06:03 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>> I can attempt another merge of the emacs-24 branch... with fear :)

SM> Don't forget to use gitmerge.el.

Right, thanks.  It works well.

On Fri, 12 Dec 2014 21:46:05 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> It should get merged into master soon.  I can attempt another merge of
>> the emacs-24 branch... with fear :)

LMI> Oops.  I didn't notice that this fix went into the emacs-24 branch, so I
LMI> removed the `fboundp' checks from the trunk.  Which means that trunk
LMI> doesn't work for people without gnutls support.

LMI> So if you could do the merge, that would be nice, otherwise I'll have to
LMI> re-revert those `fboundp' changes again.

It's merged.  Sorry for the delay.

Ted

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

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It's merged.  Sorry for the delay.

Great; thanks.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Ted Zlatanov]

On Fri, 12 Dec 2014 19:25:38 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
EZ> No need to fear, just remember to review what "git show" displays,
EZ> after the merge and before you push.  If it doesn't look OK to you,
EZ> you can always reset to cancel the merge.

TZ> Yup.  I did it, carefully.

Damn it:

commit 805074d059b5bdb868a4f795a0aca58f49302f66
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Fri Dec 12 16:48:06 2014 -0800

    Remove duplicate ChangeLog entries

Thanks, Paul.  I missed that.

Ted

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

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 12 Dec 2014 19:25:38 -0500
> 
> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> EZ> No need to fear, just remember to review what "git show" displays,
> EZ> after the merge and before you push.  If it doesn't look OK to you,
> EZ> you can always reset to cancel the merge.
> 
> Yup.  I did it, carefully.

Thanks.  I fixed the dates of the ChangeLog entries merged by that.

David, is it possible to enhance gitmerge.el to take care of that
automatically?  Otherwise I predict that people will keep making these
mistakes forever.

Thanks.

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

[David Engster]

Eli Zaretskii writes:
> David, is it possible to enhance gitmerge.el to take care of that
> automatically?  Otherwise I predict that people will keep making these
> mistakes forever.

I was hoping that gitmerge already does it, since I lifted the ChangeLog
merge stuff directly from bzrmerge, which AFAIK also did the date
fixes. I'll take a look why that doesn't work anymore.

-David

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

[David Engster]

David Engster writes:
> Eli Zaretskii writes:
>> David, is it possible to enhance gitmerge.el to take care of that
>> automatically?  Otherwise I predict that people will keep making these
>> mistakes forever.
>
> I was hoping that gitmerge already does it, since I lifted the ChangeLog
> merge stuff directly from bzrmerge, which AFAIK also did the date
> fixes. I'll take a look why that doesn't work anymore.

It seems that this code will only fix dates for conflicted ChangeLog
files. However, the changelog merge driver will avoid those conflicts,
so nothing happens (Bzr had a changelog driver as well, so I'm not sure
how it ever worked).

I think the dates might get fixed when you disable the changelog merge
driver before running gitmerge.el. I know this is not really a solution,
but this is not trivial to fix and we'll switch to generated ChangeLogs
anyway, so I'm not inclined to work on this.

-David

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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: emacs-devel@gnu.org
> Date: Thu, 18 Dec 2014 23:38:54 +0100
> 
> David Engster writes:
> > Eli Zaretskii writes:
> >> David, is it possible to enhance gitmerge.el to take care of that
> >> automatically?  Otherwise I predict that people will keep making these
> >> mistakes forever.
> >
> > I was hoping that gitmerge already does it, since I lifted the ChangeLog
> > merge stuff directly from bzrmerge, which AFAIK also did the date
> > fixes. I'll take a look why that doesn't work anymore.
> 
> It seems that this code will only fix dates for conflicted ChangeLog
> files. However, the changelog merge driver will avoid those conflicts,
> so nothing happens (Bzr had a changelog driver as well, so I'm not sure
> how it ever worked).

AFAIR, Bazaar's changelog merge plugin would simply put all the merged
ChangeLog entries from the other branch on top, so all you needed to
do was manually update the dates of the top entries.  Git's driver
tries to be more sophisticated, so some entries which come from the
other branch are inserted in-between the existing entries.  Which
makes the merged entries harder to find.

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

[David Engster]

Ted Zlatanov writes:
> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
>
> EZ> No need to fear, just remember to review what "git show" displays,
> EZ> after the merge and before you push.  If it doesn't look OK to you,
> EZ> you can always reset to cancel the merge.
>
> Yup.  I did it, carefully.

I'm afraid something went wrong. You did not actually merge.

Could it be that you somehow rebased before pushing (by doing 'pull
--rebase', for instance)?

-David

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

[David Engster]

David Engster writes:
> Ted Zlatanov writes:
>> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
>>
>> EZ> No need to fear, just remember to review what "git show" displays,
>> EZ> after the merge and before you push.  If it doesn't look OK to you,
>> EZ> you can always reset to cancel the merge.
>>
>> Yup.  I did it, carefully.
>
> I'm afraid something went wrong. You did not actually merge.
>
> Could it be that you somehow rebased before pushing (by doing 'pull
> --rebase', for instance)?

Hmm. Even that wouldn't explain it, since I cannot see any rebased
commits from 'emacs-24' on 'master'. It seems like they're all squashed
into this one commit. I'd really like to see your reflog.

Anyway, I guess the best way to fix this is to do another merge of
emacs-24 with merge strategy 'ours'?

-David

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

[Ted Zlatanov]

On Sat, 13 Dec 2014 10:50:13 +0100 David Engster <deng@randomsample.de> wrote: 

DE> David Engster writes:
>> Ted Zlatanov writes:
>>> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
>>> 
EZ> No need to fear, just remember to review what "git show" displays,
EZ> after the merge and before you push.  If it doesn't look OK to you,
EZ> you can always reset to cancel the merge.
>>> 
>>> Yup.  I did it, carefully.
>> 
>> I'm afraid something went wrong. You did not actually merge.
>> 
>> Could it be that you somehow rebased before pushing (by doing 'pull
>> --rebase', for instance)?

I don't think so? Now I'm just perplexed, too. I must have rebased the
commit accidentally. I *started* to rebase because a commit came in
before I pushed.  But I aborted the rebase, then redid the merge.

DE> Hmm. Even that wouldn't explain it, since I cannot see any rebased
DE> commits from 'emacs-24' on 'master'. It seems like they're all squashed
DE> into this one commit. I'd really like to see your reflog.

DE> Anyway, I guess the best way to fix this is to do another merge of
DE> emacs-24 with merge strategy 'ours'?

It's definitely pilot error, you can assume it's not gitmerge.el.
Andreas has redone the merge, it seems.

I'm sorry about this, I'll get it right next time.

Ted

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

[David Engster]

Ted Zlatanov writes:
> On Sat, 13 Dec 2014 10:50:13 +0100 David Engster <deng@randomsample.de> wrote: 
>
> DE> David Engster writes:
>>> Ted Zlatanov writes:
>>>> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
>>>> 
> EZ> No need to fear, just remember to review what "git show" displays,
> EZ> after the merge and before you push.  If it doesn't look OK to you,
> EZ> you can always reset to cancel the merge.
>>>> 
>>>> Yup.  I did it, carefully.
>>> 
>>> I'm afraid something went wrong. You did not actually merge.
>>> 
>>> Could it be that you somehow rebased before pushing (by doing 'pull
>>> --rebase', for instance)?
>
> I don't think so? Now I'm just perplexed, too. I must have rebased the
> commit accidentally. I *started* to rebase because a commit came in
> before I pushed.

Never rebase commits that are upstream. Rebasing will always create new
commits (in case if you wondering, 'pull --rebase=preserve' doesn't
change that; it will keep a merge commit, but that will not merge
origin/emacs-24 anymore but a new set of commits).

Instead, simply merge master into your tree. Despite what others may
say, this is still a perfectly valid thing to do in Git. :-) This what
'git pull' will do by default (unless you configured it otherwise).

> But I aborted the rebase, then redid the merge.

Yes, it seems there was a pending commit when you finished the merge, so
it was all squashed into one. When you want to start from scratch, the
best thing to do is a hard reset on 'origin/master'. This will make sure
you're in the same state as upstream.

In any case, as much as I like Emacs, I really recommend to use 'gitk
--all' to inspect your tree before pushing. This will show you
immediately if you have created a proper merge from origin/emacs-24.

> I'm sorry about this,

Don't be.

> I'll get it right next time.

That's the spirit.

-David

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

[Ted Zlatanov]

On Sat, 13 Dec 2014 15:13:25 +0100 David Engster <deng@randomsample.de> wrote: 

DE> Never rebase commits that are upstream. Rebasing will always create new
DE> commits (in case if you wondering, 'pull --rebase=preserve' doesn't
DE> change that; it will keep a merge commit, but that will not merge
DE> origin/emacs-24 anymore but a new set of commits).

Yes.  I have a pull alias that I shouldn't have used.  I realized the
issue this morning after people noticed, but it was too late.

DE> Instead, simply merge master into your tree. Despite what others may
DE> say, this is still a perfectly valid thing to do in Git. :-) This what
DE> 'git pull' will do by default (unless you configured it otherwise).

>> But I aborted the rebase, then redid the merge.

DE> Yes, it seems there was a pending commit when you finished the merge, so
DE> it was all squashed into one. When you want to start from scratch, the
DE> best thing to do is a hard reset on 'origin/master'. This will make sure
DE> you're in the same state as upstream.

DE> In any case, as much as I like Emacs, I really recommend to use 'gitk
DE> --all' to inspect your tree before pushing. This will show you
DE> immediately if you have created a proper merge from origin/emacs-24.

Yes, will do.  I guess I'm too hard-headed to give up after doing this
wrong twice... I'll try the process again in a few days, third time's a charm.

Ted

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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Sat, 13 Dec 2014 15:13:25 +0100
> 
> Never rebase commits that are upstream. Rebasing will always create new
> commits (in case if you wondering, 'pull --rebase=preserve' doesn't
> change that; it will keep a merge commit, but that will not merge
> origin/emacs-24 anymore but a new set of commits).

English, please: what does that mean?  The documentation seems to
suggest that "pull --rebase=preserve" is exactly the right thing in
this situation.

> Instead, simply merge master into your tree. Despite what others may
> say, this is still a perfectly valid thing to do in Git. :-) This what
> 'git pull' will do by default (unless you configured it otherwise).

Yes, but then my commits will appear as merge-commits, won't they?

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

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Sat, 13 Dec 2014 15:13:25 +0100
>> 
>> Never rebase commits that are upstream. Rebasing will always create new
>> commits (in case if you wondering, 'pull --rebase=preserve' doesn't
>> change that; it will keep a merge commit, but that will not merge
>> origin/emacs-24 anymore but a new set of commits).
>
> English, please: what does that mean?

When you rebase a commit, it becomes a new one. Therefore, you can only
safely rebase "local" commits (meaning: commits only *you* have).

> The documentation seems to suggest that "pull --rebase=preserve" is
> exactly the right thing in this situation.

The name "preserve" is misleading. It does not mean that you have the
same merge after the rebase. That's not possible, since the commits
change during this operation.

It helps to think of a rebase simply as a series of cherry-picks. Any
conflicts you resolved in a merge commit are now resolved commit by
commit. If you do 'rebase=preserve', what git does is: it tries to
re-create(!)  the merge commit with the rebased commits afterwards. This
merge commit is pure metadata now, since there are no conflicts to
resolve.

So practically, 'rebase=preserve' is only meant for *unpushed* local
branches you have merged, and you want to keep the metadata of this
local merge.

>> Instead, simply merge master into your tree. Despite what others may
>> say, this is still a perfectly valid thing to do in Git. :-) This what
>> 'git pull' will do by default (unless you configured it otherwise).
>
> Yes, but then my commits will appear as merge-commits, won't they?

Not sure what you mean. This is equivalent to the merge-based workflow
we had with Bazaar.

-David

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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: emacs-devel@gnu.org
> Date: Sat, 13 Dec 2014 20:44:18 +0100
> 
> When you rebase a commit, it becomes a new one. Therefore, you can only
> safely rebase "local" commits (meaning: commits only *you* have).

If "safely" here means "while preserving the commit's sha1", then it's
quite obvious.  But why would that matter in this scenario?  And why
does that cause the merged versions appear as if they were not merged
at all, even when rebase=preserve was/is used?

> > The documentation seems to suggest that "pull --rebase=preserve" is
> > exactly the right thing in this situation.
> 
> The name "preserve" is misleading.

I didn't mean the name, I meant its documentation.  It says:

  locally committed merge commits will not be flattened by running
  'git pull'

"locally committed" seems to fit the scenario we are discussing, no?

> It does not mean that you have the same merge after the
> rebase. That's not possible, since the commits change during this
> operation.

I didn't say I want to have the same merge.  All I want is to have
_some_ indication there was a merge from the other branch, including
when that branch is a public branch.  You seem to say it's not
possible with Git.

> It helps to think of a rebase simply as a series of cherry-picks. Any
> conflicts you resolved in a merge commit are now resolved commit by
> commit. If you do 'rebase=preserve', what git does is: it tries to
> re-create(!)  the merge commit with the rebased commits afterwards. This
> merge commit is pure metadata now, since there are no conflicts to
> resolve.

Sorry, I still don't understand.  Which commits from what branches
does Git merge after 'rebase=preserve'?

And how do conflicts enter this picture?  Suppose there were no
conflicts at all during the original merge -- would the merge still
disappear after 'rebase=preserve'?

> >> Instead, simply merge master into your tree. Despite what others may
> >> say, this is still a perfectly valid thing to do in Git. :-) This what
> >> 'git pull' will do by default (unless you configured it otherwise).
> >
> > Yes, but then my commits will appear as merge-commits, won't they?
> 
> Not sure what you mean. This is equivalent to the merge-based workflow
> we had with Bazaar.

But I didn't work on a separate branch, I worked in master.
Therefore, I'd like to avoid merge-commits if possible, and I thought
using 'rebase=preserve' does that, and also lets me merge branches,
whether my local branches or the emacs-24 release branch.

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

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:

>> When you rebase a commit, it becomes a new one. Therefore, you can only
>> safely rebase "local" commits (meaning: commits only *you* have).
>
> If "safely" here means "while preserving the commit's sha1", then it's
> quite obvious.

Rebasing *never* preserves a commit's SHA.  So basically, you always get
a set of new commits that look very much like the old ones.

> at all, even when rebase=preserve was/is used?

What rebase=preserve does, is "pass --preserve-merges along to git
rebase so that locally created merge commits will not be flattened"
(quoting the 'git pull' man page).

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: David Engster <deng@randomsample.de>,  emacs-devel@gnu.org
> Date: Sun, 14 Dec 2014 00:00:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> When you rebase a commit, it becomes a new one. Therefore, you can only
> >> safely rebase "local" commits (meaning: commits only *you* have).
> >
> > If "safely" here means "while preserving the commit's sha1", then it's
> > quite obvious.
> 
> Rebasing *never* preserves a commit's SHA.  So basically, you always get
> a set of new commits that look very much like the old ones.

That's what I said.

> > at all, even when rebase=preserve was/is used?
> 
> What rebase=preserve does, is "pass --preserve-merges along to git
> rebase so that locally created merge commits will not be flattened"
> (quoting the 'git pull' man page).

That's what I said.

Thanks.

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

[David Engster]

[-- Attachment #1: Type: text/plain, Size: 3121 bytes --]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 13 Dec 2014 20:44:18 +0100
>> 
>> When you rebase a commit, it becomes a new one. Therefore, you can only
>> safely rebase "local" commits (meaning: commits only *you* have).
>
> If "safely" here means "while preserving the commit's sha1", then it's
> quite obvious.  But why would that matter in this scenario?  And why
> does that cause the merged versions appear as if they were not merged
> at all, even when rebase=preserve was/is used?

I think we really have to discuss this on an actual example. I've
attached a small script which will create three directories underneath a
directory called "MERGE_REBASE_TEST": 'upstream', 'ted' and 'eli'. There
are two branches, 'master' and 'stable', which Ted sets up and pushes. I
put some sleeps in there just so that the commits have different time
stamps.

Ted merges 'stable' into 'master', but does not push yet. Then Eli makes
a new commit on 'master' and pushes. This is where the script ends.

Now go to 'ted' and do 'gitk --all' to see the situation. If you try to
push with 'git push origin master', then this will fail because there's
this new commit from Eli. Now do 'git pull --rebase=preserve', and then
again do 'gitk --all'. You'll see that the 'stable' branch was rebased
onto 'origin/master'. This changed the SHA1 of those two commits on
'stable', as they now descend from a different parent. You *have* a
merge, but it is *not* a merge from origin/stable, but from a new
(unnamed) branch that was created by rebasing origin/stable.

Simply delete the MERGE_REBASE_TEST directory and run the script again
to try the alternatives for Ted. 'git pull --rebase' will do the same as
'--rebase=preserve' but will simply drop the merge commit ("flatten the
history"). Again, this will *not* merge the two commits from
origin/stable (a 'git log stable ^master' will list all commits that are
in stable but not in master).

If you simply do 'git pull', this will merge origin/master into your
tree. If you push this, everything will be OK. The above log command
will show nothing, just as it should after a succesful merge.

> I didn't say I want to have the same merge.  All I want is to have
> _some_ indication there was a merge from the other branch, including
> when that branch is a public branch.  You seem to say it's not
> possible with Git.

You can't at the same time move a branch onto a new parent (which is
what rebase does) and then merge it, so that it looks like you've merged
the original one which had another parent.

> Sorry, I still don't understand.  Which commits from what branches
> does Git merge after 'rebase=preserve'?

It merges the branch that is implicitly created by moving
'origin/emacs-24' to a newer parent.

> And how do conflicts enter this picture?  Suppose there were no
> conflicts at all during the original merge -- would the merge still
> disappear after 'rebase=preserve'?

I guess it's better to forget conflicts. I was hoping it would make
clearer how rebase works, but it just complicates things.

-David


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: merge-rebase-test.sh --]
[-- Type: text/x-sh, Size: 993 bytes --]

#!/bin/sh

mkdir MERGE_REBASE_TEST
cd MERGE_REBASE_TEST

# Create bare upstream
mkdir upstream
cd upstream
git init --bare
cd ..
# Ted clones, creates two commits on master and pushes.
git clone upstream ted
cd ted
echo "bla" > foo
git add foo
sleep 2
git commit -a -m "first commit on master"
echo "bla2" >> foo
sleep 2
git commit -a -m "second commit on master"
git push origin master
# Ted now creates branch 'stable' with two commits and pushes.
git checkout -b stable
echo "bla" > bar
git add bar
sleep 2
git commit -a -m "commit to stable 1"
echo "bla2" >> bar
sleep 2
git commit -a -m "commit to stable 2"
git push origin stable
# Ted goes back to master and merges 'origin/stable', but does NOT push.
git checkout master
sleep 2
git merge --no-ff origin/stable -m "merge stable"
cd ..
# Eli clones, creates new commit on master and pushes
git clone upstream eli
cd eli
git checkout master
echo "bla3" >> foo
sleep 2
git commit -a -m "New commit on master"
git push origin master
cd ..

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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Dec 2014 00:13:20 +0100
> 
> > Sorry, I still don't understand.  Which commits from what branches
> > does Git merge after 'rebase=preserve'?
> 
> It merges the branch that is implicitly created by moving
> 'origin/emacs-24' to a newer parent.

That's the missing link, thanks.

So this means that:

  . Using "pull --rebase=preserve" always rewrites the merge to come
    from some unnamed branch, which is different from the branch that
    originated the merged commits.

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

  . IOW, rebase=preserve is not useful in a merge-based workflow.

Is my interpretation correct?

If it is, then here's my conundrum.  When I make changes in master, I
don't want them to look as if they were made on some branch when I
push them.  Why? for starters, because "log --first-parent" won't show
them.  So I use "pull --rebase" to avoid that.  This works well as
long as I didn't make any local merge-commits, be it from my local
branches or from public branches such as emacs-24.  I thought that
using rebase=preserve would cover the latter use cases as well, but
now I understand I was mistaken: I can use "pull --rebase" only if
there were no merge-commits since the last refs update; otherwise I
need to use "pull".  So I cannot configure Git to always use some
option when pulling, and forget about that.

AFAIU, an alternative, when I have local merge-commits, is to use
"pull --ff-only", and when it refuses to pull, use "reset --hard
origin/master", and then "merge -no-ff" and commit, before pushing.
That's significantly more complicated, sigh.

Which means there's no easy way with Git to support a workflow that
preserves mainline, without jumping through some hoops.

Is that correct?  Or is there a better workflow that preserves the
mainline?

If there is no better workflow, perhaps we need to radically rethink
our recommended project workflow, like not base it on merges but on
rebase, or push fixes to master and then cherry-pick them to the
release branch, or something else.  Because what bzr supported easily
and almost seamlessly, Git doesn't -- in the sense that emulating the
same workflow is more complicated and thus error-prone.  To me, this
spells that we fight the tool, i.e. our workflow should change.

> You can't at the same time move a branch onto a new parent (which is
> what rebase does) and then merge it, so that it looks like you've merged
> the original one which had another parent.

I only use rebase because I don't know of another way of being able to
work on master without having my commits look as if they were made on
a branch, after I push them, which AFAIU will happen if someone else
pushes before I push my local commits made on master.  If there's a
reasonably simple way to avoid this effect without rebasing, I guess
I'll switch to that.  I didn't use rebase with bzr, because there was
a simple way to preserve the mainline without rebasing.

Btw, I think we need to do something urgently in gitmerge.el to avoid
this kind of mistakes.  Otherwise, people will keep making these
mistakes, and no amount of explanations will ever be able to prevent
that.

Thanks.

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

[Ted Zlatanov]

On Sun, 14 Dec 2014 18:09:49 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> If there is no better workflow, perhaps we need to radically rethink
EZ> our recommended project workflow, like not base it on merges but on
EZ> rebase, or push fixes to master and then cherry-pick them to the
EZ> release branch, or something else.  Because what bzr supported easily
EZ> and almost seamlessly, Git doesn't -- in the sense that emulating the
EZ> same workflow is more complicated and thus error-prone.  To me, this
EZ> spells that we fight the tool, i.e. our workflow should change.

I think cherry-picking fixes from emacs-24 to master or vice-versa is
the best way:

* we tend to make commits in isolation, so there's no need to merge the
  whole branch in one shot.  It's also much less risky as far as
  methodology.

* "cherry-pick -x" will preserve the original commit info

* "git diff" and "git log --cherry-pick" will do what people expect

Ted

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

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sun, 14 Dec 2014 11:37:49 -0500
> 
> I think cherry-picking fixes from emacs-24 to master or vice-versa is
> the best way:

IMO, if we go for cherry-picking, then it's best to fix bugs on master
and cherry-pick from there to emacs-24.

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

[Ted Zlatanov]

On Sun, 14 Dec 2014 18:55:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sun, 14 Dec 2014 11:37:49 -0500
>> 
>> I think cherry-picking fixes from emacs-24 to master or vice-versa is
>> the best way:

EZ> IMO, if we go for cherry-picking, then it's best to fix bugs on master
EZ> and cherry-pick from there to emacs-24.

It's OK to go either way. The patch is simply getting copied between the
branches, so the direction doesn't matter.

Ted

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

[Stefan Monnier]

  I think cherry-picking fixes from emacs-24 to master or vice-versa is
> the best way:

Good for you, but this has been decided long ago, and I have no
intention to discuss this again.


        Stefan

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

[Paul Eggert]

Eli Zaretskii wrote:
> perhaps we need to radically rethink
> our recommended project workflow, like not base it on merges but on
> rebase, or push fixes to master and then cherry-pick them to the
> release branch, or something else

Part of the problem is the mundane business of maintaining ChangeLogs by hand, 
an error-prone process with merges.  We're planning to fix this (currently 
scheduled for next month) by generating ChangeLogs automatically.  Perhaps once 
we've done that the remaining problems with merging will be so small that we can 
just live with them.  (The particular problem Ted ran into seems pretty 
complicated; I'm not sure it's a good use case for us when designing our 
development workflow.)

More fundamentally there's the issue of how much we want commits to be 
serialized.  That is, do we want development history to look as if it was done 
one commit at a time in a single branch?  If so, merges are not the way to go, 
because they're DAG-based.

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

[Eli Zaretskii]

> Date: Sun, 14 Dec 2014 09:46:12 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > perhaps we need to radically rethink
> > our recommended project workflow, like not base it on merges but on
> > rebase, or push fixes to master and then cherry-pick them to the
> > release branch, or something else
> 
> Part of the problem is the mundane business of maintaining ChangeLogs by hand, 
> an error-prone process with merges.  We're planning to fix this (currently 
> scheduled for next month) by generating ChangeLogs automatically.  Perhaps once 
> we've done that the remaining problems with merging will be so small that we can 
> just live with them.

I'm not sure.  The problem of using incorrect Git commands in the case
that triggered this discussion was unrelated to ChangeLogs.

> (The particular problem Ted ran into seems pretty complicated; I'm
> not sure it's a good use case for us when designing our development
> workflow.)

People are running into problems all over.  It's not just Ted and not
just that particular push.

> More fundamentally there's the issue of how much we want commits to be 
> serialized.  That is, do we want development history to look as if it was done 
> one commit at a time in a single branch?  If so, merges are not the way to go, 
> because they're DAG-based.

That's what I was asking, in different words.

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

[Ted Zlatanov]

On Sun, 14 Dec 2014 09:46:12 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: 

PE> (The particular problem Ted ran into seems pretty complicated; I'm
PE> not sure it's a good use case for us when designing our development
PE> workflow.)

No, please assume I screwed up :)

But I still think generally, cherry-picks are easier to manage and
harder to screw up.  The gitmerge.el workflow is basically a sequence of
cherry-picks.

Ted

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

[David Engster]

Ted Zlatanov writes:
> But I still think generally, cherry-picks are easier to manage and
> harder to screw up.

Cherry-picks are *terrible* to manage. Git tries a bit to do that,
either be giving you tools to record additional information in the
commit log (see the '-x' option of cherry-pick), or by using patch-id's,
but all of that stuff pretty much falls apart when you have conflicts,
so it's nothing you can really rely on (especially not us, because of
ChangeLogs).

> The gitmerge.el workflow is basically a sequence of cherry-picks.

No, that's precisely what gitmerge.el avoids. It is a sequence of
merges.

-David

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

[David Engster]

Eli Zaretskii writes:
> So this means that:
>
>   . Using "pull --rebase=preserve" always rewrites the merge to come
>     from some unnamed branch, which is different from the branch that
>     originated the merged commits.

Yes.

>   . 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? You're right that in this case doing 'pull
--rebase=preserve' is problematic. If you continue to work on your
branch and merge from master, you will indeed merge the rebased
commits. To avoid that, you would have to delete the old branch and
continue working on the rebased one.

>   . IOW, rebase=preserve is not useful in a merge-based workflow.

Rebasing is the anti-thesis to merging, so a purely merge-based workflow
wouldn't touch it in the first place (see: Bazaar).

> If it is, then here's my conundrum.  When I make changes in master, I
> don't want them to look as if they were made on some branch when I
> push them. Why? for starters, because "log --first-parent" won't show
> them.  So I use "pull --rebase" to avoid that.  This works well as
> long as I didn't make any local merge-commits, be it from my local
> branches or from public branches such as emacs-24.

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?

> AFAIU, an alternative, when I have local merge-commits, is to use
> "pull --ff-only", and when it refuses to pull, use "reset --hard
> origin/master", and then "merge -no-ff" and commit, before pushing.

That would also mean you have to fix conflicts again (unless you use the
'rerere' feature, but let's not go there yet).

> Which means there's no easy way with Git to support a workflow that
> preserves mainline, without jumping through some hoops.
>
> Is that correct?

I would say it is. AFAIK, Git has no notion of 'mainline' like Bazaar
had, so trying to preserve it does require a lot of discipline.

> If there is no better workflow, perhaps we need to radically rethink
> our recommended project workflow, like not base it on merges but on
> rebase, or push fixes to master and then cherry-pick them to the
> release branch, or something else.

Cherry-picking to emacs-24 would indeed make some things easier. Most
importantly, it would make gitmerge.el obsolete (which I consider a good
thing).

-David

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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Dec 2014 22:40:41 +0100
> 
> Eli Zaretskii writes:
> > So this means that:
> >
> >   . Using "pull --rebase=preserve" always rewrites the merge to come
> >     from some unnamed branch, which is different from the branch that
> >     originated the merged commits.
> 
> Yes.
> 
> >   . 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.

> You're right that in this case doing 'pull
> --rebase=preserve' is problematic. If you continue to work on your
> branch and merge from master, you will indeed merge the rebased
> commits. To avoid that, you would have to delete the old branch and
> continue working on the rebased one.

Sad.

> >   . IOW, rebase=preserve is not useful in a merge-based workflow.
> 
> Rebasing is the anti-thesis to merging, so a purely merge-based workflow
> wouldn't touch it in the first place (see: Bazaar).

But rebase=preserve seemed to be advertised to give you the best of
both worlds.  Now it turns out to be a sales gimmick at best, and a
time bomb at worst...

> > If it is, then here's my conundrum.  When I make changes in master, I
> > don't want them to look as if they were made on some branch when I
> > push them. Why? for starters, because "log --first-parent" won't show
> > them.  So I use "pull --rebase" to avoid that.  This works well as
> > long as I didn't make any local merge-commits, be it from my local
> > branches or from public branches such as emacs-24.
> 
> 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.

> > AFAIU, an alternative, when I have local merge-commits, is to use
> > "pull --ff-only", and when it refuses to pull, use "reset --hard
> > origin/master", and then "merge -no-ff" and commit, before pushing.
> 
> That would also mean you have to fix conflicts again (unless you use the
> 'rerere' feature, but let's not go there yet).

Yes.  Like I said: more complicated.

> > Which means there's no easy way with Git to support a workflow that
> > preserves mainline, without jumping through some hoops.
> >
> > Is that correct?
> 
> I would say it is. AFAIK, Git has no notion of 'mainline' like Bazaar
> had, so trying to preserve it does require a lot of discipline.

Discipline I have.  It's memory that I no longer have enough to
prevent me from making mistakes when certain everyday actions need
small variations.

Thanks.

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

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Cc: emacs-devel@gnu.org
>> 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

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 <deng@randomsample.de>
> Cc: emacs-devel@gnu.org
> 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.

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

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

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

Let me see if I understand, you branch off from master like so:

 -a---b-c-d- master
     \
      e-f- eli-feature-1

Then you wish to prepare for a push so you merge in master:

 -a---b-c-d--- master
     \      \
      e-f----g- eli-feature-1

(where "g" is the merge commit)

You merge your feature branch into master (ff merge):

 -a---b-c-d------ master
     \      \  /
      e-f----g---- eli-feature-1

And then push of master fails, and you do 
 git pull --rebase=preserve

and at this point I have no idea what the branches look like, since
I've never used "--rebase=preserve".

But if I understand you correctly, you're concerned that if you
continue to work on eli-feature-1 and then merge into master, then the
commits "b", "c", and "d" that were merged into your feature branch
will be re-applied?

Have you seen this happen? The "git merge" command seems to be
generally very good at backing off when the changes are already in
place (e.g. when I cherry pick changes from master back to a release
branch, and later merge the release branch, I rarely see conflicts).

At least, if you were doing ordinary merges in pull, it would never be
a problem... but I'm guessing (note: "guessing") now that what happens
is that what you end up with on master, is a rebased version of the
merge commit "g", ie. something like this:

 -a---b-c-d-i-j-h- master
     \      \  /
      e-f----\/
              \g---- eli-feature-1

where "i" and "j" are the commits that blocked your push, and "h" is a
rebased version of "g"?
(I saw later that my guessing might be off, see below for more)

Hm... what would happend if you continue to work on eli-feature-1 and
then merge back into master, I have no idea... probably nothing good.

The simplest way to proceed would be to just delete the existing
eli-feature-1 and create a new eli-feature-1 off the rebased merge
commit "h". 

You could pop off "g" of eli-feature-1, ie.
 git checkout eli-feature-1
 git reset --hard HEAD~1
and then merge in master to get "h" in its place
 git merge master

But it amounts to the more or less same thing (and it all depends on
the behaviour being like I describe, which may not be the case, since
I'm just guessing).

> Where will origin/master help in this situation?

Not directly, but you can prepare for the newest that will be on
master after the pull before push, without moving off your feature
branch, ie.
 git fetch
 git merge origin/master

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

FWIW I agree on all of Eli's saying here.

[snip! rebasing feature branches]
> 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.

I'm again in complete agreement with Eli.

[snip!]
> 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.

+10

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

Aah... so that's what happens: "b", "c", "d" in the example above
(that come from master into your feature branch), are rebased, and
then later reapplied...? 

If so that's bad! (I *knew* there were good reasons to shun rebase,
and if this is the case I have some real ammunition the next time a
discussion with a rebase entusiast comes up)

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

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> and at this point I have no idea what the branches look like, since
> I've never used "--rebase=preserve".

I still haven't used it, but I have googled a bit, and I found this:
 http://stackoverflow.com/a/15915431

Example 3 looks a lot like what I outlined, ie. you would get something
like this:

>  -a---b-c-d-i-j-h- master
>      \      \  /
>       e-f----\/
>               \g---- eli-feature-1

> where "i" and "j" are the commits that blocked your push, and "h" is a
> rebased version of "g"?

And if so, there will never be a problem with "b", "c", and "d", because
they are recorded in "h" (which is the rebased "g").

But there _will_ be a problem if you continue with eli-feature-1 with
"g" in the graph.

Ie. you will need to pop off a non-rebased merge commit and replace it
with the rebased one on one of the the two branches with you proceed
(the merge commit can be rebased on either branch, but it's probably
less work to do the rebase together with the pull on master, and then
fix it later in the feature branch).

Unless someone has written an extension to let you rebase two branches
simultanously...? It wouldn't surprise me, but a quick googling didn't
turn up anything.

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

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Wed, 17 Dec 2014 11:52:54 +0100
> 
> > and at this point I have no idea what the branches look like, since
> > I've never used "--rebase=preserve".
> 
> I still haven't used it, but I have googled a bit, and I found this:
>  http://stackoverflow.com/a/15915431

Yes, I've read it when I tried to understand what exactly does
rebase=preserve do.

> Example 3 looks a lot like what I outlined, ie. you would get something
> like this:

> >  -a---b-c-d-i-j-h- master
> >      \      \  /
> >       e-f----\/
> >               \g---- eli-feature-1
> 
> > where "i" and "j" are the commits that blocked your push, and "h" is a
> > rebased version of "g"?
> 
> And if so, there will never be a problem with "b", "c", and "d", because
> they are recorded in "h" (which is the rebased "g").
> 
> But there _will_ be a problem if you continue with eli-feature-1 with
> "g" in the graph.

Yes, that's the problem.

AFAIU, there are 2 possible ways to escape this problem:

  . Let go of the desire to keep the "mainline" linear, and just use
    "pull" when updating master from upstream.

  . Use "pull --ff-only", and if it refuses to pull, cancel the merge,
    pull, and merge again using "merge --no-ff".  This will probably
    preserve the mainline (unless Git has more surprises ;-), and also
    keep the merge-commits intact, but at the cost of more complicated
    and error-prone workflow.

For GitForEmacsDevs, I tend to prefer the former, since I don't hear
too many voices in support of the linear mainline desire.

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

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Wed, 17 Dec 2014 10:58:15 +0100
> 
> Let me see if I understand, you branch off from master like so:
> 
>  -a---b-c-d- master
>      \
>       e-f- eli-feature-1
> 
> Then you wish to prepare for a push so you merge in master:

>  -a---b-c-d--- master
>      \      \
>       e-f----g- eli-feature-1
> 
> (where "g" is the merge commit)

> You merge your feature branch into master (ff merge):

>  -a---b-c-d------ master
>      \      \  /
>       e-f----g---- eli-feature-1
> 
> And then push of master fails, and you do 
>  git pull --rebase=preserve

Yes, this is the workflow and the scenario I was describing.  With
bzr, it actually happened more or less every time I finished a feature
and was about to land it on trunk.  So naturally, I would like to
preserve the workflow if it's practically possible.

> But if I understand you correctly, you're concerned that if you
> continue to work on eli-feature-1 and then merge into master, then the
> commits "b", "c", and "d" that were merged into your feature branch
> will be re-applied?

Yes.

Also note that I'm not only concerned about myself alone, but about
all those who read or will read GitForEmacsDevs, and try to follow the
instructions there.  They current suggest "pull --rebase", although
stop short of mentioning rebase=preserve.

> Have you seen this happen?

No, not yet (thankfully).

> The "git merge" command seems to be generally very good at backing
> off when the changes are already in place (e.g. when I cherry pick
> changes from master back to a release branch, and later merge the
> release branch, I rarely see conflicts).

I know and agree, but I'd prefer not to rely on sheer luck, even if
the chances are very high.  If the danger exists, then the costs of
the failure, however rare, can be too high, so I'd like to avoid that
completely, especially for the audience of GitForEmacsDevs.

> The simplest way to proceed would be to just delete the existing
> eli-feature-1 and create a new eli-feature-1 off the rebased merge
> commit "h". 

That's mostly what happens, at least in my sandboxes.  But again,
there are others who might not delete the branch right away, and
there's emacs-24, of course.

> > 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.
> 
> Aah... so that's what happens: "b", "c", "d" in the example above
> (that come from master into your feature branch), are rebased, and
> then later reapplied...? 

Yes.

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

[David Engster]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: David Engster <deng@randomsample.de>
>> Cc: emacs-devel@gnu.org
>> 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.

Thank you for explaining it again. You are right that 'origin/master'
won't help you in this case. As soon as you rebase, merge and push, you
simply cannot work on your old branch. You have to delete it and set it
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...). This is why I prefer an explicit rebase onto
master, as it will not keep the old one lying around.

>> 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? You're right that
this will be lost.

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

Yes. I do that instead of merging master into my feature branch. I just
happen to not like this "merge from trunk" business, and I also prefer
to resolve conflicts commit-by-commit. Also, I usually do an interactive
rebase to clean up my branch before merging (I usually never get a
feature branch "right" the first time).

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

OK, let me try to summarize what I think are the two main conflicting
requirements:

. You want to handle merges of local feature branches and public
  branches (like 'emacs-24') in the same way.

I think this one is the strongest requirement, since it means you simply
cannot use 'rebase' in any way. Also, you've pointed out several other
problems with 'rebase', like loosing the "real" history of a feature
branch, and accidental merging of rebased commits.

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.

An alternative would be to swap the parents after the merge of a normal
'git pull', but that requires some Git plumbing, which however can be
easily scripted.

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

-David

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

[Stephen J. Turnbull]

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"?  (Real question, I don't understand your reference
to "seeing ... branch as merged".  The docs seem to indicate it should
work.)

 > > 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? You're right that
 > this will be lost.

I think this is the crucial question.  git documents are very good at
explaining implementations, but people have a habit of deciding what
they think a command does based on its name.  That matters a little
for Eli, and a lot for GitForEmacsDevs.

We really need to see what DAG Eli wants to construct.  Then we can
see how to create it using primitives, and finally see if there's a
reasonable shortcut by using more complex commands and appropriate
options (where "reasonable" is defined "Eli feels comfortable with it
for the purposes he has in mind" -- we have to ask Eli :-).

 > OK, let me try to summarize what I think are the two main conflicting
 > requirements:
 > 
 > . You want to handle merges of local feature branches and public
 >   branches (like 'emacs-24') in the same way.
 > 
 > I think this one is the strongest requirement, since it means you simply
 > cannot use 'rebase' in any way. Also, you've pointed out several other
 > problems with 'rebase', like loosing the "real" history of a feature
 > branch, and accidental merging of rebased commits.
 > 
 > 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 don't see a conflict here.  What I do see is an ambiguity in the
discription of entry conditions.  If you bzr-think, on a feature
branch the "local master" is likely to be the feature branch.[1]  That
is, the workflow is

    git clone git:emacs ./feature-1
    cd feature-1
    emacs file1 ...
    git commit
    git pull git:emacs    # we've just swapped master and
                          # origin/master, ie, the public mainline,
                          # when we push mainline is nonlinear

without actually defining a branch.  I agree this is problematic.
It's more complex, but if you do

    git clone git:emacs ./feature-1
    cd feature-1
    git checkout -b feature-1
    emacs file1 ...
    git commit
    git pull git:emacs      # origin/master contains public mainline
                            # feature-1 contains local mainline

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.  I think that
one way to provide convenience and discipline would be to (a) require
that the feature branch workspace be located in a directory with the
same name as the feature branch, and (b) provide git-pull-emacs and
git-push-emacs scripts that check for $(basename $cwd) == feature-name
as a precondition.  I don't know about the failed merge recovery,
though.

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

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

Footnotes: 
[1]  I think Eli means that in his feature branch workspace he uses a
branch named for the feature rather than master, but we need to be
clear about this.

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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>     emacs-devel@gnu.org
> Date: Thu, 18 Dec 2014 13:55:26 +0900
> 
>  > > 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? You're right that
>  > this will be lost.
> 
> I think this is the crucial question.  git documents are very good at
> explaining implementations, but people have a habit of deciding what
> they think a command does based on its name.  That matters a little
> for Eli, and a lot for GitForEmacsDevs.
> 
> We really need to see what DAG Eli wants to construct.

The one that would be there if the push from master following a merge
from a feature branch succeeded.  I hope this is clear enough; if not,
please ask more specific questions.

> (where "reasonable" is defined "Eli feels comfortable with it
> for the purposes he has in mind" -- we have to ask Eli :-).

I don't think I've invented something unnatural here.  What I'd like
is to have a merge-based workflow where the DAG reflects all the
merges between 2 branches as they happened in real time.  Race
conditions interfere with that, but I'd like to resolve that issue
in a way that only affects the last merge before the final successful
push from the local master to upstream.

>  > . 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 don't see a conflict here.  What I do see is an ambiguity in the
> discription of entry conditions.  If you bzr-think, on a feature
> branch the "local master" is likely to be the feature branch.[1]  That
> is, the workflow is

>     git clone git:emacs ./feature-1
>     cd feature-1
>     emacs file1 ...
>     git commit
>     git pull git:emacs    # we've just swapped master and
>                           # origin/master, ie, the public mainline,
>                           # when we push mainline is nonlinear
> 
> without actually defining a branch.

This is not how work on a branch happens (and not how it happened with
bzr).  There's an actual named branch, and changes are merged from
there to master, before pushing them.

>     git clone git:emacs ./feature-1
>     cd feature-1
>     git checkout -b feature-1
>     emacs file1 ...
>     git commit
>     git pull git:emacs      # origin/master contains public mainline
>                             # feature-1 contains local mainline

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

What I do for emacs-24 is similar, but not identical:

  git clone git:emacs ./emacs-24
  cd emacs-24
  git checkout emacs-24
  <hack, hack>
  git commit
  git push
  cd ../trunk # another clone
  git checkout master
  git pull
  git merge origin/emacs-24
  <test, fix problems, commit>
  git push

> The problems are (1) a convenient discipline for those last three
> commands

What is error-prone about them?

> I think that one way to provide convenience and discipline would be
> to (a) require that the feature branch workspace be located in a
> directory with the same name as the feature branch, and (b) provide
> git-pull-emacs and git-push-emacs scripts that check for $(basename
> $cwd) == feature-name as a precondition.

Sounds complicated, and I'm not sure it's really needed.  Local
feature branches (unlike emacs-24) don't need to be in a separate
directory, because they usually don't diverge from master enough to
justify that.  What remains is the requirement to be aware of the
currently checked-out branch, something that is quite easy both at the
shell prompt (where Git instructs Bash to show the branch) and in
Emacs.

A significant disadvantage of this proposal, at least for me, is that
it defines a set of commands and some details of the workflow that are
specific to Emacs and not available and/or unneeded in any other
project that uses Git.  So it gets in the way of a more efficient
learning to use Git by combining the experience from other projects.

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

But there doesn't appear to be such a sufficiently convenient
workflow, not with Git.

> [1]  I think Eli means that in his feature branch workspace he uses a
> branch named for the feature rather than master

Of course!

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

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> What I do for emacs-24 is similar, but not identical:

>   git clone git:emacs ./emacs-24
>   cd emacs-24
>   git checkout emacs-24
>   <hack, hack>
>   git commit
>   git push
>   cd ../trunk # another clone
>   git checkout master
>   git pull
>   git merge origin/emacs-24

What I would do here, is:
 git merge --no-ff --no-commit origin/emacs-24

Then I would inspect the diffs in magit, fix any conflicts, and stage
the conflict-fixed files, revert the changes that shouldn't be there
(typically version-related stuff, and this is mostly taken care off on
the first merge, but it never hurts to check), and then do 'c c' in
magit to commit the merge.

>   <test, fix problems, commit>
>   git push

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

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Thu, 18 Dec 2014 21:00:00 +0100
> 
> >   cd ../trunk # another clone
> >   git checkout master
> >   git pull
> >   git merge origin/emacs-24
> 
> What I would do here, is:
>  git merge --no-ff --no-commit origin/emacs-24
> 
> Then I would inspect the diffs in magit, fix any conflicts, and stage
> the conflict-fixed files, revert the changes that shouldn't be there
> (typically version-related stuff, and this is mostly taken care off on
> the first merge, but it never hurts to check), and then do 'c c' in
> magit to commit the merge.
> 
> >   <test, fix problems, commit>
> >   git push

Not sure how what you suggest is different, in principle.  Why does it
matter if I examine the results of a merge before or after I commit
it?  It's a local commit, and I can always go back if I need to.  But
I see no reason to assume up front I'd need to back up, since we are
talking about a merge from the release branch, not from a development
branch.  So I have all the reasons to believe the merge will be
uneventful, and there will be no conflicts most of the time.  Which
makes all the precautions like --no-ff and --no-commit unnecessary, I
think.

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

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Not sure how what you suggest is different, in principle. 

Not different, just convenient.

> Why does it matter if I examine the results of a merge before or after
> I commit it?  It's a local commit, and I can always go back if I need
> to.

Yes, of course.  But magit's presentation of a staged, but yet
uncommitted merge, is a very convenient and keyboard-only way of viewing
the merge resuls (a compact representation of new files, for one thing,
compared to a diff), and it's easy to fix conflicts, and revert files
without leaving emacs.

> But I see no reason to assume up front I'd need to back up, since we
> are talking about a merge from the release branch, not from a
> development branch.  So I have all the reasons to believe the merge
> will be uneventful, and there will be no conflicts most of the time.

Not so much conflicts merging that way, but version number stuff always
show up on the first merge, and sometimes later as well (it's good to
check).  And in emacs' case there has been the ChangeLog stuff (are they
autogenerated and not committed these days?).

> Which makes all the precautions like --no-ff and --no-commit
> unnecessary, I think.

I don't do it merging in to my own branches, but I always give published
merges a final look-over in this way before pushing them (ie. merges
_to_ master and release branches).

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

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Fri, 19 Dec 2014 09:09:03 +0100
> 
> > But I see no reason to assume up front I'd need to back up, since we
> > are talking about a merge from the release branch, not from a
> > development branch.  So I have all the reasons to believe the merge
> > will be uneventful, and there will be no conflicts most of the time.
> 
> Not so much conflicts merging that way, but version number stuff always
> show up on the first merge, and sometimes later as well (it's good to
> check).

What do you mean by "version number stuff"?

> And in emacs' case there has been the ChangeLog stuff

This doesn't cause conflicts most of the time, if you use the
git-merge-changelog driver.

> > Which makes all the precautions like --no-ff and --no-commit
> > unnecessary, I think.
> 
> I don't do it merging in to my own branches, but I always give published
> merges a final look-over in this way before pushing them (ie. merges
> _to_ master and release branches).

Yes, but "git show" before pushing will do it well enough.

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

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> What do you mean by "version number stuff"?

The version of the package itself (eg. AC_INIT in configure.ac and the
line in the README file), and versions of dependencies.

Stuff like the AC_INIT line will usually be taken care of in the first
merge, however if the configure.ac is changed for some reason on the
emacs-24 branch, one should examine the merge results. 

Git tries to be clever in merges, and usually manages to be so, but I've
seen it fail in cases like this (ie. making changes in the file
containing a package's version number).  And in a staged-but-uncommitted
merge in magit, the workflow is simple and emacs-ish:
 - Edit configure.ac (fix the AC_INIT line and keep the rest)
 - 'C-x v =' to check the diff
 - Go back to magit ('q' to close the vc diff, 'C-x b RET' from the
   source file) the unstaged version of the file ('s' in front of the
   file)
 - In magit 'c c' to commit the merge

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

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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: emacs-devel@gnu.org
> 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.

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

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

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

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

Indeed,... unless you can break them of the habit of merging master into
the feature branch before merging with master...?

If they always merge from the feature branch into master and then push,
they will be safe.  They can merge back from master after they have
successfully pushed master.

But the safest will always be not to worry about the linearity of the
mainline. 

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

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Thu, 18 Dec 2014 20:46:51 +0100
> 
> > 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.
> 
> Indeed,... unless you can break them of the habit of merging master into
> the feature branch before merging with master...?

Unlikely.  My take of that workflow is that those people try to keep
'master' pristine, so they won't want to merge there until they are
really ready to push; any real work gets done on a branch.

> If they always merge from the feature branch into master and then push,
> they will be safe.  They can merge back from master after they have
> successfully pushed master.

They must merge from master before the push, to test the merge
results.

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

[Yuri Khan]

On Fri, Dec 19, 2014 at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> They must merge from master before the push, to test the merge
> results.

Why not merge *into* master and test that before pushing?

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

[Steinar Bang]

>>>>> Yuri Khan <yuri.v.khan@gmail.com>:

> On Fri, Dec 19, 2014 at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> They must merge from master before the push, to test the merge
>> results.

> Why not merge *into* master and test that before pushing?

My guess would be that they merge in regularily from master or emacs-24,
to make sure they stay in sync...?

Ie.
 git checkout my-feature-branch
 git fetch
 git merge origin/master
 <build-and-test>
 <work-work-work>
 <new day>
 git fetch
 git merge origin/master
 <build-and-test>
 <work-work-work>
 etc.

And that's OK, it's only the final merge to master (and subsequent
commits) that will be rebased with a pull.

So if they do:
 git checkout master
 git merge --no-ff my-feature-branch
 git push
 <error message>
 git pull
 git push
the rebased commit will only be on master and not on my-feature-branch

(the --no-ff argument to merge, causes git to always create a merge
commit, even if the merge is a FF)

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

[Eli Zaretskii]

> Date: Fri, 19 Dec 2014 13:07:12 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Steinar Bang <sb@dod.no>, Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, Dec 19, 2014 at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > They must merge from master before the push, to test the merge
> > results.
> 
> Why not merge *into* master and test that before pushing?

Because they want to keep master pristine, and so do no development at
all there.  (Please keep in mind that I'm describing what I think is
someone else's state of mind, as I gleaned it from their commits in
the past.  It's not what I do or think.)

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

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>

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

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

[Stefan Monnier]

> When I make changes in master, I don't want them to look as if they
> were made on some branch when I push them.

I think that's a mistake.  Emacs's history should be less linear.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: David Engster <deng@randomsample.de>,  emacs-devel@gnu.org
> Date: Sun, 14 Dec 2014 17:42:42 -0500
> 
> > When I make changes in master, I don't want them to look as if they
> > were made on some branch when I push them.
> 
> I think that's a mistake.  Emacs's history should be less linear.

Feel free to describe a better workflow in more detail.  The
"mistaken" one is the basis for what's described on the Wiki, so if we
think that should change, we need to know better how to describe it.

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

[Stefan Monnier]

>> > When I make changes in master, I don't want them to look as if they
>> > were made on some branch when I push them.
>> I think that's a mistake.  Emacs's history should be less linear.
> Feel free to describe a better workflow in more detail.

I'm just saying that "not wanting to make them look as if they were made
on a branch" is not something very important.


        Stefan

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

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It should get merged into master soon.  I can attempt another merge of
> the emacs-24 branch... with fear :)

Oops.  I didn't notice that this fix went into the emacs-24 branch, so I
removed the `fboundp' checks from the trunk.  Which means that trunk
doesn't work for people without gnutls support.

So if you could do the merge, that would be nice, otherwise I'll have to
re-revert those `fboundp' changes again.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Leo Liu]

On 2014-12-11 20:08 +0200, Eli Zaretskii wrote:
> Because the feature might be available, but inoperable (e.g., if some
> underlying library is missing).  This happens all the times in the
> Windows build, where optional shared libraries are loaded dynamically
> only when needed, even though Emacs itself was compiled with support
> for that library.  We will see more of that once we support some kind
> of dynamic modules.

I see and thanks for the info.

Leo