Re: [PATCH] push: give early feedback

Jeff King wrote:

If your intent is to let people stop disastrous pushes before they
complete, I think there are two failings:

  1. It does not tell very much about how the refspecs are expanded or
     what is going to happen. "git push --dry-run" gives a much more
     complete view of what will be pushed.

Yes.

  $ git push
  # pushing refspecs ':' to ram

Completely useless.

On the other hand, if I implement it at the transport layer like
TRANSPORT_PUSH_DRY_RUN, it takes *way* too long to say anything
useful; the whole "early" part has been thrown out the window.  The
issue is again related to the same nightmare I'm having: not being
able to implement @{push} refspec because the transport API is so
tangled up; I can't call into the refspec-pattern-expander from
anywhere else.

  2. You are creating a race with the user to hit ^C. It will probably
     work if there are a lot of objects to be pushed. But not if the
     push is small, or even has no pack at all (e.g., only deletions, or
     moving refs to existing history). As an added bonus, since push
     prints its output after receiving commitment from the server, it is
     possible for the server to commit a change, have the user hit ^C,
     thinking they beat the race, only to find out that the server did
     indeed accept the change.

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.

  http://thread.gmane.org/gmane.comp.version-control.git/128426

A TRANSPORT_PUSH_CONFIM.  Cute.

As discussed in the top thread, this could also be used for "interactive
push" where you could examine and confirm the changes for each proposed
ref change.

Overkill, I think.  I don't want to bolt on very heavy safety
features: just help the user help themselves with feedback.