Drew Northup writes:
> On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> I personally do not think the downside of breaking backward
>> compatibility is too bad. If we do this only when we already are
>> configured to keep remote tracking branch for branch $
On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> 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
>
> Now having said all that, we should probably revisit this and
On Tue, Oct 9, 2012 at 6:33 AM, Junio C Hamano wrote:
> * Unify pathspec semantics
>
>This has happened and commands that used to take only path prefix
>style pathspecs now take globs as well [ND]
I've been thinking about it lately and will probably restart soon with
a different approach
Junio C Hamano writes:
> 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
Now having said all that, we should probably revisit this and
possibly other issues and for the ones we can reach concensus, s
Junio C Hamano writes:
> Angelo Borsotti writes:
>
>> git fetch 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
Angelo Borsotti writes:
> git fetch 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 com
6 matches
Mail list logo
