Allowing push --dry-run through fetch url

Hi,

I am currently considering, when I'll get some time, to dive in the git push code to allow push --dry-run without the rights to push.

We currently have two remote configuration items for urls: remote.<name>.url and remote.<name>.pushurl. The latter is used when pushing and the former when pulling/fetching.

The typical use of both at the same time is to put an authenticated value for pushurl (ssh://, for example) and an anonymous one (git://, for example) for url.

What has been annoying me lately is that git push --dry-run asks me for the ssh key or password. I know I could be using an ssh-agent, but that's not the point.

It would be interesting, to me at least, that git push --dry-run can do its job through the git:// url instead of the ssh:// one. But for now, all that does is telling me: fatal: The remote end hung up unexpectedly (probably because the git server doesn't allow pushes at all)

So, before I dive in, what would you think about such a feature?

There is one thing that bothers me, though, it's that --dry-run would, in the end, not really be a dry-run anymore, and, for example, could not be used to validate that the ssh setup is good without actually pushing.

Cheers,

Mike

Mike Hommey <mh@glandium.org> writes:

The daemon sitting on the other end to serve "git://" URL won't understand an attempt to push into. What goes over the wire in the fetch protocol does not give your updated "git push" enough information to guess what would happen if you pushed.

Of course, it is open source and everything can be modified. You _could_ change the daemon whose primary purpose has been to serve fetch requests to also support dry-run only push to make what you outlined work.

But isn't it adding unnecessary complexity for no real reason? It would be a tough sell, I would imagine.

On Fri, Nov 06, 2009 at 12:49:49AM -0800, Junio C Hamano wrote:

Maybe I'm missing something, but the only missing thing I can see at first thought is whether the server is going to reject non fast-forward updates. Are there any others ?

Mike

Mike Hommey <mh@glandium.org> writes:

Hooks, for a starter.

On Fri, Nov 06, 2009 at 01:02:35AM -0800, Junio C Hamano wrote:

AFAICS, they are not run when using --dry-run.

Mike

Mike Hommey <mh@glandium.org> writes:

I actually sense a possible XY problem here.

What are you trying to achieve with "git push --dry-run", especially when you would instead be doing an equivalent of "git fetch" (or "ls-remote") but not storing what you learned from that session with a change like what you are imagining?

The answer to the above question is the real reason "X".

It could be that what you are interested in is if you are ahead of the other side. In other words, you would want to know if some branches result in non-fast-forward error, causing you to re-fetch and re-merge (or rebase).

And "push --dry-run" that fails would give you that information, if it worked for you without authenticating. And that could be your "Y".

But doesn't "branch -v" give the necessary information for that purpose and even a bit more? Couldn't "git fetch && git branch -v" be a better solution for your real problem "X"?

It is a better solution _if_ the real problem you are trying to solve is what I suspected above because:

 (1) If you will end up fetching to make you ahead of them again, doing
     "push --dry-run" to learn fast-forwardness first would still require
     you to fetch from there anyway.  With "git fetch && git branch -v",
     you have already fetched when you learned that you are not ahead;

 (2) When you learn from "git fetch && git branch -v" that you were indeed
     ahead, you can push.  In such a case, because you were ahead, the
     fetch wouldn't have slurped a lot of data from the other end anyway,
     so there is no real overhead for doing so.

 (3) In either case, "branch -v" output would give you not just "is it
     fast-forward?" but also "if not, by how much they have diverged" (in
     addition to the commit message for the tip).

But this may not be an XY problem.  I am just curious.

On Fri, Nov 06, 2009 at 01:44:54AM -0800, Junio C Hamano wrote: <snip>

Usually, when I run git push --dry-run, it's to check that what follows (usually the refspec part) does what I want it to do, such as not pushing tags I didn't intend to push(*), and stuff like that.

Mike

(*) the fact that all tags from all remotes are being mixed doesn't help, here, and without dry-running, I end up pushing tags from one remote onto another.

Mike Hommey <mh@glandium.org> writes:

Ahh, that one.

That reminds me of a topic that we discussed but went away without reaching the conclusion on adding a "confirmation: are you sure this pushes what you want?" to the command. I had a doubt about the patch back then which was that it hardcoded a tty interaction and it would be hard to retrofit it to help GUI frontends (so my suggestion was to use something like hooks mechanism, perhaps --confirm=this-script and allow it to do its GUI thing), but thinking about it again, they can always use "expect" to drive the interaction with the confirmation prompt, so it may not a big deal after all---we might want to resurrect the topic.

That was an unrelated, independent thought on your comment, but if we did so, you might not even have to try to use --dry-run on git:// transport.

On Sun, Nov 08, 2009 at 11:23:27AM -0800, Junio C Hamano wrote:

How about an option to have the confirmation asked, quite like cp/mv/rm's -i option ?

Sounds like a good trade-off.

Cheers

Mike

Junio, could you tell us what happened to this thread?

After discussing "git push --dry-run" that looks at URL used for fetching, because pushURL might require authentication, the maintainer recalls an earlier "git push --confirm" patch

http://thread.gmane.org/gmane.comp.version-control.git/128426/focus=128429

but nothing happens after that.

Nanako Shiraishi <nanako3@lavabit.com> writes:

Your analysis is correct --- nothing happened after that ;-)

I think it is probably worthwhile to revisit Owen's patch, though. Back then I was worried too much about giving IDE authors (who need to scrape the output and interact with the "confirm" interface) enough flexibility and wanted to see an interface to allow plugging a more machine readable interaction before proceeding, but I changed my mind.

We can have --confirm with two output styles, one that is for consumption by human sitting in front of a terminal (and is prone to future UI tinkering like coloring), and the other with machine readable interaction, that is more or less frozen (or "extensible"). And it is perfectly Ok to start only with the human readable one, clearly documented that it is not (yet) for use by IDE via scraping.

But I won't be the person with the --confirm itch, so interested people need to help to make that happen.

Thanks for a stream of reminders, by the way.