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

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 23, 2007, 05:38 UTC
Message-ID: <92320AA3-6D23-4967-818D-F7FA3962E88D@zib.de>
In-Reply-To: <8fe92b430710221635x752c561ejcee14e2526010cc9@mail.gmail.com>

On Oct 23, 2007, at 1:35 AM, Jakub Narebski wrote:

Show 45 quoted lines

> On 10/22/07, Andreas Ericsson <ae@op5.se> 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. Git knows when I haven't got any changes on my local
>> branches, and it can be fairly safely assumed that when I feel like
>> making any, I'd like to make them off as fresh a tip as possible  
>> unless
>> I explicitly tell git otherwise.
> [cut]
>
> It would be I think possible to make git behave as you want,  
> although I'd rather
> (at least at first) have behaviour described above turned on by  
> some option
> or config variable. I guess that it would be not that hard to make  
> script to do
> what you ant (and probably it would be best if you tried your idea  
> that way).
>
> There are the following caveats.
> 1. For each local branch that is to be updated on pull, this branch
> must be marked as tracking some branch of some repository. This has to
> be explicitely done; for example by creating those branches using
> --track option.

True, and only the branches matching the remote currently pulled should be considered. Tracking branches pointing to a different remote need to be skipped.

> 2. Git can do a merge with conflicts _only_ if that branch is checked
> out.

Andreas' proposal contains an important requirement that avoids this problem. His proposal states "when they, prior to fetching, pointed to the same commit [the head in remotes pointed to]". That is only fast-forwards are needed, which never have merge conflicts.

Show 6 quoted lines

> So for all local branches which you want to get updated using
> "git pull --update-all <repo>" (or something like that), the merge
> with remote branch should be either fast-forward, trivial merge, or
> merge without conflicts. "git pull --update-all <repo>" would return
> then list of updated branches and list of branches which cannot be
> updated.

Maybe Andreas' proposal could be extended as you describe. But I don't think any merging should automatically be done. I'd only support fast forwards. Merging always includes a risk of unexpected changes to the code; even if there are no merge conflicts detected by git. I think it is reasonable to leave all such cases to the user for manual resolution. Supporting fast-forward should be sufficient.

	Steffen