Re: [O] Merge branch 'maint'

[Nicolas Richard]

Oleh Krehel  writes:
> Now, please check my facts again. Is it true that Emacs doesn't have
> maint and has instead a bunch of hanging branches for each release that
> aren't meant to have master merged into them on release?

In emacs, the current emacs24 branch will never be used for a release
unless there is a serious concern with emacs-24.5 that needs a
emacs-24.6 release. So it sees no commits, except for the few commits
that "really should go into 24.6 if it is ever released".

Before 24.5 was released, emacs-24 had more commits, and was regularly
merged backinto master.

> If so, what
> exactly is the advantage in applying a patch to a stable branch and then
> merging it into master, instead of applying to patch to master and
> cherry-picking it to the stable branch?

We don't want to create to distinct commits for a given change, because
they will not be related in the git sense (the « DAG ») and it will be
more difficult to e.g. list every branch that has a given change.

> I'm not saying that I'm a Git expert or anything, far from it. But I
> observe the Git history of Emacs and Org regularly, and both models seem
> to be working fine for the users, release-wise. But the master branch of
> Emacs looks a lot better than the master branch of Org, and I don't
> understand the trade-off that Org's model offers to compensate for that
> lack of prettiness.

IIUC Org has a similar model, except that maint is merged far more often
into master (basically after every commit to maint). Probably this is
done so that `master branch users' don't need to wait before seeing the
bugfixes that go to maint.

-- 
Nicolas

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Kyle Meyer  writes:

>> As far as I understood, maint is a subset of master, i.e. all commits
>> that are in maint are in master as well. Is that correct?
>
> Yes.  As long as there aren't any new commits on maint that have yet to
> be merged

What is the purpose of maint exactly? In Emacs git repository there's
master and emacs24. All commits apply to master first, while some are
cherry picked onto emacs24. The emacs24 branch will never be merged into
master: it's divergent and that's fine.

As I understood, for Org mode some commits are applied to maint, and
then merged into master. Why?

Oleh

Re: [O] Merge branch 'maint'

[Achim Gratz]

Am 11.09.2015 um 13:59 schrieb Oleh Krehel:

What is the purpose of maint exactly?


It's a bit short on the explanation side, but does that help?

http://orgmode.org/worg/dev/index.html

Also (not exactly the branch model ORg uses, but explains the issues in 
more detail):


http://nvie.com/posts/a-successful-git-branching-model/
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
http://williamdurand.fr/2012/01/17/my-git-branching-model/


In Emacs git repository there's
master and emacs24. All commits apply to master first, while some are
cherry picked onto emacs24. The emacs24 branch will never be merged into
master: it's divergent and that's fine.


You might want to check your facts (most recently, see for instance 
commit 59db4308b546).  Realitity simply doesn't conform to your 
world-view and the conclusions you draw from it are similarly distorted. 
 Cherry-picking from master to emacs24 is actually fixing a mistake 
made when committing a bug-fix to master.



As I understood, for Org mode some commits are applied to maint, and
then merged into master. Why?


Because that's how you make sure that bugfixes are applied to the 
releases in maint and get incorporated into master so that they don't 
vanish with the next release, all while each change appears exactly in 
one commit.



--
Achim.

(on the road :-)

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Stefan Nobis  writes:

> Oleh Krehel  writes:
>
>> Would it be so hard for Git to perform a single merge of master into
>> maint on release, while keeping them separate and cherry-picking
>> in-between for the sake of a clean linear history?
>
> The question is not whether git is capable of doing this (there are
> ways to accomplish this goal). The true question is: Do you really
> want a linear history?

Of course I do: it's prettier. My problem is that I don't see the
advantages that the other approach brings, I only see that it takes away
the prettiness.

> A linear history may look pretty, but at the same time you loose
> information. In a big complex project that is also a dependency to
> another complex project, a bit more ugly bookeeping may make
> maintenance easier.

Org's git history doesn't look complex at all: the commits are pretty
much synchronous and applied to master and maint at the same time.
Basically, Org's history is already linear, it's just hard to see it
behind the ugly bookkeeping.

Oleh

Re: [O] Merge branch 'maint'

[Josiah Schwab]

Hello Oleh,

On 11 September 2015 at 04:59 PDT, Oleh Krehel wrote:

> What is the purpose of maint exactly? In Emacs git repository there's
> master and emacs24. All commits apply to master first, while some are
> cherry picked onto emacs24. The emacs24 branch will never be merged into
> master: it's divergent and that's fine.
>
> As I understood, for Org mode some commits are applied to maint, and
> then merged into master. Why?

It may be helpful for you to do a some background reading on workflows
with git.  Have you ever read the gitworkflows man page?

  https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

This page discusses many of the questions you have raised.

Best,
Josiah

Re: [O] Merge branch 'maint'

[Suvayu Ali]

On Thu, Sep 10, 2015 at 06:26:59PM -0400, Kyle Meyer wrote:
> Oleh Krehel  writes:
> 
> > Why not just cherry-pick the commits from master onto maint, or the
> > other way around? That would result in no merge commits.
> 
> The result of doing that is IMO worse than many merge commits.  For each
> fix in maint, you'd end up with two commits that are linked only by a
> patch id (if there are no conflicts) and perhaps a reference in the
> message (e.g., if -x is used and there are no conflicts).  Merging
> allows you to manage a large set of changes, including conflicts,
> between upstream and downstream branches and to be sure about which
> commits a branch contains.

Indeed!  It's one of Git's upsides, why fight it?

> I think cherry picking should be limited to one-off cases where a fix
> lands in master and then it is later realized that it's needed in maint.

Well said.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Josiah Schwab  writes:

Hi Josiah,

>> As I understood, for Org mode some commits are applied to maint, and
>> then merged into master. Why?
>
> It may be helpful for you to do a some background reading on workflows
> with git.  Have you ever read the gitworkflows man page?
>
>   https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>
> This page discusses many of the questions you have raised.

Thanks for the link. I've read it, and it does make sense.  But making
sense doesn't make it more convenient. I can understand some feature
branch being merged, but is the workflow of applying a single commit to
maint and merging maint into master really the best that Git can offer?

Would it be so hard for Git to perform a single merge of master into
maint on release, while keeping them separate and cherry-picking
in-between for the sake of a clean linear history?  The easy way would
be to rewrite maint on each release, but perhaps Git can do better?

Oleh

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Achim Gratz  writes:

> Am 11.09.2015 um 13:59 schrieb Oleh Krehel:
>> What is the purpose of maint exactly?
>
> It's a bit short on the explanation side, but does that help?
>
> http://orgmode.org/worg/dev/index.html

It does help a bit.

> Also (not exactly the branch model ORg uses, but explains the issues
> in more detail):
>
> http://nvie.com/posts/a-successful-git-branching-model/
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> http://williamdurand.fr/2012/01/17/my-git-branching-model/
>
>> In Emacs git repository there's
>> master and emacs24. All commits apply to master first, while some are
>> cherry picked onto emacs24. The emacs24 branch will never be merged into
>> master: it's divergent and that's fine.
>
> You might want to check your facts (most recently, see for instance
> commit 59db4308b546).  Realitity simply doesn't conform to your
> world-view and the conclusions you draw from it are similarly
> distorted. Cherry-picking from master to emacs24 is actually fixing a
> mistake made when committing a bug-fix to master.

Well, there are only 5 commits since the last tag in the emacs-24
branch, the top one being a cherry-pick. I don't really see harm in
them, there are more cherry-picks in that branch.

What exactly is the advantage of having 2 commits in master for 1 commit
in maint? Besides the ease of merging maint into master and master into
maint or release? This ease of merging comes at the cost of ease of
examining the master, which is where most of the work should be anyway.

Now, please check my facts again. Is it true that Emacs doesn't have
maint and has instead a bunch of hanging branches for each release that
aren't meant to have master merged into them on release? If so, what
exactly is the advantage in applying a patch to a stable branch and then
merging it into master, instead of applying to patch to master and
cherry-picking it to the stable branch?

I'm not saying that I'm a Git expert or anything, far from it. But I
observe the Git history of Emacs and Org regularly, and both models seem
to be working fine for the users, release-wise. But the master branch of
Emacs looks a lot better than the master branch of Org, and I don't
understand the trade-off that Org's model offers to compensate for that
lack of prettiness.

Re: [O] Merge branch 'maint'

[Stefan Nobis]

Oleh Krehel  writes:

> Would it be so hard for Git to perform a single merge of master into
> maint on release, while keeping them separate and cherry-picking
> in-between for the sake of a clean linear history?

The question is not whether git is capable of doing this (there are
ways to accomplish this goal). The true question is: Do you really
want a linear history?

A linear history may look pretty, but at the same time you loose
information. In a big complex project that is also a dependency to
another complex project, a bit more ugly bookeeping may make
maintenance easier.

-- 
Until the next mail...,
Stefan.

Re: [O] Merge branch 'maint'

[Oleh Krehel]

Kyle Meyer  writes:

> Hello,
>
> Oleh Krehel  writes:
>
>> Hi all,
>>
>> Was the issue of abundant "Merge branch 'maint'" commit messages
>> discussed before? I couldn't find a reference...
>>
>> It's not a big deal, really, but I personally prefer to have linear
>> history with commits that actually do stuff. And it should be easy to
>> switch to this style: just use the "rebase" instead of the "merge"
>> command.
>>
>> Anyway, it's a small thing, and if Nicolas or Bastien strongly like the
>> merge method I won't bring it up again. But if they don't care either
>> way, I think it's better to start rebasing.
>
> While I'm all for rebasing unpushed commits, short-lived feature
> branches, and throw-away integration branches, your suggestion would
> frequently rewrite the history of a long-lived public branch.

Why not just cherry-pick the commits from master onto maint, or the
other way around? That would result in no merge commits.

I think it should be possible to rebase two branches without having to
rewrite the public history. As far as I understood, maint is a subset of
master, i.e. all commits that are in maint are in master as well. Is
that correct?

Oleh

Re: [O] Merge branch 'maint'

[Robert Klein]

Hi,

Oleh Krehel  wrote:

> Kyle Meyer  writes:
> 
> > Hello,
> >
> > Oleh Krehel  writes:
> >
> >> Hi all,
> >>
> >> Was the issue of abundant "Merge branch 'maint'" commit messages
> >> discussed before? I couldn't find a reference...
> >>
> >> It's not a big deal, really, but I personally prefer to have linear
> >> history with commits that actually do stuff. And it should be easy
> >> to switch to this style: just use the "rebase" instead of the
> >> "merge" command.
> >>
> >> Anyway, it's a small thing, and if Nicolas or Bastien strongly
> >> like the merge method I won't bring it up again. But if they don't
> >> care either way, I think it's better to start rebasing.
> >
> > While I'm all for rebasing unpushed commits, short-lived feature
> > branches, and throw-away integration branches, your suggestion would
> > frequently rewrite the history of a long-lived public branch.
> 
> Why not just cherry-pick the commits from master onto maint, or the
> other way around? That would result in no merge commits.
> 
> I think it should be possible to rebase two branches without having to
> rewrite the public history. As far as I understood, maint is a subset
> of master, i.e. all commits that are in maint are in master as well.
> Is that correct?

No.

I agree, the many merge commits in August/September look ugly right
after the 8.3/8.3.1 release. Maint and master will surely diverge more,
now...

Best regards
Robert

Re: [O] Merge branch 'maint'

[Kyle Meyer]

Oleh Krehel  writes:

> Why not just cherry-pick the commits from master onto maint, or the
> other way around? That would result in no merge commits.

The result of doing that is IMO worse than many merge commits.  For each
fix in maint, you'd end up with two commits that are linked only by a
patch id (if there are no conflicts) and perhaps a reference in the
message (e.g., if -x is used and there are no conflicts).  Merging
allows you to manage a large set of changes, including conflicts,
between upstream and downstream branches and to be sure about which
commits a branch contains.

I think cherry picking should be limited to one-off cases where a fix
lands in master and then it is later realized that it's needed in maint.

> I think it should be possible to rebase two branches without having to
> rewrite the public history. 

A rebase involving public commits will rewrite the public history
(except for the useless case where calling "git rebase" does nothing
because the branch is already up-to-date).

> As far as I understood, maint is a subset of master, i.e. all commits
> that are in maint are in master as well. Is that correct?

Yes.  As long as there aren't any new commits on maint that have yet to
be merged, running

   $ git log master..maint

will return empty and

  $ git log --oneline --no-merges maint..master

will show all commits new to master.

-- 
Kyle

[O] Merge branch 'maint'

[Oleh Krehel]

Hi all,

Was the issue of abundant "Merge branch 'maint'" commit messages
discussed before? I couldn't find a reference...

It's not a big deal, really, but I personally prefer to have linear
history with commits that actually do stuff. And it should be easy to
switch to this style: just use the "rebase" instead of the "merge"
command.

Anyway, it's a small thing, and if Nicolas or Bastien strongly like the
merge method I won't bring it up again. But if they don't care either
way, I think it's better to start rebasing.

Oleh

Re: [O] Merge branch 'maint'

[Kyle Meyer]

Hello,

Oleh Krehel  writes:

> Hi all,
>
> Was the issue of abundant "Merge branch 'maint'" commit messages
> discussed before? I couldn't find a reference...
>
> It's not a big deal, really, but I personally prefer to have linear
> history with commits that actually do stuff. And it should be easy to
> switch to this style: just use the "rebase" instead of the "merge"
> command.
>
> Anyway, it's a small thing, and if Nicolas or Bastien strongly like the
> merge method I won't bring it up again. But if they don't care either
> way, I think it's better to start rebasing.

While I'm all for rebasing unpushed commits, short-lived feature
branches, and throw-away integration branches, your suggestion would
frequently rewrite the history of a long-lived public branch.

--
Kyle