From: Steffen Prohaska <prohaska@zib.de>
Date: Mon, 22 Oct 2007 15:42:48 GMT
Subject: Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
Message-ID: <87AF88A8-93B2-448C-B100-10B8EFFB6627@zib.de>
In-Reply-To: <471CBEB1.2030008@op5.se>


On Oct 22, 2007, at 5:16 PM, Andreas Ericsson wrote:

> Johannes Schindelin wrote:
>> Hi,
>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:
>>> Johannes Schindelin wrote:
>>>
>>>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:
>>>>
>>>>> If I were to suggest any improvements, it'd be to change the  
>>>>> semantics of git-pull to always update the local branches set  
>>>>> up to be merged with the remote tracking branches when they,  
>>>>> prior to fetching, pointed to the same commit, such that when
>>>>>
>>>>> $ git show-ref master
>>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
>>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/ 
>>>>> master
>>>>>
>>>>> refs/heads/master gets set to refs/remotes/origin/master post- 
>>>>> fetch.
>>>> In general, this should fail.  Because you are expected to have  
>>>> local changes in the local branches.
>>>
>>> BS argument.
>> Aha.  So you want to make sure that the local branches are no  
>> longer "purely" local.  And you want to stop updating them when  
>> unpushed changes are in the local branches.
>
> To me, it's more along the lines of "let git help me not make the  
> mistake of hacking on a six-week old codebase when I've explicitly  
> asked it to merge these and those remote tracking branches into  
> these and those local branches". Not updating those branches when  
> there *are* changes on them is something users can understand and  
> will probably also appreciate, but the reason for not allowing even  
> fast-forwards escape me.

Here's also an interesting asymmetry. By default, git push
updates all remote branches matching a local branch. But git
pull "updates" only the current local branch to the state of
the remote head (by updating all local copies of the remote
branches, but merging only a single of these heads).

Maybe this asymmetry adds to the confusion. I see arguments
for both behaviours:
1) In both cases, update only the branch you're on
or
2) in both cases update all matching branches.
(btw, if I do not intend to merge at all, you can always use
"git fetch".)

	Steffen