From: Alex Riesen Date: Tue, 29 Apr 2008 21:53:11 GMT Subject: Re: [PATCH 7/7] make "git fetch" update all fetch repositories Message-ID: <20080429215311.GC2413@steel.home> In-Reply-To: <48179625.3050704@gnu.org> Paolo Bonzini, Tue, Apr 29, 2008 23:41:57 +0200: >> Hmm... Which one do you mean? I cannot find his reply to message-id >> > > http://permalink.gmane.org/gmane.comp.version-control.git/80720 > Just received it >>> 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). > 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?