Re: [PATCH] push: give early feedback

[Ramkumar Ramachandra <artagnon@gmail.com>]

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?