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

From: Andreas Ericsson <ae@op5.se>
Date: Oct 25, 2007, 12:46 UTC
Message-ID: <4720903E.1070103@op5.se>
In-Reply-To: <Pine.LNX.4.64.0710251232370.25221@racer.site>

Johannes Schindelin wrote:

Show 43 quoted lines

> Hi,
> 
> On Thu, 25 Oct 2007, Andreas Ericsson wrote:
> 
>> Johannes Schindelin wrote:
>>
>>> 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.
> 
> As I pointed out, there is no way to sensibly have 500 _local_ branches 
> lying around.
> 
> It is ridiculous to assume that you have to have local branches for all 
> the stable, maintenance, whatever branches.
> 
> When you have to change something, you branch, hack, develop, commit, 
> push, and then _clean up_ after yourself.  No need to clutter your 
> local branch space with unused branches.
>

error: The branch 'next' is not a strict subset of your current HEAD. If you are sure you want to delete it, run 'git branch -D next'.

So you want me to tell all the developers they should use "git branch -D maint" instead, so they can bypass the built-in security checks? No thanks.

Show 7 quoted lines

>> 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>?
> 
> If you _insist_ on your workflow, hey, git is a free program, and you can 
> do what you want to do with an alias easily enough.

With a git alias? No. There aren't even any switches in git to make it do what I want. With a shell alias? Sure, it's doable, but cumbersome. With a shell-script I can get it done, but it's ugly, inefficient and has to parse everything twice. It's also a time-sink, and time is something I don't have very much of right now.

>  You can even make 
> that alias part of the templates, so you can force your desires down the 
> throat of every of your coworkers.
>

They're the ones that requested I hack it into git, but the result would remain the same, ofcourse.

> However, that does not mean that you can insist on support for your 
> workflow in upstream git.
>

I'm not. We're currently discussing the pros and the cons, and I'm spending my free 20 minutes every night working on a patch-series to make git-pull a built-in and then implementing the switch/config-option/whatever that makes it do what I want it to do. Apart from Junio, that's how everyone that wants a feature implemented has to do it, so I'd hardly call that insisting. If Junio decides the patch does something evil, I'll have to settle for cherry-picking it into whatever branch I want to build from.

On a side note; I'd *love* for it to have a rebase option as well. Perhaps I'll do that next. In the mean-time, I'd settle for just updating locally modifiable copies of tracking branches that I've already configured git to merge with a tracking branch when it happens to be a fast-forward.

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