Quoting Paolo Bonzini <bonzini@xxxxxxx>: >>> Sorry, how does the patch make you lose some of your work (as >>> opposed to some of your time, which is possible as is the case for >>> every backwards incompatible change)? >> >> Because I will lose some of the refs and then have to dig them up in the >> reflog. >> >> I'm not comfortable with the reflog. I appreciate its usefulness, but I'm >> thoroughly unhappy when I'm forced to use it. > > So am I, but still it would lose time (to dig refs up in the reflog), > not work (e.g. having to rewrite code). I think we're in agreement on > this part. > >> Yes, I understand the rationale, and I do have an alternative idea, which >> is to make it configurable. > > Then sorry, but I think you don't understand the rationale. The cover > letter has excerpts from other git hackers' e-mails that explain it > better than I can. But shortly speaking, the point of the patch is to > remove the "magic" operation of "git fetch" as "git fetch > origin". Removing is quite the opposite of "add a configuration option > that disables it, but leave the old behavior as default". > >> Now that I think about it, it's probably useful to have it >> togglable via command-line switch as well. Something along the >> lines of "git fetch --all-remotes", perhaps. > > Making it accessible via a command-line switch is pointless, as we > already have "git remote update" for that. > > Paolo Sorry but then why does this patch have to even touch "git fetch"? Isn't it enough to run "git remote update"? -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com/tag/2 -- 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
