Re: git push --confirm ?

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 13, 2009, 10:37 UTC
Message-ID: <7vljkjuo43.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20090913093324.GB14438@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

>> I do not think this is an unreasonable option to have.  Just please don't
>> justify this change based on atomicity argument, but justify it as a mere
>> convenience feature.
>
> I don't agree. Making sure we use the _same_ <old-sha1> in the
> confirmation output we show to the user and in the ref update we send to
> the remote is critical for this to be safe.

OK.

You may be giving stale info to the user if somebody else is pushing from sideways anyway, and the difference between a separate --dry-run and real push when that happens is where and how the human waits.

With a separate --dry-run, the wait happens while the output is examined offline. The user may run "git log --oneline old...new" himself before deciding to run the real push.

With --confirm, the wait happens while the --confirm waits for the human, and perhaps the command does "git log --oneline old...new" as convenience. While all this is happening, the TCP connection to the remote end is still kept open. We do not lock anything, but if somebody else pushed from sideways, at the end of this session we would notice that, and the push will be aborted.

This somewhat makes me worry about DoS point of view, but it does make it somewhat safer.

I think the largest practical safety would come from the fact that this would make it convenient (i.e. a single command "push --confirm") than having to run two separate ones with manual inspection in between. A safety feature that is cumbersome to use won't add much to safety, as that is unlikely to be used in the first place.