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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html