On Fri, Feb 08, 2008 at 07:24:06PM -0800, Junio C Hamano wrote:
> Yeah, -f using "matching refs" is dangerous, but on the other
> hand, that would be how you correct that mistake in one shot,
> after you fixed the mistake locally.
Not necessarily; you might not even have the refs that you just rewound.
> Is there anything wrong with "git push $there $branch_name"? I
I think only that:
- it's more typing, so if there is a class of users who want to use
"git push origin HEAD" as their workflow, it might make sense to
support them with a config option
- I have seen less experienced users expecting "git push" to do a
single branch (i.e., users whose workflow is "git pull; hack hack
hack; git push").
With one branch it is not a problem, but as soon as you introduce
them to other branches, then the push behavior is yet another thing
that you have to explain. And I know "clueless users" is not a good
reason to change defaults if it makes clueful users less happy, but
it might be reason for a config option.
> thought we discussed this last time and there was even a patch
> that does "git push $there HEAD" to push out the current branch,
Ah, I forgot about that. Yes, that does work in 1.5.4.
> I do not know if this was part of the last round of patches, but
> I suspect it is not a problem to allow
>
> $ git push HEAD
>
> if it is unambiguous. That is, "HEAD? Do we have such a remote
> nickname? No. Then can we default to 'origin' and use it as
> the ref to push? Yeah, we can, so the user meant 'git push
> origin HEAD'".
I have often wanted that, since I typically only _ever_ push to an
origin, but the DWIM made me paranoid that it could be unsafe. If you
had a remote and a branch name that were similar, then a typo could end
up pushing to the wrong place.
-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
