[DEV] New git workflow

[DEV] New git workflow

[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 feature or fixing something not yet released,
   commit to master.

On top of that, some local development happens in dedicated branches.

The role of master is clear: it contains latest mature developments,
which are either (1) bugfixes merged from maint, (2) features merged
from dedicated branches or (3) features developed in master directly.

The role of maint is less clear: it is both a "hotfix" branch and a
release branch for bugfix releases.  The reason for this branch was
first that we need to keep a production-like version of Org in sync 
with Emacs.  

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.

So I suggest to use three branches with these rules:

- master: the main persistent branch.  This is were regular development
  goes.  This branch is merged back to the maint branch when we release
  a new major version.  No release happens directly from this branch.

- maint: the "production" persistent branch.  This branch is dedicated
  to the release process: when hot fixes are hot enough, we merge the
  hotfix branch to the maint branch and release a bugfix release.  When
  the master branch (where hot fixes are also merged to) is mature and
  well tested, we merge master into maint and release a major version.

- hotfix-7.XX.XX: the transient branch for hotfixes.  Severe bugs are
  fixed there first, then merged back to maint when this makes sense.
  The branch is created when we need it and deleted when we don't need
  it anymore.

This workflow looks clearer to me.  Here are the advantages I see:

1) *all releases happen on the same branch* (the maint branch): it is
   easier to keep this branch in sync with Emacs and we can also add
   git hooks to automate the release process.

2) the master branch *is* the development branch: yes, pretty unusual.
   At least as unusual as not having two mailing lists, one for users
   and one for devs.  But I want to stick to what makes this list a
   great place: regular users are invited to live on the bleeding edge
   and to contribute patches on the "development" branch, the one they
   will clone first.

So, what's next?

I will merge 7.8.06 into Emacs.

Nothing should be committed to maint anymore before the next release.

Important bug fixes for 7.8.06 all go to a new branch hotfix-7.8.06.

Usual development goes to master, from where we regularily merge the
hotfix branch.

We'll get rid of the hotfix branch when releasing 7.8.07 or 7.9.

...

Finally, two positive things from the mess I put and went through: 
I learned more about git, and I experienced once again how patient
and helpful people can be on this list.  Thanks to all again!

-- 
 Bastien

Re: [DEV] New git workflow

[Achim Gratz]

Bastien <bzg@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 to be done from
maint (that's the whole purpose of it), preceded by a merge from master
if and only if a major release is done.

> So I suggest to use three branches with these rules:
>
> - master: the main persistent branch.  This is were regular development
>   goes.  This branch is merged back to the maint branch when we release
>   a new major version.  No release happens directly from this branch.
>
> - maint: the "production" persistent branch.  This branch is dedicated
>   to the release process: when hot fixes are hot enough, we merge the
>   hotfix branch to the maint branch and release a bugfix release.  When
>   the master branch (where hot fixes are also merged to) is mature and
>   well tested, we merge master into maint and release a major version.

So far no deviation from today.

> - hotfix-7.XX.XX: the transient branch for hotfixes.  Severe bugs are
>   fixed there first, then merged back to maint when this makes sense.
>   The branch is created when we need it and deleted when we don't need
>   it anymore.

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.  For instance,
Carsten has already committed to maint again, because he can't see your
bugfix branch.  All things considered, the hotfix branch and maint
should almost always point to the same commit.  In other words, all
hotfix branches should merge into maint first and then maint back into
master.  The only advantage of version-specific hotfix branches I can
see is if you want to be able to fix bugs in several releases seperately
(e.g. 7.8.06 in Emacs 24.1, 7.x.yy in Emacs 24.2 etc.).  Also, the setup
would have to be slightly different in that case: branch the hotfix from
the release commit and then keep adding bugfixes and merging into maint.
That would require an enormous amount of coordination and discipline
from all maintainers and committers, as several branches would have to
keep merging into both maint and master.

> This workflow looks clearer to me.

I suggest you try this first in a disposable repo clone, if possible
together with all other commiters to the public repo.  It is a valid
setup and suppports some things that you can't do very well today, but
it makes things more complicated than the current workflow (which maybe
need to be spelled out more explicitly).

>  Here are the advantages I see:
>
> 1) *all releases happen on the same branch* (the maint branch): it is
>    easier to keep this branch in sync with Emacs and we can also add
>    git hooks to automate the release process.

See above, that was always how it was supposed to work.

> 2) the master branch *is* the development branch: yes, pretty unusual.

Not really unusual, there are more examples of this.

>    At least as unusual as not having two mailing lists, one for users
>    and one for devs.  But I want to stick to what makes this list a
>    great place: regular users are invited to live on the bleeding edge
>    and to contribute patches on the "development" branch, the one they
>    will clone first.
>
> So, what's next?
>
> I will merge 7.8.06 into Emacs.
>
> Nothing should be committed to maint anymore before the next release.
>
> Important bug fixes for 7.8.06 all go to a new branch hotfix-7.8.06.
>
> Usual development goes to master, from where we regularily merge the
> hotfix branch.
>
> We'll get rid of the hotfix branch when releasing 7.8.07 or 7.9.

Once you've pushed it out to the repo you shouldn't delete it, even when
merged back into maint.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [DEV] New git workflow

[Achim Gratz]

Achim Gratz <Stromeko@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 microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [DEV] New git workflow

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien <bzg@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 to be done from
> maint (that's the whole purpose of it), preceded by a merge from master
> if and only if a major release is done.

Agreed.  What I want on top of this is a to have a branch where *every*
commit corresponds to a single release.

>> - master: the main persistent branch.  This is were regular development
>>   goes.  This branch is merged back to the maint branch when we release
>>   a new major version.  No release happens directly from this branch.
>>
>> - maint: the "production" persistent branch.  This branch is dedicated
>>   to the release process: when hot fixes are hot enough, we merge the
>>   hotfix branch to the maint branch and release a bugfix release.  When
>>   the master branch (where hot fixes are also merged to) is mature and
>>   well tested, we merge master into maint and release a major version.
>
> So far no deviation from today.

There is one important deviation: so far we could commit changes to
maint and _not_ make a release.  From now on, every commit to maint
should correspond to a release.

> All things considered, the hotfix branch and maint
> should almost always point to the same commit.  In other words, all
> hotfix branches should merge into maint first and then maint back into
> master.  

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.

My main goal is this: have a branch with one commit = one release.

>>  Here are the advantages I see:
>>
>> 1) *all releases happen on the same branch* (the maint branch): it is
>>    easier to keep this branch in sync with Emacs and we can also add
>>    git hooks to automate the release process.
>
> See above, that was always how it was supposed to work.

Yes.  

-- 
 Bastien

Re: [DEV] New git workflow

[Achim Gratz]

Bastien <bzg@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 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).  If it
changes name at every release, that just begs for a mix-up to happen
when you are preparing for release and someone else tries to do one more
fix.

> 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).

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.

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.  If
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.  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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [DEV] New git workflow

[Bastien]

Hi Achim,

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: 
http://nvie.com/posts/a-successful-git-branching-model/

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
trunk.

>> 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.

> If
> 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
hotfix-* branch.)

> 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.

-- 
 Bastien

Re: [DEV] New git workflow

[Bastien]

Bastien <bzg@altern.org> writes:

> version, their lifespan is not much (expect now, while we are 
                                       ^^^^^^
                                       except
-- 
 Bastien

Re: [DEV] New git workflow

[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 0: instead of committing fixes
to maint, we commit them to hotfix-*.

-- 
 Bastien

Re: [DEV] New git workflow

[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 
somewhat safer master to me - I fail to see a big difference between 
them. One may want to count that as a bonus; I don't. Part of the reason 
is that sometimes releases have commits that simply don't belong into 
master, like specific version increments.

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 master, fixes which should be 
back-ported are cherry-picked onto the release branches. When desired, a 
new release is tagged. Releases only come from release branches, of course.

If you like to see an example, the X server uses such a model:

http://cgit.freedesktop.org/xorg/xserver/

I guess a decision should mostly be based on how significant the use 
case "back-port fix" is to org-mode. The "safer master" role of maint 
could of course be retained in a stable branch which points to something 
like master@{1 month ago}.

Cheers,

Simon

On 03/20/2012 01:51 AM, Bastien wrote:
> 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 feature or fixing something not yet released,
>     commit to master.
>
> On top of that, some local development happens in dedicated branches.
>
> The role of master is clear: it contains latest mature developments,
> which are either (1) bugfixes merged from maint, (2) features merged
> from dedicated branches or (3) features developed in master directly.
>
> The role of maint is less clear: it is both a "hotfix" branch and a
> release branch for bugfix releases.  The reason for this branch was
> first that we need to keep a production-like version of Org in sync
> with Emacs.
>
> 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.
>
> So I suggest to use three branches with these rules:
>
> - master: the main persistent branch.  This is were regular development
>    goes.  This branch is merged back to the maint branch when we release
>    a new major version.  No release happens directly from this branch.
>
> - maint: the "production" persistent branch.  This branch is dedicated
>    to the release process: when hot fixes are hot enough, we merge the
>    hotfix branch to the maint branch and release a bugfix release.  When
>    the master branch (where hot fixes are also merged to) is mature and
>    well tested, we merge master into maint and release a major version.
>
> - hotfix-7.XX.XX: the transient branch for hotfixes.  Severe bugs are
>    fixed there first, then merged back to maint when this makes sense.
>    The branch is created when we need it and deleted when we don't need
>    it anymore.
>
> This workflow looks clearer to me.  Here are the advantages I see:
>
> 1) *all releases happen on the same branch* (the maint branch): it is
>     easier to keep this branch in sync with Emacs and we can also add
>     git hooks to automate the release process.
>
> 2) the master branch *is* the development branch: yes, pretty unusual.
>     At least as unusual as not having two mailing lists, one for users
>     and one for devs.  But I want to stick to what makes this list a
>     great place: regular users are invited to live on the bleeding edge
>     and to contribute patches on the "development" branch, the one they
>     will clone first.
>
> So, what's next?
>
> I will merge 7.8.06 into Emacs.
>
> Nothing should be committed to maint anymore before the next release.
>
> Important bug fixes for 7.8.06 all go to a new branch hotfix-7.8.06.
>
> Usual development goes to master, from where we regularily merge the
> hotfix branch.
>
> We'll get rid of the hotfix branch when releasing 7.8.07 or 7.9.
>
> ...
>
> Finally, two positive things from the mess I put and went through:
> I learned more about git, and I experienced once again how patient
> and helpful people can be on this list.  Thanks to all again!
>

Re: [DEV] New git workflow

[Achim Gratz]

Simon Thum <simon.thum@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, maint is bound quite tightly to master. maint seems like a
> somewhat safer master to me - I fail to see a big difference between
> them.

That's what it was designed to be, a way for people with (and more so
without) git access to access the latest bugfixes without the vagaries
of evolving new features.

> One may want to count that as a bonus; I don't. Part of the
> reason is that sometimes releases have commits that simply don't
> belong into master, like specific version increments.
>
> 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 master, fixes which should be
> back-ported are cherry-picked onto the release branches. When desired,
> a new release is tagged. Releases only come from release branches, of
> course.

Sorry, but cherry-picking into multiple release branches would simply
not be a sane development model for a small project like orgmode.

> I guess a decision should mostly be based on how significant the use
> case "back-port fix" is to org-mode. The "safer master" role of maint
> could of course be retained in a stable branch which points to
> something like master@{1 month ago}.

Any point in the past is no safer than today's master.  The stability
that maint should provide to users is with regards to the feature set,
i.e. no gratuitous changes between releases.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [DEV] New git workflow

[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 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.

>
>> I guess a decision should mostly be based on how significant the use
>> case "back-port fix" is to org-mode. The "safer master" role of maint
>> could of course be retained in a stable branch which points to
>> something like master@{1 month ago}.
>
> Any point in the past is no safer than today's master.  The stability
> that maint should provide to users is with regards to the feature set,
> i.e. no gratuitous changes between releases.

Ooops, I just wanted to illustrate that "stable" is typically behind 
master - ultimately it should be a concious decision what is "stable".

I like the goal maint is set to achieve, I'm just not convinced regular 
merges are a good way to ensure it - after all, merges include 
everything in a branch. If there are no doubts about that on your side, 
I'm fine.

Cheers,

Simon

Re: [DEV] New git workflow

[Achim Gratz]

Simon Thum <simon.thum@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 since he's the one doing the
maintenance.

> I like the goal maint is set to achieve, I'm just not convinced
> regular merges are a good way to ensure it - after all, merges include
> everything in a branch. If there are no doubts about that on your
> side, I'm fine.

It was intended as a solution to the problem of either not getting
bugfixes for the latest release or having to live on bleeding edge.  It
was too shortlived to judge if it had achieved that goal and how
satisfied people were with it.  Bastien is now trying a three-branch
model since he also needs to maintain org within Emacs(*).  As long as it
works for him it will work for us, I'd think.

(*) This should provide similar benefits to users as maint was supposed
to, albeit it may not be obvious to users on how to follow that branch.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [DEV] New git workflow

[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 10:01 AM, Achim Gratz wrote:
> Simon Thum<simon.thum@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 since he's the one doing the
> maintenance.
>
>> I like the goal maint is set to achieve, I'm just not convinced
>> regular merges are a good way to ensure it - after all, merges include
>> everything in a branch. If there are no doubts about that on your
>> side, I'm fine.
>
> It was intended as a solution to the problem of either not getting
> bugfixes for the latest release or having to live on bleeding edge.  It
> was too shortlived to judge if it had achieved that goal and how
> satisfied people were with it.  Bastien is now trying a three-branch
> model since he also needs to maintain org within Emacs(*).  As long as it
> works for him it will work for us, I'd think.
>
> (*) This should provide similar benefits to users as maint was supposed
> to, albeit it may not be obvious to users on how to follow that branch.
>
>
> Regards,
> Achim.

Re: [DEV] New git workflow

[Daniel Dehennin]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

Simon Thum <simon.thum@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 development go to master, fixes which should be
> back-ported are cherry-picked onto the release branches. When desired,
> a new release is tagged. Releases only come from release branches, of
> course.

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.

My 2¢.

Regards.

Footnotes: 
[1]  http://mercurial.selenic.com/wiki/DaggyFixes

[2]  http://wiki.monotone.ca/DaggyFixes/

[3]  http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [DEV] New git workflow

[Simon Thum]

Hi Daniel,

On 03/24/2012 12:05 PM, Daniel Dehennin wrote:
> Simon Thum<simon.thum@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
> cherry-picking.

I'm a bit biased as I mainly have git experience but to me it seems that 
both cherry-picking and daggy fixes have their strengths and weaknesses, 
and I'd rather have them both in all the VCSes but needless fights over 
which one is ultimately superior. Git should probably learn that thing, IMO.

Cheers,

Simon

>
> My 2¢.
>
> Regards.
>
> Footnotes:
> [1]  http://mercurial.selenic.com/wiki/DaggyFixes
>
> [2]  http://wiki.monotone.ca/DaggyFixes/
>
> [3]  http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from
>

Re: [DEV] New git workflow

[Nick Dokos]

Simon Thum <simon.thum@gmx.de> wrote:

> Hi Daniel,
> 
> On 03/24/2012 12:05 PM, Daniel Dehennin wrote:
> > Simon Thum<simon.thum@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
> > cherry-picking.
> 
> I'm a bit biased as I mainly have git experience but to me it seems
> that both cherry-picking and daggy fixes have their strengths and
> weaknesses, and I'd rather have them both in all the VCSes but
> needless fights over which one is ultimately superior. Git should
> probably learn that thing, IMO.
> 

I'm probably missing something but what's there to learn? You check out
the offending commit, make a branch off of it, commit the fix on the
branch, give it a tag (so you can find it easily later on) and then
merge it back anywhere you want. AFAICT, that's all there is to
daggy-fixes and git is perfectly capable of doing that - no?

Nick

> >
> > Footnotes:
> > [1]  http://mercurial.selenic.com/wiki/DaggyFixes
> >
> > [2]  http://wiki.monotone.ca/DaggyFixes/
> >
> > [3]  http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from
> >
> 
> 

Re: [DEV] New git workflow

[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 is it would have looked when done right 
from the first day on, and the fix as it looks when introduced later.

Daggy fixes' mental image is to incrementally fix your release branches 
(or how you call them) each the in way it needs to be fixed. 
Cherry-picking usually implies (but does not mandate!) fix on master, 
then go back. Git's support for the other way round could be better, 
e.g. by introducing a DAGGY_FIX_HEAD and repo mode so you don't need to 
alternate cherry-pick, tag, checkout, ...

To me the mental image behind is the main difference, and what is better 
depends on the fix and the project and what not.

Just my 2c.

Cheers,

Simon

On 03/24/2012 08:29 PM, Nick Dokos wrote:
> Simon Thum<simon.thum@gmx.de>  wrote:
>
>> Hi Daniel,
>>
>> On 03/24/2012 12:05 PM, Daniel Dehennin wrote:
>>> Simon Thum<simon.thum@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
>>> cherry-picking.
>>
>> I'm a bit biased as I mainly have git experience but to me it seems
>> that both cherry-picking and daggy fixes have their strengths and
>> weaknesses, and I'd rather have them both in all the VCSes but
>> needless fights over which one is ultimately superior. Git should
>> probably learn that thing, IMO.
>>
>
> I'm probably missing something but what's there to learn? You check out
> the offending commit, make a branch off of it, commit the fix on the
> branch, give it a tag (so you can find it easily later on) and then
> merge it back anywhere you want. AFAICT, that's all there is to
> daggy-fixes and git is perfectly capable of doing that - no?
>
> Nick
>
>>>
>>> Footnotes:
>>> [1]  http://mercurial.selenic.com/wiki/DaggyFixes
>>>
>>> [2]  http://wiki.monotone.ca/DaggyFixes/
>>>
>>> [3]  http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from
>>>
>>
>>
>