From: Bastien <email@example.com>
To: Achim Gratz <Stromeko@nexgo.de>
Subject: Re: [DEV] New git workflow
Date: Wed, 21 Mar 2012 01:02:30 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <87haxjkrki.fsf@Rainer.invalid> (Achim Gratz's message of "Tue, 20 Mar 2012 20:20:13 +0100")
Achim Gratz <Stromeko@nexgo.de> writes:
> Fair enough: a three-branch model with a release branch at the side of
> bugfixing and bleeding edge.
This is directly inspired from this:
with some simplifications.
>> No. All hotfix branches should merge into master regularily. When
>> hotfix contains enough fixes for a bugfix release, then we merge it to
>> maint, and process with release.
> This is what I think is confusing: the bugfix branch (be it maint or any
> other) should always have the same _unless_ you want to track release
> specific bugfixes (which I don't think you do, but you tell me).
I mostly want to track wrt-last-Emacs-merge specific bugs.
I used the naming convention hotfix-* as suggested above because
I like the idea of deleting such a branch once we don't need it
anymore (i.e. once a release has been done.) Since hotfix-* role
is to contain fixes for severe bugs against the last production
version, their lifespan is not much (expect now, while we are
testing this workflow, and while the forthcoming Emacs release
puts some heat on getting as much bugfixes committed to the
next 7.8.07 Org version.)
If we keep a persistent maint branch, I guess we will tend to
put all bugfixes there -- which I don't want. But which could
make sense if those bugfixes are regularily merged back to Emacs
>> My main goal is this: have a branch with one commit = one release.
> Why not name it release then and keep maint for fixes? You could even
> install that release branch retro-actively if you want. BTW, this also
> means you need to prepare the release on the hotfix branch, no
> fier-upper on the release allowed at all (since you would need to merge
> that back).
Indeed. As for the names, I don't care, I just don't want to change
things that are just conventions.
> But as I said before, clone the repo, branch off the 7.7 release or so
> and re-trace the following releases via cherry-pick according to that
> new development model. You will quickly learn if what you have to do
> feels right and if you commit to that model you will have practised the
> moves a few times already.
Good idea. I will try.
> Another thing that I'd recommend is to not work on the public repo _at
> all_ and specifically never push to it, especially not automatically.
> The public repo should be "bare" (without a work tree) and any work on
> the server should use a clone of that repo, just like anyone else.
Mhh.. something I don't get here: why should we not work on the public
repo? This is the repo many people are cloning.
> you prepare the releases on a fresh clone apart from the development
> clone, you have a stable base to work from and can nuke with no
> consequences if something goes wrong.
(We prepare major releases on the development branch, minor ones on the
> Git was designed to make merges
> easier, but they are hard and I still botch about every tenth that I try
> unless they are really trivial. Once the release repo is finished, have
> it reviewed and then pull from it on the public repo. The reason is
> that it is easy to push from the wrong branch onto the wrong target, but
> you really have to try to do that when pulling. You can be more liberal
> with the normal development and bugfixing work on the development repo,
> but it would still be a good idea to have commits reviewed and signed
> off by another person before they are pulled into public.
Okay, I now understand the problem of pushing from the wrong repo ;)
Well, this is a trade-off. If developers are willing to follow these
rules, okay. But I don't feel like imposing them to everyone --
especially because paying a little more attention might be enough to
avoid the mess I did.
Again, thanks for sharing this.
Let's continue with the model I suggest and see what is better and
what should be fixed.
next prev parent reply other threads:[~2012-03-21 0:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 0:51 [DEV] New git workflow Bastien
2012-03-20 7:03 ` Achim Gratz
2012-03-20 7:24 ` Achim Gratz
2012-03-20 10:40 ` Bastien
2012-03-20 19:20 ` Achim Gratz
2012-03-21 0:02 ` Bastien [this message]
2012-03-21 0:23 ` Bastien
2012-03-20 10:47 ` Bastien
2012-03-20 22:35 ` Simon Thum
2012-03-20 22:27 ` Achim Gratz
2012-03-21 8:46 ` Simon Thum
2012-03-21 9:01 ` Achim Gratz
2012-03-21 22:38 ` Simon Thum
2012-03-24 11:05 ` Daniel Dehennin
2012-03-24 20:08 ` Simon Thum
2012-03-24 19:29 ` Nick Dokos
2012-04-01 9:26 ` Simon Thum
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).