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
fetch'.
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
