Paolo Bonzini, Tue, Apr 29, 2008 23:41:57 +0200: >> Hmm... Which one do you mean? I cannot find his reply to message-id >> <cover.1209391614.git.bonzini@xxxxxxx> > > 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
