Jeff King wrote: > Leaving aside the transport API for a minute, you are always going to > have this lack-of-information versus time problem. A refspec like ":" > says nothing particularly useful, but it can only be expanded once > contact is made with the other side (which is what takes time). Right, and ':' is special in that aspect; it does not warrant slowing down the expansion of refs/heads/*, for instance. Besides, I suspect ':' can be resolved much faster than using push --dry-run. > I do not personally think the "early" information is particularly > useful. I don't have a problem with it as part of "-v" output (or > enabled by config), but it seems useless for enough cases (e.g., user > gave explicit refspecs, or refspecs are not useful without being > expanded) that showing it by default is going to be considered noisy > cruft by many users. > > Was the unconditional nature of your earlier patch meant to be part of > the final version, or was it just illustrative? Very much illustrative. The finer details of when exactly we should show it can be discussed later. >> Yes, ^C is a hack, but it's useful in practice (there is ofcourse no >> guarantee): I've been saved many times by it. The only way to prevent >> the race is to wait (either indefinitely for some user-input or for N >> seconds), but I don't want to trade of speed. > > I have had the opposite experience. Many times I tried "rm -v" to keep > an eye on what was being removed, but I do not recall once where I > frantically reached for the keyboard in time to make a difference. But > of course that is anecdotal, and push can be somewhat slower. push is an all-or-nothing network operation that has significant startup time (name resolution etc.), very much unlike "rm -v". Again, I'm talking about "in practice" *in the context of push*; not making any statements about the general usefulness or correctness of ^C. > Yes. I do not have any interest in such an interactive push, but the > point is that a potential first step to any confirmation scheme, no > matter what you want it to look like, is a hook. You don't seem to want > a confirmation scheme, though, due to the wait (and I cannot blame you, > as I would not want it either; but then I would not want the extra > refspec message you propose, either). I'm trying to figure out how to determine what a push will do without actually pushing (or --dry-run, which is almost as expensive). You might like to put that information in your prompt instead of stdout, but do you agree that the information is worth getting? -- 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