On Wednesday, 7 January 2015 20:22:46 UTC-5, Stephen Morton wrote: > > On Wednesday, 7 January 2015 17:20:08 UTC-5, Magnus Therning wrote: >> >> 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 >> <http://stackoverflow.com/a/2558501/34996>.) >> >> /M >> >> > That is a good point, and is actually what we do. I was trying to provide > a simplified description of what we do. We have a sort of "continuous > integration ++" system. So devs commit to the pre-customer branch and it > undergoes normal continuous automated integration testing on the way there. > But before it is ready to be shipped in a customer load it must undergo > some degree of targeted testing that only a human can define or gate. and > that will take an unknown amount of time for all sorts of reasons -- from > hours to months. It is only after this point that it is cherry-picked into > the final customer branch. > > Steve > > Actually, would option #2 be that hard? Presumably, if I have a bugfix to cherrypick which consists of a bunch of regular commits and one or more merge commits, I *can *figure out which parent in the merge I want to diff against. I just need to figure out which merge parent contains the other commits of interest. Or at least, which one has the shortest path to a commit of interest. (Or something like that.)
I'm sure there are some pathological cases one could concoct to prove this is impossible. But but given a normal dev working on one computer with their work in one clone and only pulling off the central master server, or even perhaps two different devs working on different aspects of the same bugfix, I'm beginning to think that it wouldn't be too bad at all. Comments? Steve -- 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.
