On Oct 24, 2007, at 11:28 PM, Peter Baumann wrote:

quoted text
> 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

You're not forced to pull. Just use "git fetch" if you
want to do this. Or is something missing if you'd be
limited to "git fetch"?


quoted text
> 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 (and, as I understood, Andreas, too) want to change the
default. Because we believe that git would be easier to use
in workflows based on a shared repository.

But if we fail to convince the list, maybe a global
configuration variable that configures "git pull" to autoforward
branches as propose would be a nearly equally good solution.

However, I think it is dangerous to introduce many of such
configuration options. Explaining the behaviour of git will
become harder. The behaviour will become dependent on the
local configuration and eventually the first question before
answering a question will be "send me the output of 'git config
--list'. I need to see how your git is configured."

	Steffen



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html