Re: [O] [DEV] New git workflow

2012-04-01 Thread Simon Thum
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

Re: [O] [DEV] New git workflow

2012-03-24 Thread Nick Dokos
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

Re: [O] [DEV] New git workflow

2012-03-24 Thread Simon Thum
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

Re: [O] [DEV] New git workflow

2012-03-24 Thread Daniel Dehennin
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

Re: [O] [DEV] New git workflow

2012-03-21 Thread Simon Thum
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

Re: [O] [DEV] New git workflow

2012-03-21 Thread Achim Gratz
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

Re: [O] [DEV] New git workflow

2012-03-21 Thread Simon Thum
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

Re: [O] [DEV] New git workflow

2012-03-20 Thread Bastien
Bastien writes: > version, their lifespan is not much (expect now, while we are ^^ except -- Bastien

Re: [O] [DEV] New git workflow

2012-03-20 Thread 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

Re: [O] [DEV] New git workflow

2012-03-20 Thread Achim Gratz
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

Re: [O] [DEV] New git workflow

2012-03-20 Thread Simon Thum
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

Re: [O] [DEV] New git workflow

2012-03-20 Thread Achim Gratz
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.

Re: [O] [DEV] New git workflow

2012-03-20 Thread Bastien
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

Re: [O] [DEV] New git workflow

2012-03-20 Thread Bastien
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.

Re: [O] [DEV] New git workflow

2012-03-20 Thread Achim Gratz
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

Re: [O] [DEV] New git workflow

2012-03-20 Thread Achim Gratz
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