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.