fetch <repo> <branch>:<branch> fetches tags?

Is this the intended behavior?

I'm pretty sure this was discussed recently on the list. My understanding was that tags would only be fetched automatically if a remote tracking branch was configured.

$ cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true

I expect these to fetch tags automatically (and they do):

   git fetch
   git pull
   git fetch <repo>
   git pull <repo>

I expect these to _not_ fetch tags (and they don't):

   git fetch <repo> <branch>
   git pull <repo> <branch>

But, I did not expect these to fetch tags:

   git fetch <repo> <branch>:<branch>
   git pull <repo> <branch>:<branch>

The association I am making here is between manually specifying the repo and branch implying "don't automatically fetch tags", and fetch/pull automatically determining the branch (and repo) implying "automatically fetch tags".

There is nothing automatic about that last form of fetch.

I know there is --no-tags, and I know I can do

   git fetch <repo> <branch>
   git branch <branch> FETCH_HEAD

But neither are what I expected to have to do. So I guess the colon notation implies remote tracking? I'm not sure I want the tags by default when I call fetch this way. In this instance I definitely did not want them.

-brandon

Hi,

On Mon, 28 Jan 2008, Brandon Casey wrote:

AFAICT yes. Whenever you say "git fetch" without "--no-tags", it should fetch those tags that reference objects that were fetched, and _only_ those.

Hth, Dscho

P.S.: What does the Navy do with git?

Johannes Schindelin wrote:

It doesn't always fetch tags only when "--no-tags" is missing. Sometimes it refrains from fetching tags even when "--no-tags" is missing.

$ mkdir test1 && cd test1 && git init && echo : > file1 && git add file1 &&
  git commit -m 'Commit1' file1 && git tag -m 'CommitTag1' tag1 && cd .. &&
  mkdir test2 && cd test2 && git init && git fetch ../test1 master &&
  git branch master FETCH_HEAD && cd ../test1 && echo -n 'Test1: ' &&
  git tag -n -l && cd ../test2 && echo -n 'Test2: ' && git tag -n -l | grep '' || echo 'NO TAGS'

Initialized empty Git repository in .git/
Created initial commit 0f701fc: Commit1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file1
Initialized empty Git repository in .git/
warning: no common commits
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
Test1: tag1            CommitTag1
Test2: NO TAGS

Notice the last two lines.

But, change that fetch to master:master and...

$ mkdir test1 && cd test1 && git init && echo : > file1 && git add file1 &&
  git commit -m 'Commit1' file1 && git tag -m 'CommitTag1' tag1 && cd .. &&
  mkdir test2 && cd test2 && git init && git fetch ../test1 master:master &&
  cd ../test1 && echo -n 'Test1: ' && git tag -n -l && cd ../test2 &&
  echo -n 'Test2: ' && git tag -n -l | grep '' || echo 'NO TAGS'

Initialized empty Git repository in .git/
Created initial commit d67022e: Commit1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file1
Initialized empty Git repository in .git/
warning: no common commits
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../test1
 * [new branch]      master     -> master
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
From ../test1
 * [new tag]         tag1       -> tag1
Test1: tag1            CommitTag1
Test2: tag1            CommitTag1

I only get the tags if I use the colon notation.

-brandon

Manage software of course! What a silly question.

Kidding aside. I work with oceanographers.

Brandon Casey <casey@nrlssc.navy.mil> writes:

Sigh... that matches my expectation.

Did we break it when we overhauled "git fetch", or was this an independent "improvement" that happened long before that?

Junio C Hamano <gitster@pobox.com> wrote:

I think during the git-fetch builtin marathon this got implemented, but probably as a feature masquerading as a bug fix and we didn't notice the regression.

The theory behind the expectation here is if we are fetching the object to a tracking ref then we probably want to watch it in the future. If we want to watch it and tag following was allowed, and we are missing a tag, we should follow the tag if we have the object graph under the tag complete.

Now what should:

	git pull <repo> <branch1>:<branch1> <branch2>

do, especially if <branch2> is referring to an object that you don't already have, that object also isn't reachable through <branch1>, but <branch2>^0 is the target of a tag <tag2> that you don't have? Should we get the tag anyway?

Personally I'd expect us to skip the tag pointing at <branch2>^0, based upon my description above, but I have a feeling we'd follow it anyway, as tag following was enabled and at least one item in the fetchspec provided asked for storage to a tracking ref and we have <tag2>^{} complete.

Of course even if we didn't follow that tag right away a future:

	git fetch <repo> <branch1>:<branch1>

might cause us to get the tag anyway, as <branch2>^0 is now reachable through HEAD, due to the implicit git-merge we ran above. ;-)

Junio C Hamano <gitster@pobox.com> writes:

Having said that, I do not particularly think the new behaviour is bad per-se. If you are storing what you fetched locally in tracking branches, you are interested in their work enough to want to auto-follow their tags.

It's just that the expectation you and I shared is the documented behaviour everywhere, and we would need to document the new behaviour.

Junio C Hamano <gitster <at> pobox.com> writes:

How is "tracking" defined? Is this a term that implies some configuration to link a local branch to a remote branch? Or is any local branch created from a remote branch considered "tracking"?

I thought that a tracking branch needed some setup like what the --track option to git-branch or git-checkout would do. If setup is required, then it implies some permanence to the branch and for the link between the branch and the remote. In this case I agree you would want to auto-follow tags.

-brandon

Brandon Casey <drafnel@gmail.com> writes:

I probably should have said "Instead of just letting fetch temporarily store the result in FETCH_HEAD and using it from there, you saved it away; that's a good indication of you care about it deeply enough".

It's really about what's convenient. I was somewhat upset that the behaviour change was not I was very aware of (perhaps I said it was a good idea and I then forgot), I didn't think the earlier behaviour was broken, but if I have to choose, I think the new behaviour is probably slightly nicer than the old one.

Junio C Hamano wrote:

It feels a little inconsistent to me.

With this behavior adopted as standard, then all forms of fetch will fetch tags except for 'git-fetch <repo> <branch>'. I think this is probably the least used form for porcelain.

What I understand you to be saying is that creating a branch during fetch indicates "I care deeply enough, so I want tags". At the moment, I don't know why I would fetch if I didn't want to make a branch. Even if I just wanted to cherry-pick one patch, or one source file, or (some other contrived example), I think I would create a branch to give it some anchor point, and why not create the branch during the fetch.

And, if I fetch now with the colon notation implying I want tags, later, if I 'git pull <repo> <branch>' from within that branch, why does that imply that I do not still want tags just because I'm not creating a 'new' branch.

I think the current metric for indicating "caring deeply enough" is the remote tracking configuration. Tracking implies "I care deeply enough, I want tags", lack of tracking does not imply this. But I said this already in another email. I am not sure if this feels right because it is documented or because it is right.

An alternative to this is to make fetch completely consistent so it either "always" gets tags, or "never" gets tags, and requires an option to reverse its behavior.

It seems to me that "never" gets tags is the safer choice. This is because accidentally fetching tags is a pain to clean up, but if I forget to ask for tags, I just run the same command again and ask this time. If I fetch or pull and use the --tags (the current --tags should be changed to --all-tags) then I know what I am doing.

The documented behavior for tracking branches and fetching tags could be retained by requiring a fetch option in the branch configuration and modifying git-remote and commands that use --track, to add the option by default. The big downside is that this would require existing repositories to update their config file which would also cause confusion.

-brandon