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.


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



> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to