I sent them together to provide a single coherent series and an aim for
a transition plan -- which I'd prefer to work out with the git
community, who knows the release mechanics much better than I do. Jeff
King's reply to the cover letter is a start towards that; your e-mails
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
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".
It is not. It seem to propose, instead of fixing existing behaviour,
Do you know how to "fix" existing behavior?
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.
Paolo
--
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
