Jeff King wrote (2008-04-09 16:34 -0400):

quoted text
> On Wed, Apr 09, 2008 at 11:08:36PM +0300, Teemu Likonen wrote:

quoted text
> >   $ git fetch <URL>
> > 
> > would be equivalent to
> > 
> >   $ git fetch <URL> +refs/heads/*:refs/remotes/<name>/*

quoted text
> This has been discussed before and rejected, because the point of
> doing a fetch of a URL (rather than a remote name) is to do
> a "one-off" thing.

First, thank you for such a detailed information and giving somewhat
different point of view from mine.

Ok, "git fetch <URL>" has its own "point", as you noted, and no doubt
it's for good reasons. I just had partially misunderstood its point. See
below:

quoted text
> Almost nobody says "git fetch <URL>"; it is just a subpart of "git
> pull <URL>" [...]

Hmm, maybe. I recently wanted to join two purely local repos together.
Both of them had just one branch. Totally different histories so no
actual mergin would happen; just two branches in the same repo. I don't
know why but "git fetch /the/other/repo/" just happened to be the one
I tried first. I saw it fetched something but as no new branch appeared
and I had never heard of this FETCH_HEAD thing it was a "didn't work,
what should I try next?" thing. I think your idea of showing

quoted text
>   From git://host/path/to/repo
>    * [new branch]      foo -> FETCH_HEAD

would be really good. At least to me this would have been enough
information. As I'm starting to see the "point of doing fetch <URL>"
I take back what I proposed. Just a bit more information would be nice.

I have to agree with Ingo Molnar that sometimes Git is a bit un- or even
disinformative about what happened. One example is this "git fetch
<URL>". Maybe it's not a "sane thing to do" but users are like this. We
just try something and learn from it. To me "git fetch <URL>" was
a broken command (UI-wise) until I read your message (thanks again!). If
Git had told me that it created FETCH_HEAD I had learned fetch's habits
myself and likely wouldn't have come up with this "broken command"
conclusion.

Another thing I spoke of was this refs/ stuff. I know my way around with
them now, so maybe they are not actually confusing to me anymore. It's
just that I have noticed a pattern: I always use refs/heads/... in
certain places and refs/remotes/ in certain places. If such a pattern is
very common (well, I don't know if it is) one starts to think that maybe
the pattern can/should be hidden and made part of the tool. Just
thoughts.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html