On Sat, Sep 12, 2009 at 01:51:37PM -0400, Owen Taylor wrote:
> * 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.
> - 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html