On Tue, 9 Dec 2008, R. Tyler Ballance wrote: > On Tue, 2008-12-09 at 19:17 +0900, Nanako Shiraishi wrote: > > Quoting "R. Tyler Ballance" <tyler@xxxxxxxxx>: > > > > > The most common use-case involves a user merging a project branch into a > > > stabilization branch (`git checkout stable && git pull . project`) in > > > such a way that no merge commit is generated. Of course, without > > > thinking they'll push these changes up to the centralized repository. > > > Not 15 minutes later they realize "ruh roh! I didn't want to do that" > > > > Why does the user not want to fast-forward, if the merge she wants to do is actually a fast-forward? > > I agree with you, this is more about preventing coworkers who are too > lazy to understand the entirety of what they're doing from hurting the > workflow of "the rest of us". It's a technically solution to a people > problem (I understand technology far more than people ;)) > > Consider the following scenarion: > % git checkout -b project > % <work> > % git commit -am "A" > % <work> > % git commit -am "B" > % <work> > % git commit -am "C" > % <work> > % git commit -am "D" > % git checkout stable > % git pull . project > % <fast-forward> > % git push origin stable > > At this point, QA is involved and what can happen is that QA realizes > that this code is *not* stable and *never* should have been brought into > the stable branch. How do you prevent the (IMHO more likely) case of: % git checkout -b project % git checkout stable <fix some bug in stable> % git commit -a <forget to switch branches back> <work> % git commit -am "A" <work> % git commit -am "B" ... % git push origin stable That is, the developer makes a whole bunch of inappropriate commits on their stable branch instead of their project branch and then pushes it out (perhaps as part of a push rule, or thinking only the bug fix went there). I suspect that "pull" step there isn't the point where things are going wrong. If you've actually got QA in the process, have developers push to a per-developer location and send a pull request to QA. QA can reject bad changes instead of putting them into the stable branch at all, and then they can reply to the pull requests with snide comments instead of having to beat up the developers, because the developer doesn't inconvenience anybody (except QA, whose job is to be inconvenienced by developers). > I'm less concerned at this point, the company switched entirely to Git > two weeks ago, with the history containing possible unwanted merges. I'm > more concerned however with LazyDeveloper inadvertently polluting stable > branches as LazyDeveloper does not yet fully grasp the concepts that Git > offers I think such developers are more likely to push some bad commits to "stable" directly than they are to make their bad commits on a branch, merge it (fast-forward or otherwise) and push the result. It's also easy to discover: % git push origin project:stable And not generate a merge commit simply by virtue of not merging branches. -Daniel *This .sig left intentionally blank*
