Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

[Andreas Ericsson <ae@op5.se>]

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-<cmd-156>?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231