Re: git fetch documentation problem or bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Angelo Borsotti <angelo.borsotti@xxxxxxxxx> writes:
>
>> git fetch <repository> <refspec> does not create the remote refs in
>> the current (local)
>> repository...
>> However, if a git fetch origin is executed, the refs are properly created:
>
> Working as designed and documented.
>
>  $ git fetch origin master
>
> is giving the refspec "master" from the command line which is a
> short-hand for "refs/heads/master".
>
> When you run
>
>  $ git fetch origin
>
> configured refspec is looked up from your config (because you didn't
> give any from the command line).  The default refspec in your config
> is likely to be "refs/heads/*:refs/remotes/origin/*".
>
> The former, "refs/heads/master" refspec, tells Git not to update the
> remote tracking branch.  The latter has colon and right-hand-side of
> the colon tells Git what to update with what was fetched.
>
> It would hlep to read up on refspec by running "git fetch --help"
> and looking for a string "colon".

Addendum.  Your claim

>> git fetch <repository> <refspec> does not create the remote refs in
>> the current (local)
>> repository...

is incorrect.  The behaviour depends on what <refspec> you give.

In other words, you can do this from the command line if you want
to do the update.

  $ git fetch origin master:refs/remotes/origin/master
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]