Mike Hommey <mh@xxxxxxxxxxxx> 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.
--
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