[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.
> haven't finished testing. For updates, showing a commit count and (a
> probably limited number of) commit subjects would avoid having to
> cut-and-paste the update summary into git log.
>
> As you say, maybe that's something that just needs to be fixed
> with a better format for --dry-run. But that doesn't negate the main UI
> advantage.
Sure. I just think the two concepts are somewhat orthogonal (though you
would probably want to enable them together for your particular
workflow). It sounds like you want something like (and obviously you
could have a config option to avoid typing --log-changes each time):
$ git push --dry-run --log-changes
To server:/path/to/repo.git
5ad9dce..cfc497a topic -> topic
abcd123: commit subject 1
cfc497a: commit subject 2
That can potentially get long, though. I'm not sure if you would want to
abbreviate it in some way, and if so, how.
> Hmm, yeah, I've certainly looked at git-receive-pack(1) before but
> hadn't internalized that --force was client side. Certainly doing it
> with a single atomic pass is the better way to do it.
There is actually a server-side analogue, which is the
"receive.denyNonFastForwards" config option, and it defaults to "off".
The "--force" option is a client side way of helping you be polite. The
receive config option is about actual policy.
> (Wouldn't work for rsync and http pushes, right? A simple "Not
> supported" perhaps.)
Rsync, at least, is already non-atomic because there is no way to do
locking. So you wouldn't make anything worse by supporting this feature
(though you do widen the gap for the race condition by waiting for user
input). I'm not sure anyone really cares about rsync these days, though.
I believe http-push actually does some kind of DAV locking. So there's
no reason you this couldn't work for http push.
> Hmm, of two minds about this. Doing it as a pick-and-choose
> --interactive does integrate it conceptually with other parts of Git.
> And probably is occasionally useful.
>
> But it makes it considerably less convenient to just config on.
> Because any time you want to push more than 2-3 refs at once you'll have
> to add --no-interactive.
>
> It also increases the amount of reading - if I see all the branches at
> once that are being pushed I can immediately notice that I'm pushing two
> branches when I thought I was pushing one, without actually having to
> read the branch names.
I think it really depends on your workflow, and how many refs you are
typically pushing. So yeah, I can see that the iterative asking is not
really a replacement for what you are asking for.
-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