On Tue, Feb 17, 2015 at 1:10 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> Sure. But if I got a pull request saying "please pull
> git://example.org/foo.git HEAD" I would think that the sender
> messed up the pull request. So *in the context of git-request-pull*
> ${remote:-HEAD} makes little sense to me.
Umm. If somebody actually leaves off the third argument THAT IS NOT AT
ALL what it prints.
It will show
The following changes since commit <base>...
.. base commit description ..
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
for you to fetch changes up to cc4f9c2a91b7be7b3590bb1cbe8148873556aa3f:
...
IOW, it does exactly the right thing. It gives the contents of HEAD,
but it doesn't actually say HEAD anywhere.
And just look at lkml. The above kind of branch-less and tag-less pull
requests are still fairly common. It's the original git model, and it
may be a bit archaic, and I much prefer people to send me signed tags,
but hey, that's what "don't mention a branch or tag" means.
And no, I don't think git request-pull is at all different from other
git commands. "git log" means the same thing as "git log HEAD". Exact
same thing, and nobody would actually write out that HEAD (except
inside scripts, perhaps).
So basically I agree that git request-pull has changed behavior, but
the new behavior is *more* in line with other git commands, and the
old behavior was actually really really odd with that whole extensive
"guess what the user means". No other git command ever did that
guessing thing (ok, famous last words, maybe somebody can come up with
one), and not mentioning a branch/tag/commit explicitly pretty much
always means "HEAD".
:Linus
--
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