From: Jeff King <peff@peff.net>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] push: give early feedback
Date: Mon, 24 Jun 2013 14:28:09 -0400 [thread overview]
Message-ID: <20130624182809.GA15296@sigill.intra.peff.net> (raw)
In-Reply-To: <1372095662-24527-1-git-send-email-artagnon@gmail.com>
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
next prev parent reply other threads:[~2013-06-24 18:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 17:41 [PATCH] push: give early feedback Ramkumar Ramachandra
2013-06-24 18:04 ` Fredrik Gustafsson
2013-06-24 18:24 ` Junio C Hamano
2013-06-24 18:28 ` Jeff King [this message]
2013-06-24 18:42 ` Ramkumar Ramachandra
2013-06-24 18:55 ` Jeff King
2013-06-24 19:24 ` Ramkumar Ramachandra
2013-06-24 19:39 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130624182809.GA15296@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).