git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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