Re: git push --confirm ?

From: Jeff King <peff@peff.net>
Date: Sep 12, 2009, 18:43 UTC
Message-ID: <20090912184342.GB20561@coredump.intra.peff.net>
In-Reply-To: <1252777897.2974.24.camel@localhost.localdomain>

On Sat, Sep 12, 2009 at 01:51:37PM -0400, Owen Taylor wrote:

Show 13 quoted lines

>  * An initial --dry-run pass is done but with more verbosity -
>    for updates of existing references, it would show what commits
>    were being added or removed in a one-line format.
> 
>  * The user is prompted if they want to proceed
>  
>  * If the user agrees, then the push is run without --dry-run
>
> [...]
>
> I think this wouldn't be too hard to add to 'git push', though
> I haven't tried to code it. Yes, it's not atomic without protocol
> changes - I think that's OK:

I have never wanted such a feature, so maybe I am a bad person to comment, but I don't see much advantage from a UI standpoint over what we have now. Which is "git push --dry-run", check to see if you like it, and then re-run without --dry-run. If you just want to see more output in the first --dry-run, then that is easy to do with an alternate format.

But what _would_ be useful is doing it atomically. You can certainly do all three of those steps from within one "git push" invocation, and I think that is enough without any protocol changes. The protocol already sends for each ref a line like:

  <old-sha1> <new-sha1> <ref>

and receive-pack will not proceed with the update unless the <old-sha1> matches what is about to be changed.

Show 5 quoted lines

>  - If the push isn't being forced intermediate ref updates will
>    be caught as a non-fast-forward in the second pass.
> 
>  - If the push is being forced, you might overwrite someone else's
>    push anyways even without --confirm.

Yeah, "--force" is not very fine-grained. I wonder if rather than a complete --confirm you would rather have something iterative like:

  $ git push --interactive
  Pushing to server:/path/to/repo.git
    * [new branch]      topic -> topic
  Push this branch [Yn]?
      5ad9dce..cfc497a  topic -> topic
  Push this branch [Yn]?
      5ad9dce...cfc497a topic -> topic (non-fast forward)
  Force this branch [yN]?

where of course the actual output text and y/n defaults are subject to debate. You could even have a 'v' option at each prompt to visualize the differences in gitk so you can easily get more information on what you might be overwriting in a non-fast-forward scenario.

-Peff