On Wed, Jan 07, 2015 at 12:40:35PM -0800, Stephen Morton wrote:
> My team is planning a transition to git. We're a big division in a
> corporate environment. I'm "the tools guy"; I guess the latest
> trendy term is DevOps.
> Our current workflow involves the equivalent of using cherry-pick to
> move approved bugfixes into the customer release branches. (1) We
> intend to maintain this workflow with git for the conceivable
> future.
> I can rewrite our existing cherry-picking scripts for use with git
> and that is *mostly *no problem, I think, except for one thing:
> merges. If a dev doesn't use fetch --rebase, there could at some
> point be a non-trivial merge as part of their series of commits.
> Merges, from what I understand, present a problem for cherry-pick. I
> can see two solutions at the moment.
>    1. Don't allow any merges in the branch to be cherry-picked from.
>       (This is a bugfixes-only branch, no massive feature work.)
>       We'll likely use some wrappers around git commands, to make
>       'fetch --rebase' happen automagically for devs. If a dev tries
>       to push a merge, block it and get them to do an interactive
>       rebase until the merge is removed. This might sound crazy, but
>       coming from a non-DVCS background it would not be a very
>       different from our old workflow.
>    2. Cherry-pick the merge by introducing what seems to me to be
>       likely hellishly complicated and error-prone code into the
>       cherry-picking script to try to determine the correct merge
>       parent to use when cherry-picking the merge.
> Obviously, I prefer #1 and include #2 only for completeness. But I
> don't really like #1 either.
> Does anybody have any thoughts on this? Preferences to these
> solutions, better versions of these solutions, additional different
> solutions, other ways of thinking about the problem?
> (While I'm mostly looking for "this is how you do it" comments, I
> welcome *constructive* "you should do it a different way" comments.
> But ones where you just say I'm crazy and doing it all wrong without
> knowing anything about the size of my team, our corporate culture,
> the number of customer release branches we have to support, the
> penalties we are liable for if bugs are introduced in the field,
> etc, are frankly not helpful at all.  Honestly, save your breath.
> :-)

I know you write you intend to maintain the current workflow for the
foreseeable future, but have you considered turning around the
direction of merges?  That is, make the change on the "customer
release branch" and then merge into the development branch?  (A better
description can be found in the first half of


Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

I invented the term Object-Oriented, and I can tell you I did not have
C++ in mind.
     -- Alan Kay

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: pgplW_IID79C0.pgp
Description: PGP signature

Reply via email to