On Wed, Apr 09, 2008 at 12:14:28PM +0200, Ingo Molnar wrote:
As you figured out later, the problem was that "git remote add" doesn't
actually fetch the remote's contents: it just sets up the remote. There
is a "-f" option which does the fetch automagically after adding.
In this case, had "-f" been the default, it would have Just Worked for
you. So that's something for us to consider, but I'm not sure if we
would annoy more users who _didn't_ want the fetch.
This is another place where we might have DWYM, by seeing that your
repository name started with "<name of a remote>/" and splitting it into
"<remote> <branch>". This could affect current usage, but it seems
unlikely that people have remote names which are exact prefixes (with
trailing slash) of non-remote repositories they are trying to fetch.
Reading "git help fetch" should show you the synopsis:
git-fetch <options> <repository> <refspec>
which maybe gives a clue about the syntax. But I think the problem here
is that there are two different syntaxes for what is _almost_ the same
thing. The ref refs/remotes/x86/latest, which you can call "x86/latest"
as a shorthand, and the (remote, refspec) pair (x86, latest).
Unless you are planning on merging this remote a lot, the common usage
is probably to just forget the remote stuff and do:
git pull ~/linux-2.6-x86.git latest
Yes, just showing the remotes would be consistent with what other
commands do (e.g., git-branch, git-tag). I'll post a patch in a minute.
That is an annoying message. Perhaps we could notice that it looks like
a file path (because it begins with '.') and suggest "maybe you wanted
to "git pull ..."?
-Peff
--
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
