On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:
quoted text
> 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.

The downsides are that it makes the behavior of pull slightly more
complicated, and that it changes long-established default behavior of a
major subcommand.  (Those aren't huge disadvantages, but they are
disadvantages.)

quoted text
>
>> 	- the user has one or more unmodified copies of remote branches
>> 	  lying around, and
>
> Extremely common case for a large group of users.

OK, but that was one part of a four-"and" clause.  I don't see any
absolute clincher here, but on balance I think the disadvantages win
out.

--b.
-
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