From: Andreas Ericsson Date: Thu, 25 Oct 2007 10:24:03 GMT Subject: Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued Message-ID: <47206EC3.5000002@op5.se> In-Reply-To: Johannes Schindelin wrote: > Hi, > > On Thu, 25 Oct 2007, Andreas Ericsson wrote: > >> Johannes Schindelin wrote: >> >>> On Wed, 24 Oct 2007, Andreas Ericsson wrote: >>> >>>> Conceptually, I don't think it'll be any problem what so ever >>>> telling anyone that the branches that aren't currently checked out >>>> get merged automatically only if they result in a fast-forward. >>> It would be a matter of seconds until someone asks "why only >>> fast-forwards? Would it not be _much_ better to merge _always_? >>> Stupid git." >>> >>> And all because the concept of "local" vs "remote" was blurred. >> It's already blurred, since we have git-pull instead of just git-fetch. > > Huh? How is "I ask git pull to fetch the remote branch, and merge it into > my local branch" a blurring of local vs remote branch? > > The local branch is still the local branch where it is _my_ responsibility > to update or change anything. True. So git pull saves you exactly one command. The various fetch-all-git- repos-and-update-all-fast-forward-branches in circulation at the office save us ~500 commands each time they're run. Or rather, they *could* do that, but you can't know until you've run it. So what should I do to make what I want possible, without having git-pull muddy the waters of local vs remote? There's clearly a user desire for it, besides that of my eight co-workers and myself. Introduce git-? -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231