Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
- From
Andreas Ericsson <ae@op5.se>
- Date
- Oct 25, 2007, 10:24 UTC
- Message-ID
- <47206EC3.5000002@op5.se>
- In-Reply-To
- <Pine.LNX.4.64.0710251108330.25221@racer.site>
Johannes Schindelin wrote:
Show 23 quoted lines
> 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-<cmd-156>?
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231