Re: [PATCH 7/7] make "git fetch" update all fetch repositories

From: Alex Riesen <raa.lkml@gmail.com>
Date: Apr 29, 2008, 21:53 UTC
Message-ID: <20080429215311.GC2413@steel.home>
In-Reply-To: <48179625.3050704@gnu.org>

Paolo Bonzini, Tue, Apr 29, 2008 23:41:57 +0200:

Show 5 quoted lines

>> Hmm... Which one do you mean? I cannot find his reply to message-id
>> <cover.1209391614.git.bonzini@gnu.org>
>
> http://permalink.gmane.org/gmane.comp.version-control.git/80720
>

Just received it

Show 11 quoted lines

>>> are also a start towards that, even though I don't think your 
>>> transition  plan is feasible (also because it would break "git remote 
>>> update"  completely).
>>
>> Which part of "warn people in git-fetch" will break "git remote update"?
>> Or what will break after the "git remote add" start setting
>> skipDefaultUpdate?
>
> People will expect the new remotes to be, ehm, updated by "git remote  
> update".
>

Ah, right. How about a warning, then? Like:

    $ git remote add abc host:src/project
    warning: fetch and push without arguments WILL update the references of "abc"
    $

>> It is not. It seem to propose, instead of fixing existing behaviour,
>
> Do you know how to "fix" existing behavior?
>

Never considered it broken. OTOH, it hasn't occured to me to run "git push" without arguments. And I do expect "git fetch" to fetch just the remote my current branch is related to (and not all remotes).

Show 5 quoted lines

> I mean, I just wonder why as long as I had one remote only, I could  
> write "git push", while now I have to write "git push origin && git push  
> mirror".  The patch to "git fetch" comes from this observation too, and  
> I think it is a good idea, even though I'm less attached to it and it  
> would influence my workflow much less.

Have you tested your patches in your workflow? Worked with them for some weeks? Gave them to your peers?