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

[Peter Baumann <waste.manager@gmx.de>]

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

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.

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.

-Peter