On Thu, May 16, 2013 at 4:54 AM, Ramkumar Ramachandra
<artag...@gmail.com> wrote:
> Felipe Contreras wrote:
>> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
>> fatal: Refusing to fetch into current branch
>> refs/heads/fc/fast-export/cleanup of non-bare repository
>> fatal: The remote end hung up unexpectedly
> That's because your HEAD is pointing to something under refs/heads/*:
> it would work otherwise.  When I'm developing on my personal branch, I
> sometimes do 'git fetch origin master:master +pu:pu +next:next', and
> it works as expected.  When on master branch, I can't git fetch origin
> master:master and this is a cute safety feature.

Now you know what's the problem.

> Either way, I think it's a bad practice to fetch directly into
> refs/heads/*: you should really be fetching to refs/remotes and then
> merging your changes in.  I do want shortcuts though, which is why I'm
> interested in fixing pull: there is nothing to fix in fetch as far as
> I'm concerned.

It doesn't matter if you think it's a bad practice or not, 'git push
--mirror' works, and it's possible to update a branch even if HEAD is
point to it. There should be a possibility to do the same with 'git

Right now the user is forced to do something like:

        git checkout -q -b tmp &&
        git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*' 
        git checkout -q @{-1} &&
        git branch -q -D tmp 2> /dev/null

Which doesn't seem to be quite right.

Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to