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

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

[Brandon Casey]

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

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

[Johannes Schindelin]

Hi,

On Mon, 28 Jan 2008, Brandon Casey wrote:

> Is this the intended behavior?

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?

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

[Brandon Casey]

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 28 Jan 2008, Brandon Casey wrote:
> 
>> Is this the intended behavior?
> 
> AFAICT yes.  Whenever you say "git fetch" without "--no-tags", it should 
> fetch those tags that reference objects that were fetched, and _only_ 
> those.

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


> 
> Hth,
> Dscho
> 
> P.S.: What does the Navy do with git?

Manage software of course! What a silly question.

Kidding aside. I work with oceanographers.

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

[Junio C Hamano]

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

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

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?

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

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> >
> > But, I did not expect these to fetch tags:
> >
> >    git fetch <repo> <branch>:<branch>
> >    git pull <repo> <branch>:<branch>
> 
> 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?

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.  ;-)

-- 
Shawn.

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

[Junio C Hamano]

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

> Brandon Casey <casey@nrlssc.navy.mil> writes:
> ...
>> 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>
>
> 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?

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.

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

[Brandon Casey]

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

> 
> Junio C Hamano <gitster <at> pobox.com> writes:
> 
> > Brandon Casey <casey <at> nrlssc.navy.mil> writes:
> > ...
> >> 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>
> >
> > 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?
> 
> 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.

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

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

[Junio C Hamano]

Brandon Casey <drafnel@gmail.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.
>
> 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 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.

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

[Brandon Casey]

Junio C Hamano wrote:
> Brandon Casey <drafnel@gmail.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.
>> 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 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.

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