From: Klas Lindberg <klas.lindberg@gmail.com>
Date: Tue, 24 Jun 2008 15:31:49 GMT
Subject: Re: git-fetch remote tag to local branch fails
Message-ID: <33f4f4d70806240831q14caacddp66645e1bcfb6d14b@mail.gmail.com>
In-Reply-To: <8aa486160806240727r6fc6de6doec8300700293a3a7@mail.gmail.com>

>>> git branch -a
>>>
>
> empty?

Sorry, my mistake. It lists "master"

>>> git-pull bogustree refs/tags/foo_tag:refs/heads/b
>>
>> actually does update branch "b". I find the behaviour quite inconsistent.
>
> You asked explicitly to update branch b with :refs/heads/b.

I'm not sure what you mean. I asked it to update local branch "b"
against remote tag "foo_tag" and it did just that. I find it
inconsistent that pull can do this, but fetch can't.

> Can you explain why you have to do it this way? Or the whole workflow?

I am looking into the possibility of writing a tool that handles
configurations of trees. For instance, I want the tool to be able to
consume some version of a configuration and create, update or reset
branches in other trees accordingly.
The main stumbling block is actually that a lot of git commands have
side effects on the working tree (usually because they do something
with a "current" branch). In my mind, the user should be able to
select a configuration that effectively fast forwards branches in some
trees and resets branches in others -- all of it without touching any
working trees (unless there is an explicit checkout).
The example in this case is that fetching tags to update a branch
isn't possible. Pulling *is* possible, but would also update the
current branch and the working tree.

/Klas