On Mon, Jun 24, 2013 at 11:11:02PM +0530, Ramkumar Ramachandra wrote:
> There are many configuration variables that determine exactly what a
> push does. Give the user early feedback so that she has a chance to
> abort if she doesn't mean to push those refspecs to that destination
> like:
>
> $ git push
> # pushing refspecs 'master next' to ram (^C to abort)
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.
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.
I think you could deal with both of them by doing something like:
git push --dry-run "$@" || exit 1
echo >&2 "OK to push?"
read response
case "$response" in
[Yy]) ;;
*) exit 1
esac
exec git push "$@"
That is subject to a race condition in a busy repo (you do not know that
the refs are in the same state on either end between the two pushes).
You could solve that by having a "pre-push" hook on the local side that
gets the list of proposed updates.
In fact, I think this came up before but no hook code ever materialized:
http://thread.gmane.org/gmane.comp.version-control.git/128273
http://thread.gmane.org/gmane.comp.version-control.git/128426
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.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html