Emacs branches in git

Emacs branches in git

[Bill Wohler]

I missed the transition discussion in January, but it doesn't look like
I missed the transition :-).

I didn't see any discussion about branching conventions in regards to
release strategy and branch namespaces. I apologize if I missed it.

For a release strategy, the one espoused in this page is popular:

    http://nvie.com/posts/a-successful-git-branching-model/

I'd also recommend against a flat branch namespace in the upstream
repository. Here are some thoughts on dividing the branches, including
dev and master for completeness:

master: For tagged releases.

dev: How trunk is used now.

releases: Release branches, such as releases/emacs-24

features: Larger features, such as features/gnus or features/mh-e.

topics: Ephemeral feature or bugfix branches, such as topics/vc-git or
topics/16694.

bugs: Perhaps folks might prefer bugs/16694 instead.

The latter two namespaces would mostly only live in the developer's
repository, but it would be good to have a convention in case they are
pushed for sharing.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Emacs branches in git

[Dmitry Gutov]

Bill Wohler <wohler@newt.com> writes:

> master: For tagged releases.
>
> dev: How trunk is used now.

Why is that?

1. People can put tags on revisions in release branches. Why dedicate a
branch just for release tags?

2. I suspect that at least some releases won't be direct descendants of
one another. I.e. there won't be a way to have all release revisions on
one branch.

Re: Emacs branches in git

[Bill Wohler]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Bill Wohler <wohler@newt.com> writes:
>
>> master: For tagged releases.
>>
>> dev: How trunk is used now.
>
> Why is that?
>
> 1. People can put tags on revisions in release branches. Why dedicate a
> branch just for release tags?

Please see http://nvie.com/posts/a-successful-git-branching-model/ for
the rationale. Also, in git, release branches are deleted when they are
no longer needed.

> 2. I suspect that at least some releases won't be direct descendants of
> one another. I.e. there won't be a way to have all release revisions on
> one branch.

Yes, that is one reason why you want to tag on master.

As a related aside, I find that after tagging a release on master, it is
helpful to merge master into the release branch and then in into dev.
That way, "git describe" can refer to a reasonable tag no matter which
branch you are on.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Emacs branches in git

[David Kastrup]

Bill Wohler <wohler@newt.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> Bill Wohler <wohler@newt.com> writes:
>>
>>> master: For tagged releases.
>>>
>>> dev: How trunk is used now.
>>
>> Why is that?
>>
>> 1. People can put tags on revisions in release branches. Why dedicate a
>> branch just for release tags?
>
> Please see http://nvie.com/posts/a-successful-git-branching-model/ for
> the rationale. Also, in git, release branches are deleted when they are
> no longer needed.

You are talking past each other.  You want to organize tags into a
directory of tags, Dmitry is talking about placing tags all into a
single branch.  Which makes very little sense.  But it's not obvious to
casual users of gits that you can have tags in a directory structure
that has nothing to do with either the work directory or the commit
tree.

-- 
David Kastrup

Re: Emacs branches in git

[Bill Wohler]

David Kastrup <dak@gnu.org> writes:

> Bill Wohler <wohler@newt.com> writes:
>
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> Bill Wohler <wohler@newt.com> writes:
>>>
>>>> master: For tagged releases.
>>>>
>>>> dev: How trunk is used now.
>>>
>>> Why is that?
>>>
>>> 1. People can put tags on revisions in release branches. Why dedicate a
>>> branch just for release tags?
>>
>> Please see http://nvie.com/posts/a-successful-git-branching-model/ for
>> the rationale. Also, in git, release branches are deleted when they are
>> no longer needed.
>
> You are talking past each other.  You want to organize tags into a
> directory of tags,

s/tags/branches/

> Dmitry is talking about placing tags all into a
> single branch.  Which makes very little sense.

Except that's not the point, but rather a side-effect. The point is that
master holds the production-ready commits.

>  But it's not obvious to
> casual users of gits that you can have tags in a directory structure
> that has nothing to do with either the work directory or the commit
> tree.

Can you expound on that?

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Emacs branches in git

[Dmitry Gutov]

Bill Wohler <wohler@newt.com> writes:

>>> Please see http://nvie.com/posts/a-successful-git-branching-model/ for
>>> the rationale.

I don't see any justification there, except "We consider origin/master
to be ... a production-ready state." Which is just an arbitrary opinion.

>>> Also, in git, release branches are deleted when they are
>>> no longer needed.

So what? Tags can live on.

>> You are talking past each other.  You want to organize tags into a
>> directory of tags,
>
> s/tags/branches/

??

>> Dmitry is talking about placing tags all into a
>> single branch.  Which makes very little sense.

If master is to be used "for tagged releases", all release-tagged
revisions have to be able to line up in one branch. Interspersed with
plain revisions, of course.

> Except that's not the point, but rather a side-effect. The point is that
> master holds the production-ready commits.

Yes, and why do we need that? If one wants to use the latest release,
they can just fetch the list of tags, and then checkout the one with the
greatest number.

>> But it's not obvious to
>> casual users of gits that you can have tags in a directory structure
>> that has nothing to do with either the work directory or the commit
>> tree.
>
> Can you expound on that?

Yes, please.

Re: Emacs branches in git

[Bill Wohler]

Dmitry Gutov <dgutov@yandex.ru> wrote:

> Bill Wohler <wohler@newt.com> writes:
> 
> >>> Please see http://nvie.com/posts/a-successful-git-branching-model/ for
> >>> the rationale.
> 
> I don't see any justification there, except "We consider origin/master
> to be ... a production-ready state." Which is just an arbitrary opinion.

OK, it might not have justification, but it isn't arbitrary. What is the
justification for *not* doing this?

> >>> Also, in git, release branches are deleted when they are
> >>> no longer needed.
> 
> So what? Tags can live on.

Except you will no longer see them in git log output.

> >> You are talking past each other.  You want to organize tags into a
> >> directory of tags,
> >
> > s/tags/branches/
> 
> ??

I was suggesting directories of branches, not tags. Regardless of where
you tag, creating a hierarchy of branches would help clean things up and
make things easier to find.

Can you organize tags into a directory, and would "git tag" only list
the directory? That would be neat, because then I could put, for
example, the MH-E tags into a subdirectory so Emacs users would not have
them in their "git tags" output.

> >> Dmitry is talking about placing tags all into a
> >> single branch.  Which makes very little sense.
>
> If master is to be used "for tagged releases", all release-tagged
> revisions have to be able to line up in one branch. Interspersed with
> plain revisions, of course.
> 
> > Except that's not the point, but rather a side-effect. The point is that
> > master holds the production-ready commits.
> 
> Yes, and why do we need that? If one wants to use the latest release,
> they can just fetch the list of tags, and then checkout the one with the
> greatest number.

While an expert might have a lot more reasons, a couple of things that
come to mind are:

- Looking for and checking out a tag is more work than "git
  checkout master".
- Conversely, if master tracked the release version, you just have to do
  a "git pull" to stay up to date with the latest released version.
- Checking out a tag doesn't work if you have continuous integration.
  Granted, you wouldn't have CI with master in this scheme, but the
  generalization may apply elsewhere.
- Checking out a tagged version puts you in a "detached HEAD" state for
  better or for worse.
- git log master would yield a concise history of releases.

Since branches are cheap, why not?

> >> But it's not obvious to
> >> casual users of gits that you can have tags in a directory structure
> >> that has nothing to do with either the work directory or the commit
> >> tree.
> >
> > Can you expound on that?
> 
> Yes, please.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Emacs branches in git

[Dmitry Gutov]

On 17.02.2014 02:36, Bill Wohler wrote:
> OK, it might not have justification, but it isn't arbitrary. What is the
> justification for *not* doing this?

As far as I'm concerned, it subverts the meaning of "master". That's 
just one opinion, though.

>> So what? Tags can live on.
>
> Except you will no longer see them in git log output.

Why not? A tag just marks a commit. If the tagged commits are in a 
certain branch's history, and you call 'git log' while it's checked out, 
the tags will show up.

For example, if all release branches are eventually merged into 'devel', 
its 'git log' will show all tags.

> I was suggesting directories of branches, not tags. Regardless of where
> you tag, creating a hierarchy of branches would help clean things up and
> make things easier to find.

If you mean the naming conventions for the other branches, then yeah, 
they look okay to me.

> Can you organize tags into a directory, and would "git tag" only list
> the directory? That would be neat, because then I could put, for
> example, the MH-E tags into a subdirectory so Emacs users would not have
> them in their "git tags" output.

git tag | grep ^foo ?

> - Looking for and checking out a tag is more work than "git
>    checkout master".
> - Conversely, if master tracked the release version, you just have to do
>    a "git pull" to stay up to date with the latest released version.

I wonder how popular would that be. ATM, people who build from the 
repository usually stay with the trunk. Because it's stable most of the 
time, and offers the latest features.

> - git log master would yield a concise history of releases.

Plain 'git log' wouldn't, since it shows the full branch history. But 
yes, you'd be able to limit the history to only merge or non-merge 
commits with additional argument.

But this would also work for non-"stable" master or devel.

Re: Emacs branches in git

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.02.2014 02:36, Bill Wohler wrote:
>> Can you organize tags into a directory, and would "git tag" only list
>> the directory? That would be neat, because then I could put, for
>> example, the MH-E tags into a subdirectory so Emacs users would not have
>> them in their "git tags" output.
>
> git tag | grep ^foo ?

git tag -l foo/*

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Emacs branches in git

[Thien-Thi Nguyen]

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

() Dmitry Gutov <dgutov@yandex.ru>
() Mon, 17 Feb 2014 04:22:43 +0200

   > OK, it might not have justification, but it isn't arbitrary.  What
   > is the justification for *not* [using "master" for named releases]?

   As far as I'm concerned, it subverts the meaning of "master".
   That's just one opinion, though.

Well, it's possible to have a repo w/o "master" (e.g., all my local
repos), so there is really no inherent meaning tied to that branch name.

I prefer branch discipline ((re-)naming, operation, role in the DAG) to
be explicit, and like the scheme on the referenced page very much, the
only exception being the name "master".  If that were renamed "public"
or "archive", for example, then it would be perfect (IMHO).  This way,
the name reflects the function, and we sidestep the potential confusion
of "conventional meanings" (insert "so many standards" smirk, here).

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs branches in git

[Xue Fuqiao]

Dmitry Gutov <dgutov@yandex.ru> writes:

> As far as I'm concerned, it subverts the meaning of "master". That's
> just one opinion, though.

In the famous "Pro Git"[fn:1]:

[...]
  Many Git developers have a workflow that embraces this approach, such
  as having only code that is entirely stable in their `master' branch —
  possibly only code that has been or will be released. They have
  another parallel branch named develop or next that they work from or
  use to test stability — it isn’t necessarily always stable, but
  whenever it gets to a stable state, it can be merged into `master'.
[...]
  You can keep doing this for several levels of stability. Some larger
  projects also have a `proposed' or `pu' (proposed updates) branch that
  has integrated branches that may not be ready to go into the `next' or
  `master' branch. The idea is that your branches are at various levels
  of stability; when they reach a more stable level, they’re merged into
  the branch above them.

Footnotes:

[fn:1] http://git-scm.com/book/en/Git-Branching-Branching-Workflows

-- 
http://www.gnu.org/software/emacs/