savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [savannah-help-public] GSL: switching from bzr to git


From: Bob Proulx
Subject: Re: [savannah-help-public] GSL: switching from bzr to git
Date: Sat, 28 Dec 2013 14:51:24 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Patrick,

Patrick Alken wrote:
>   I was hoping I could trouble you to again make HEAD point to a
> different branch by default for GSL. We would like our 'develop-1'
> branch to be the default HEAD. I think the command will be:

The problem is that you would be rewinding a publicly published master
branch.  That is always a bad thing to do.  Anyone who has cloned that
branch will be broken.  Because it is the master branch it will be the
default one cloned.  The master branch is one that is expected to have
an infinite lifetime.  They will need to take manual steps to fix the
broken clone.  Having run continuous integration builds and being an
advocate for CI builds I am sensitive that it will also break them too
for the same reason.

Sometimes mistakes are made and so we do things to correct mistakes.
That is just life.  I am happy to help fix something that is broken.
Previously when you had a broken master branch I was happy to correct
it.  But you are proposing to break it every time you make a release
as a standard release strategy.

I think you should use a different branch release strategy.  Many
others have been this way many times before.  Instead of trying to
invent a new process and tripping over the snags along the way I would
try to learn from the mistakes of others.  There are endless
discussions of release branch models.  I recommend that you choose one
of the many strategies already available.  That way the path is
already smoothed out.

Here is an overview of git specific workflows.  It does a good job of
documention possible branching work flows using git.  (Some branches
of which are routinely expected to be rewound.)

  https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

I did a quick web search and found this reference.  I can't say as I
worked through the article in enough detail to know if I agree with it
completely but on first pass it sounded like one of the reasonable and
nicely written ones.

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

I would follow one of the above branch and release strategies as a
known best practice.  It will avoid a lot of pain for others.

> Also I'd like to ask for this as a feature request in the web interface
> - the GSL team prefers the default branch to be associated with a major
> version number (ie: v1, v2, etc) so for each major release we'll
> probably want to update the default HEAD. I know github has a pull down
> menu on their web interface which allows users to update the remote HEAD
> settings (like the command above). Perhaps savannah could do something
> similar?

I personally would not want to encourage this behavior.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]