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

From: Andreas Ericsson <ae@op5.se>
Date: Oct 25, 2007, 20:18 UTC
Message-ID: <4720FA00.1050805@op5.se>
In-Reply-To: <7vejfj11tk.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 33 quoted lines

> Andreas Ericsson <ae@op5.se> writes:
> 
>> However, there's still this issue:
>> $ git checkout -b foo origin/pu
>> Branch foo set up to track remote branch refs/remotes/origin/pu.
>> Switched to a new branch "foo"
>>
>> git checkout will say that every time a branch is created from a
>> tracking branch, unless one tells it --no-track (which people don't
>> learn about unless they're really into git), so it's quite natural
>> that people think git will actually make sure, within reasonable
>> limits, that 'foo' is kept in sync with refs/remotes/origin/pu.
>> That's not the case, however.
>>
>> So we could either change the message to be:
>> "Branch foo set up to track remote branch refs/remotes/origin/pu,
>> provided you only ever issue git-pull while having branch foo
>> checked out."
>>
>> Or we could make 'git checkout -b' default to --no-track, perhaps
>> giving annoying messages everytime someone "git-checkout -b"'s a
>> remote tracking branch.
>> Or we could make git-pull keep git checkout's promises.
> 
> The thing is, if you have 200 local branches (because you
> interact with 50 repositories with 4 primary branches each), you
> do not constantly check all of them out anyway.  And the only
> place that staleness of the local tracking fork matters is when
> you check it out (that is, as long as you train your users that
> the way to check differences with the upstream 'pu' in your case
> is by doing operations with 'origin/pu' not with your local
> 'foo').
>

Probably, although I think the confusion of 'foo' being something else than 'origin/pu' after it's been checked out would be hard to explain. I'll see how the patch turns out. If it all goes tits up, I'll see if a post-checkout hook can solve it.

Show 21 quoted lines

> With that in mind, how about making "git checkout foo", after
> foo is set up thusly, to show:
> 
> 	git log --pretty=oneline --left-right origin/pu...foo
> 
> if (and only if) they have diverged?  Then you can deal with the
> staleness of local tracking fork 'foo' in any way you want.
> 
> You could even go one step further and make this "checkout foo",
> in addition to or instead of showing the above left-right log,
> 
>  - automatically run "git merge origin/pu" if it is a
>    fast-forward, and say it did _not_ run that merge if it is
>    not a fast-forward;
> 
>  - automatically run "git merge origin/pu" always, even if it is
>    not a fast-forward;
> 
>  - automatically run "git rebase origin/pu" always;
> 
> Would that make your life easier?

That it would, except the confusion would then be that it's automatically rebased for the branches one currently hasn't got checked out while pulling, and the branch that *is* checked out gets merged (crazy, yes), so those who prefer the rebase would get what they want by doing something completely bonkers, such as:

git checkout -b just-gonna-pull HEAD^ git pull git checkout whatever-other-branch-they-were-on

(yes, "aggresively ignorant", I think Ted said in an earlier mail)

It'd probably be better to go with Dscho's suggestion, although I'm not quite sure what that was any more. It involved automagical rebasing on fetch or pull though.

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