Hi Nick,
I did not mean to imply git is not capable of working that way. It's
more a question of what is accepted practice and most importantly, what
fits the problem you actually have.
The difference between both approaches, it seems to me, shows when there
is a difference between the fix
Simon Thum simon.t...@gmx.de writes:
Hi all,
Hello,
[...]
Many projects use the IMO more sane model of release branches (or
maintenance branches, if you prefer) for major releases. Minor ones
are tagged on those branches, and back-porting critical fixes is much
cleaner: Fixes and
Hi Daniel,
On 03/24/2012 12:05 PM, Daniel Dehennin wrote:
Simon Thumsimon.t...@gmx.de writes:
It seems that one problem with cherry-picking is the tracking of what is
in which branch and from where it comes.
I'm not a git neither DVCS guru, but daggyfixes[1][2][3] is saner than
Simon Thum simon.t...@gmx.de wrote:
Hi Daniel,
On 03/24/2012 12:05 PM, Daniel Dehennin wrote:
Simon Thumsimon.t...@gmx.de writes:
It seems that one problem with cherry-picking is the tracking of what is
in which branch and from where it comes.
I'm not a git neither DVCS guru, but
Hi Achim,
On 03/20/2012 11:27 PM, Achim Gratz wrote:
Sorry, but cherry-picking into multiple release branches would simply
not be a sane development model for a small project like orgmode.
I just wanted to make sure it's considered.
Whether multiple branches are involved depends mainly on
Simon Thum simon.t...@gmx.de writes:
Whether multiple branches are involved depends mainly on what releases
one intends to maintain. The nice thing in the model is the gradual
maintenance: A really critical fix could see more backports than a
nicety.
Yes. Bastien has to make that decision
Hi Achim and Bastien,
in case you fancy with the release-branch model now or in the
foreseeable future, I'll probably be able to take over some of the work
load in case it's a deciding factor. I've done that locally when
necessary, and can claim enough git-foo.
Cheers,
Simon
On 03/21/2012
Bastien b...@altern.org writes:
The main problem I see With this workflow is that releases are made
from two different branches: bugfix releases are made from maint and
major releases are made from master. This doesn't look right to me.
That ain't necessarily so. IMHO, the release always has
Achim Gratz strom...@nexgo.de writes:
You would have to push this branch out to the public repo, otherwise the
other people with access to the repo can't use it.
I see you already did, had to reconfigure my refspecs for it to show up.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron
Hi Achim,
Achim Gratz strom...@nexgo.de writes:
Bastien b...@altern.org writes:
The main problem I see With this workflow is that releases are made
from two different branches: bugfix releases are made from maint and
major releases are made from master. This doesn't look right to me.
That
Let me summarise why I propose this new workflow:
1. Users will have a way to track *only releases* from git.
2. We will be able to use git hooks in order to automate the
release process on the server.
3. The workflow looks clearer to me (may be 100% subjective.)
The cost of the new setup
Bastien b...@gnu.org writes:
Agreed. What I want on top of this is a to have a branch where *every*
commit corresponds to a single release.
Fair enough: a three-branch model with a release branch at the side of
bugfixing and bleeding edge.
No. All hotfix branches should merge into master
Hi all,
as discussion started anyway, I'd like to mention that I see some
problem with maint, that is, it only ever pertains to the latest
release. It's hard to hotfix and release old versions in the proposed model.
Moreover, maint is bound quite tightly to master. maint seems like a
Simon Thum simon.t...@gmx.de writes:
as discussion started anyway, I'd like to mention that I see some
problem with maint, that is, it only ever pertains to the latest
release. It's hard to hotfix and release old versions in the proposed
model.
IMHO, that was never the objective.
Moreover,
Hi Achim,
Achim Gratz strom...@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:
http://nvie.com/posts/a-successful-git-branching-model/
with some simplifications.
No. All hotfix
Bastien b...@altern.org writes:
version, their lifespan is not much (expect now, while we are
^^
except
--
Bastien
Hi all,
our current git workflow is pretty well summarised by Achim -- we have
two main branches, master and maint, and we (try to) follow these rules:
If it's a bugfix for something broken in a release version, commit to
maint and merge maint back into master.
If implementing a new
17 matches
Mail list logo
