Re: Emacs branches in git

[Bill Wohler <wohler@newt.com>]

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