git-fetch remote tag to local branch fails

Hi

I have a repository "bogustree" that contains tags "test_tag" and "foo_tag" (both on the same branch, with "test_tag" pointing to an older commit). I also have repository "R", which contains "test_tag" from "bogustree" and a branch "b" created from "test_tag". The active branch in R is "master".

Now I want to do the following from R:

git-fetch bogustree refs/tags/foo_tag:refs/heads/b

but this fails with the message given below. The interesting part is that git-fetch tries to write a "non-commit object" and indeed I have no idea what this thing is (the commit pointed to by "foo_tag" has commit ID cab0a25388f1884a1ab16bd0d66f877c0b36f1d5). Another interesting detail is that the command fails and then continues anyway. That seems wrong in itself.

# remote: Counting objects: 6, done. # remote: Compressing objects: 100% (2/2), done. # remote: Total 4 (delta 0), reused 0 (delta 0) # Unpacking objects: 100% (4/4), done. # error: Trying to write non-commit object 5f61233bc5dad0f3e25ecea65457f5bb528174d2 to branch refs/heads/B # From /home/qliklas/bogustree/b/b # 72f0622..5f61233 foo_tag -> b # From /home/qliklas/bogustree/b/b # * [new tag] foo_tag -> foo_tag # * [new tag] test_tag -> test_tag

Why can't I fetch like this? The manual page for git-fetch says that

       <refspec>
              The canonical format of a <refspec> parameter is +?<src>:<dst>;
              that is, an optional plus +, followed by the source ref,
              followed by a colon :, followed by the destination ref.

              The remote ref that matches <src> is fetched, and if <dst> is
              not empty string, the local ref that matches it is fast
              forwarded using <src>. Again, if the optional plus + is used,
              the local ref is updated even if it does not result in a fast
              forward update.

so I think it should be OK?

BR / Klas

On Tue, Jun 24, 2008 at 14:17, Klas Lindberg <klas.lindberg@gmail.com> wrote:

non-commit object is an object that is not a commit, like a tag, a blob or a tree, and you are trying to write a tag in refs/heads/. Only commits objects (no tags) are allowed in refs/heads/.

Are you sure it is written as a branch? What is the output of "git tag -l" and "git branch -a"?

as long as <src> are commit objects.

Santi

Hello

foo_tag test_tag

At this point, I can create the branch "b" from "foo_tag", so the fetch did get me a remote tag. It just didn't update a local branch with the contents (or create a new one).

Something that also confuses me is that if branch "b" already exists, then

actually does update branch "b". I find the behaviour quite inconsistent.

Unfortunately it isn't a solution for me to fetch tags and then create branches from the tags. I need to be able to update existing branches, and I have to do that without first making such a branch the current branch.

Any suggestions?

/Klas

On Tue, Jun 24, 2008 at 3:38 PM, Santi Béjar <sbejar@gmail.com> wrote:

On Tue, Jun 24, 2008 at 16:01, Klas Lindberg <klas.lindberg@gmail.com> wrote:

empty?

You asked explicitly to update branch b with :refs/heads/b.

If you have to update existing branches from remote branches you can:

git fetch <remote> refs/heads/<remotebranch>:refs/heads/<localbranch>

But normally you have some remote tracking branches, such as how the "origin" remote repository is configured.

Updating from remote tags is not normal, since tags are not supposed to change.

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

Santi

P.D.: Please, do not toppost.

Sorry, my mistake. It lists "master"

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.

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

I'm sorry. That was plain wrong. It doesn't update the branch from the remote tag when I pull.

Oh well...

On Tue, Jun 24, 2008 at 17:31, Klas Lindberg <klas.lindberg@gmail.com> wrote:

Maybe you should be using the plumbing commands.

What are the "other trees"?

Do you mean this?

1. You have a repository with different branches as:
  master
  tree1
  tree2
  ..

2. You want /path/to/tree1 to always checkout tree1
  and the same for treeN

Then

3. In /path/to/treeN/.. you do:
$ git clone /path/to/repo treeN
$ git checkout -b treeN origin/treeN

4. To keep uptodate:
$ git pull

5. The branches for the other trees are always uptodate in origin/*.

Sure. So you have to choose those that don't have these "side effects", you have plenty of them, mainly in the low-level, plumbing commands.

Well, if you touch the current branch, for sure, you want to update the working tree.

Maybe you want to keep your local branches up to date with respect their tracking branch?

I don't see the point updating a branch with a tag, but you can make a tool to update a branch with a tag, see for example contrib/examples/git-fetch.sh.

Santi

Yes. It looks like it.

One tree tracks a configuration file that just contains specs for other trees. The idea is something like this: Given a refspec on the configuration tree, git-view the configuration file and use the contained refspecs to clone/pull/fetch/reset/whatever a bunch of other trees.

Note that I'm not trying to solve the problem addressed by the submodules system in git; I need configuration management.

Well yes, but that is only half of it. One of the scenarios I'm pondering is this: A user wants to take an old configuration based on tags and try some use case that breaks a newer configuration. After the checkout, the working trees will not be "on" any branches (what's the word for that?). Unfortunately, most people seem to think that everything in a VCS happens on a branch. A lot of people will incorrectly assume that they are still on their "working branch" because they didn't check out a different branch! They checked out a tag and, like myself, have muddy ideas about what that actually means in relation to branches. I'd prefer to not have to tell them to try git-lost-found on a 40 different trees to recover commits that they made on non-branches.

I'll have to think more about this. It's not a functionality shortcoming, but a UI one.

Thank you. I'll have a look at that, but after our conversation I think I was mentally stuck in the land of some other VCS. I know perfectly well that a tag is not just a marker along some branch, but I realize now that I was thinking of it as if it was.

/Klas

"Klas Lindberg" <klas.lindberg@gmail.com> writes:

Why not use one of existing tools (see InterfacesFrontendsAndTools page on Git Wiki, http://git.or.cz/gitwiki/), like IsiSetup, or etckeeper?

Klas Lindberg venit, vidit, dixit 24.06.2008 16:01:

You tell git to fetch everything up to the tag you specify, to store those refs into branch b, and then to merge into the current branch. This is what git did (assuming you see the merge in the current branch; if it's b then it has been fast forwarded already).

If I try what you described (using git 1.5.6) in a fresh repo (with one empty commit) I get:

git fetch ../fromrepo refs/tags/testtag:refs/heads/newbranch
warning: no common commits
remote: Counting objects: 18, done.
remote: Compressing objects: 100% (18/18), done.
remote: Total 18 (delta 9), reused 0 (delta 0)
Unpacking objects: 100% (18/18), done.
 From ../fromrepo
  * [new branch]      testtag    -> newbranch
  * [new tag]         testtag    -> testtag

I see a new branch, disconnected from master (no common commits), and a new tag pointing to the head of newbranch. All is well here. Maybe you can set-up a minimal example or share a repo which exposes your problem?

Michael