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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
