On Tue, Nov 06, 2007 at 07:38:41AM +0000, Alex Riesen wrote: > Pierre Habouzit, Tue, Nov 06, 2007 01:46:01 +0100: > > On Tue, Nov 06, 2007 at 12:36:16AM +0000, Bill Lear wrote: > > > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes: > > > > Stop thinking like "I need to integrate the changes from upstream > > > > into my WIP to keep up to date." > > > > > > > > [...] > > > > > > > > Once you get used to that, you would not have "a dirty directory" > > > > problem. > > > > > > I respectfully beg to differ. I think it is entirely reasonable, and > > > not a sign of "centralized" mindset, to want to pull changes others > > > have made into your dirty repository with a single command. > > > > I agree, I have such needs at work. Here is how we (very informally) > > work: people push things that they believe could help other (a new > > helper function, a new module, a bug fix) in our master ASAP, but > > develop big complex feature in their repository and merge into master > > when it's ready. > > > > Very often we discuss some bugfix that is impeding people, or a > > most-wanted-API. Someone does the work, commits, I often want to merge > > master _directly_ into my current work-branch, because I want the > > fix/new-API/... whatever. > > How about merging just that "fix/new-API/... whatever" thing and not > the whole master, which should be a complete mess by now? No master only holds simple patches (few of them, typically half a dozen a day), or long-lived branches that are tested and ready to merge. > The way you explained it it looks like typical centralized workflow. Well I disagree, it's /part/ centralized. We have a two speed devel method, one that works the old-centralized way for quick fixes, and a more decentralized approach for big changes. It's a rather nice and useful middle ground for a company where all programmers are within earshot. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpIU0yA6HXN5.pgp
Description: PGP signature
