Re: [PATCH] push: give early feedback

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 24, 2013, 18:42 UTC
Message-ID: <CALkWK0=d1wkKWngH+6gBd-2svj7r_tgC5=+zUbgJRDfUCzupSw@mail.gmail.com>
In-Reply-To: <20130624182809.GA15296@sigill.intra.peff.net>

Jeff King wrote:

Show 6 quoted lines

> 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.

Show 8 quoted lines

>   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.