[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs branches in git
From: |
Bill Wohler |
Subject: |
Re: Emacs branches in git |
Date: |
Sun, 16 Feb 2014 16:36:49 -0800 |
Dmitry Gutov <address@hidden> wrote:
> Bill Wohler <address@hidden> 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 <address@hidden> aka <address@hidden>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
- Emacs branches in git, Bill Wohler, 2014/02/15
- Re: Emacs branches in git, Dmitry Gutov, 2014/02/16
- Re: Emacs branches in git, Bill Wohler, 2014/02/16
- Re: Emacs branches in git, David Kastrup, 2014/02/16
- Re: Emacs branches in git, Bill Wohler, 2014/02/16
- Re: Emacs branches in git, Dmitry Gutov, 2014/02/16
- Re: Emacs branches in git,
Bill Wohler <=
- Re: Emacs branches in git, Dmitry Gutov, 2014/02/16
- Re: Emacs branches in git, Andreas Schwab, 2014/02/17
- Re: Emacs branches in git, Thien-Thi Nguyen, 2014/02/17
- Re: Emacs branches in git, Xue Fuqiao, 2014/02/17