Re: git push --confirm ?

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Sep 12, 2009, 21:55 UTC
Message-ID: <alpine.LNX.2.00.0909121739480.28290@iabervon.org>
In-Reply-To: <20090912204905.GA31427@coredump.intra.peff.net>

On Sat, 12 Sep 2009, Jeff King wrote:

Show 43 quoted lines

> [cc'd Daniel; I think this proposal for a "confirm push" might interact
> with your foreign VCS work a bit. I'm not sure anymore what would be the
> right level for inserting this code.]
> 
> On Sat, Sep 12, 2009 at 04:11:06PM -0400, Owen Taylor wrote:
> 
> > The main UI advantage is that you can adjust the default with 'git
> > config' it on and leave it on. The time you screw up is not when you are
> > worried that you are going to push the wrong thing. It's when you are
> > you know exactly what 'git push' is going to do and it does something
> > different.
> 
> That makes sense. I would not want to use such a feature, but I see the
> use case you are talking about (see, I told you I was bad person to
> comment. ;) ).
> 
> It should be pretty straightforward to implement for the git protocol.
> Pushing goes something like:
> 
>   1. Get the list of refs from the remote.
> 
>   2. Using the desired refspecs (either configured or from the command
>      line), make a list of src/dst pairs of refs to be pushed.
> 
>   3. For each ref pair, send the "<old> <new> <name>" triple to the
>      remote (or not, if it is already up-to-date, a non-fast-forward,
>      etc).
> 
>   4. Send the packed objects.
> 
>   5. For each ref pair, print the status in a summary table.
> 
> So you would just want a "2.5" where you show something similar to the
> summary table and get some confirmation (or abort). An iterative "do you
> want to push this ref" strategy would be similar; just mark the refs you
> do and don't want to push.
> 
> The tricky thing will be handling different transports. Some of that
> code has been factored out, but I haven't looked at the details. On top
> of that, I think Daniel is working in this area for his support
> of foreign VCS helpers (and other transports like libcurl are getting
> pushed out into their own helpers). So he may have a better idea of how
> to go about this sanely.

The status used to be that each method of pushing implemented approximately the rules you give, but implemented it separately. Now there's a common implementation of those rules, with (1) being a method call, (3&4) being a method, and the rest being in transport_push(). However, rsync and curl have not yet been converted to the new style. When there is support for push with helpers, it will only use the new style (because it would be pointlessly annoying to implement the git rules for refspecs in the helpers).

So it should be easy to put something into transport_push to do a step 2.5 confirmation, and a bit more work (which ought to get done anyway) to make it apply to rsync and http URLs.

(Furthermore, currently, http-push is a separate program from the fetch code, which is moving from the main git executable to git-remote-curl; the http push code should probably actually move to git-remote-curl, so that there is a single external program taking care of all operations on such URLs and there is less complexity in how the curl-using code is structured.)

	-Daniel
*This .sig left intentionally blank*