* Merge branch 'maint'
@ 2015-09-09 14:50 Oleh Krehel
2015-09-09 17:30 ` Kyle Meyer
0 siblings, 1 reply; 14+ messages in thread
From: Oleh Krehel @ 2015-09-09 14:50 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Merge branch 'maint'
2015-09-09 14:50 Merge branch 'maint' Oleh Krehel
@ 2015-09-09 17:30 ` Kyle Meyer
2015-09-10 10:48 ` Oleh Krehel
0 siblings, 1 reply; 14+ messages in thread
From: Kyle Meyer @ 2015-09-09 17:30 UTC (permalink / raw)
To: Oleh Krehel; +Cc: emacs-orgmode
Hello,
Oleh Krehel <ohwoeowho@gmail.com> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-09 17:30 ` Kyle Meyer
@ 2015-09-10 10:48 ` Oleh Krehel
2015-09-10 15:05 ` Robert Klein
2015-09-10 22:26 ` Kyle Meyer
0 siblings, 2 replies; 14+ messages in thread
From: Oleh Krehel @ 2015-09-10 10:48 UTC (permalink / raw)
To: Kyle Meyer; +Cc: emacs-orgmode
Kyle Meyer <kyle@kyleam.com> writes:
> Hello,
>
> Oleh Krehel <ohwoeowho@gmail.com> 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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Merge branch 'maint'
2015-09-10 10:48 ` Oleh Krehel
@ 2015-09-10 15:05 ` Robert Klein
2015-09-10 22:26 ` Kyle Meyer
1 sibling, 0 replies; 14+ messages in thread
From: Robert Klein @ 2015-09-10 15:05 UTC (permalink / raw)
To: Oleh Krehel; +Cc: Kyle Meyer, emacs-orgmode
Hi,
Oleh Krehel <ohwoeowho@gmail.com> wrote:
> Kyle Meyer <kyle@kyleam.com> writes:
>
> > Hello,
> >
> > Oleh Krehel <ohwoeowho@gmail.com> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-10 10:48 ` Oleh Krehel
2015-09-10 15:05 ` Robert Klein
@ 2015-09-10 22:26 ` Kyle Meyer
2015-09-11 11:59 ` Oleh Krehel
2015-09-11 13:08 ` Suvayu Ali
1 sibling, 2 replies; 14+ messages in thread
From: Kyle Meyer @ 2015-09-10 22:26 UTC (permalink / raw)
To: Oleh Krehel; +Cc: emacs-orgmode
Oleh Krehel <ohwoeowho@gmail.com> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-10 22:26 ` Kyle Meyer
@ 2015-09-11 11:59 ` Oleh Krehel
2015-09-11 12:58 ` Josiah Schwab
2015-09-11 13:40 ` Achim Gratz
2015-09-11 13:08 ` Suvayu Ali
1 sibling, 2 replies; 14+ messages in thread
From: Oleh Krehel @ 2015-09-11 11:59 UTC (permalink / raw)
To: Kyle Meyer; +Cc: emacs-orgmode
Kyle Meyer <kyle@kyleam.com> 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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Merge branch 'maint'
2015-09-11 11:59 ` Oleh Krehel
@ 2015-09-11 12:58 ` Josiah Schwab
2015-09-11 14:32 ` Oleh Krehel
2015-09-11 13:40 ` Achim Gratz
1 sibling, 1 reply; 14+ messages in thread
From: Josiah Schwab @ 2015-09-11 12:58 UTC (permalink / raw)
To: Oleh Krehel; +Cc: Kyle Meyer, emacs-orgmode
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-11 12:58 ` Josiah Schwab
@ 2015-09-11 14:32 ` Oleh Krehel
2015-09-11 15:25 ` Stefan Nobis
0 siblings, 1 reply; 14+ messages in thread
From: Oleh Krehel @ 2015-09-11 14:32 UTC (permalink / raw)
To: Josiah Schwab; +Cc: Kyle Meyer, emacs-orgmode
Josiah Schwab <jschwab@gmail.com> 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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Merge branch 'maint'
2015-09-11 14:32 ` Oleh Krehel
@ 2015-09-11 15:25 ` Stefan Nobis
2015-09-11 16:15 ` Oleh Krehel
0 siblings, 1 reply; 14+ messages in thread
From: Stefan Nobis @ 2015-09-11 15:25 UTC (permalink / raw)
To: emacs-orgmode
Oleh Krehel <ohwoeowho@gmail.com> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-11 15:25 ` Stefan Nobis
@ 2015-09-11 16:15 ` Oleh Krehel
0 siblings, 0 replies; 14+ messages in thread
From: Oleh Krehel @ 2015-09-11 16:15 UTC (permalink / raw)
To: emacs-orgmode
Stefan Nobis <stefan-ml@snobis.de> writes:
> Oleh Krehel <ohwoeowho@gmail.com> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-11 11:59 ` Oleh Krehel
2015-09-11 12:58 ` Josiah Schwab
@ 2015-09-11 13:40 ` Achim Gratz
2015-09-11 15:24 ` Oleh Krehel
1 sibling, 1 reply; 14+ messages in thread
From: Achim Gratz @ 2015-09-11 13:40 UTC (permalink / raw)
To: emacs-orgmode
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 :-)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-11 13:40 ` Achim Gratz
@ 2015-09-11 15:24 ` Oleh Krehel
2015-09-15 12:16 ` Nicolas Richard
0 siblings, 1 reply; 14+ messages in thread
From: Oleh Krehel @ 2015-09-11 15:24 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@Nexgo.DE> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-11 15:24 ` Oleh Krehel
@ 2015-09-15 12:16 ` Nicolas Richard
0 siblings, 0 replies; 14+ messages in thread
From: Nicolas Richard @ 2015-09-15 12:16 UTC (permalink / raw)
To: Oleh Krehel; +Cc: Achim Gratz, emacs-orgmode
Oleh Krehel <ohwoeowho@gmail.com> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Merge branch 'maint'
2015-09-10 22:26 ` Kyle Meyer
2015-09-11 11:59 ` Oleh Krehel
@ 2015-09-11 13:08 ` Suvayu Ali
1 sibling, 0 replies; 14+ messages in thread
From: Suvayu Ali @ 2015-09-11 13:08 UTC (permalink / raw)
To: emacs-orgmode
On Thu, Sep 10, 2015 at 06:26:59PM -0400, Kyle Meyer wrote:
> Oleh Krehel <ohwoeowho@gmail.com> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-09-15 12:16 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-09 14:50 Merge branch 'maint' Oleh Krehel
2015-09-09 17:30 ` Kyle Meyer
2015-09-10 10:48 ` Oleh Krehel
2015-09-10 15:05 ` Robert Klein
2015-09-10 22:26 ` Kyle Meyer
2015-09-11 11:59 ` Oleh Krehel
2015-09-11 12:58 ` Josiah Schwab
2015-09-11 14:32 ` Oleh Krehel
2015-09-11 15:25 ` Stefan Nobis
2015-09-11 16:15 ` Oleh Krehel
2015-09-11 13:40 ` Achim Gratz
2015-09-11 15:24 ` Oleh Krehel
2015-09-15 12:16 ` Nicolas Richard
2015-09-11 13:08 ` Suvayu Ali
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).