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 i
Simon Thum wrote:
> Hi Daniel,
>
> On 03/24/2012 12:05 PM, Daniel Dehennin wrote:
> > Simon Thum 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
Hi Daniel,
On 03/24/2012 12:05 PM, Daniel Dehennin wrote:
Simon Thum 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
cherry-picking.
I'm a bit bias
Simon Thum 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 development go to mas
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
Simon Thum 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 since he's the o
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 wha
Bastien writes:
> version, their lifespan is not much (expect now, while we are
^^
except
--
Bastien
Hi Achim,
Achim Gratz 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 branches should mer
Simon Thum 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, maint is boun
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
somewha
Bastien 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 regularily.
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 is
Hi Achim,
Achim Gratz writes:
> Bastien 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.
Achim Gratz 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 microQkb Andromeda
Bastien 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 to be done f
16 matches
Mail list logo
