>>> 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 -- 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
