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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:40

Mike Hommey [off-list ref] 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

From: Mike Hommey <hidden>
Date: 2016-06-15 22:47:40

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help