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

[Andreas Ericsson <ae@op5.se>]

Peter Baumann wrote:
> On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:
>> J. Bruce Fields wrote:
>>> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:
>>>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:
>>>>
>>>>>> I want git pull to work like git push.
>>>>> That strikes me as a less complete solution, since it only helps in the
>>>>> case where the other branches all happen to be unmodified locally (hence
>>>>> can be fast-forwarded).  In other cases the "git push" will still emit a
>>>>> spurious error.
>>>> Well, but then there's something you should really think
>>>> about.
>>> Perhaps, but not necessarily; you may have some branches with local
>>> changes that you're content to leave unpushed (and un-updated).
>> Sure, but that won't change. The only thing I'm proposing is that
>> local copies of remote branches are automatically fast-forwarded
>> on every pull, but only if
>>
>> * the branch has no modifications what so ever
>> * the branch is set up to auto-merge with the particular branch
>> fetched from the particular remote
>>
>> I really don't see any downsides what so ever with this. Those
>> of you who do, please enlighten me.
>>
> 
> You can't check what got added in your pull, e.g you can't review the new
> code with something like
> 
> 	gitk next..origin/next
> 

That's what git-fetch is for.

> I often do something like this, just to see what got changed. So at least
> in my opinion you have to add a third point:
> 
>   * the branch has no modifications what so ever
>   * the branch is set up to auto-merge with the particular branch
>     fetched from the particular remote
> 				AND
>   * the user set a config option to always autofastfoward if the above
>     conditions are true! This could be implemented as a global option with
>     a per branch overwrite.
> 

I'd be fine with that, except I think it's fairly dangerous to have
different defaults. The two first points are sort of the core of the
case I've been arguing all along.

> Only if this option is added so a user can mark a branch to never
> autofastforward (but it is still possible to  have an auto-merge config) you won't
> loose valuable information.
> 

Sure. I was thinking something along these lines:

[branch "foo"]
	remote = bar
	merge = some-branch
	autofastforward = false


Or use git-fetch. git-pull is "fetch + merge". 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.

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