Allowing push --dry-run through fetch url

Allowing push --dry-run through fetch url

[Mike Hommey]

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

Re: Allowing push --dry-run through fetch url

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

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

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.

Re: Allowing push --dry-run through fetch url

[Mike Hommey]

On Fri, Nov 06, 2009 at 12:49:49AM -0800, Junio C Hamano wrote:
> 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.

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

Re: Allowing push --dry-run through fetch url

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> On Fri, Nov 06, 2009 at 12:49:49AM -0800, Junio C Hamano wrote:
>> 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.
>
> 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 ?

Hooks, for a starter.

Re: Allowing push --dry-run through fetch url

[Mike Hommey]

On Fri, Nov 06, 2009 at 01:02:35AM -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 ?
> 
> Hooks, for a starter.

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

Mike

Re: Allowing push --dry-run through fetch url

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> 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.

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.

Re: Allowing push --dry-run through fetch url

[Mike Hommey]

On Fri, Nov 06, 2009 at 01:44:54AM -0800, Junio C Hamano wrote:
<snip>
> 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"?

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.

Re: Allowing push --dry-run through fetch url

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> 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.

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.

Re: Allowing push --dry-run through fetch url

[Mike Hommey]

On Sun, Nov 08, 2009 at 11:23:27AM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > 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.
> 
> 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.

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

> 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.

Sounds like a good trade-off.

Cheers

Mike

Re: Allowing push --dry-run through fetch url

[Nanako Shiraishi]

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.

Re: Allowing push --dry-run through fetch url

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> 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.

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.