[BUG] Pulling tags no longer works in 1.5.3.4...

Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel git trees:

1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6

2) time passes (days or weeks)

3)	cd tmp-2.6
	git pull ../linux-2.6
	git pull --tags ../linux-2.6

Result:  works as expected.

Using package git-core-1.5.3.4-1.fc8, step #3 breaks:

[jgarzik@pretzel misc-2.6]$ git pull --tags ../linux-2.6/ You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me either. Please name which branch you want to merge on the command line and try again (e.g. 'git pull <repository> <refspec>'). See git-pull(1) for details on the refspec.

If you often merge with the same branch, you may want to configure the following variables in your configuration file:

     branch.master.remote = <nickname>
     branch.master.merge = <remote-ref>
     remote.<nickname>.url = <url>
     remote.<nickname>.fetch = <refspec>

See git-config(1) for details.

Hi,

On Mon, 3 Dec 2007, Jeff Garzik wrote:

Oops.

As a workaround, please do "git fetch --tags ../linux-2.6 && git pull ../linux-2.6/" until it is fixed.

Ciao, Dscho

On Mon, Dec 03, 2007 at 09:00:15PM -0500, Jeff Garzik wrote:

Hrm, when I try to reproduce using v1.5.3.3, I get the "Warning: No merge candidate found..." message. Between 1.5.3.3 and 1.5.3.4, this message got a bit longer and the exit code was fixed to indicate an error. Were you perhaps just missing the warning message, since no error was signaled?

At any rate, I think what you really want in step 3 is

  git fetch --tags ../linux-2.6

since you just want to grab the tags, and not merge anything (remember that pull is fetch+merge -- you are only interesting in the fetching side effect). You could also do this:

  git pull --tags ../linux-2.6 master

In general, "git pull --tags" without a branch to pull doesn't make much sense. What happens is that the "--tags" tells the fetch part of the pull operation to just grab the tags. Then the merge part of the pull operation looks in what has just been fetched for something merge-able. And of course there isn't anything, since all you fetched were tags.

-Peff

Jeff Garzik <jeff@garzik.org> writes:

This is tricky, and in order to decide the right course of action, we need to understand some background.

"git pull" is defined as "fetch the history missing at this end from the remote, and integrate the remote change to the current branch".

    Side note. Historically, "integrate ... to the current branch" was
    defined as "merge", so I would have phrased the above as "pull is
    fetch followed by merge", but I am being a bit careful here.
    Upcoming 1.5.4 will optionally allow you to rebase on top of what
    was fetched instead of merging.

Now, your second "git pull --tags" is about fetching the tags but what is it integrating? Nothing. What you wanted to would have been expressed much better with "git fetch --tags".

    Side note.  My conclusion at the end would NOT be "so your usage is
    wrong, do not complain", so swallow the "I do not care.  This has
    always worked!" for a while and read on.

    Side note.  For a long time, the first "git pull" from a repository
    you track with tracking branches followed the tags automatically,
    and there shouldn't be any reason to do a separate "fetch --tags"
    these days.

Now, what is integrated by "integration of remote change into the current branch" step has long been defined as "merge refspec explicitly given from the command line (if exists), otherwise use the first Pull: line in .git/remotes/ file or corresponding remote.*.fetch line in .git/config", no matter which branch you are on. This traditional definition was fine as long as the puller stayed on the primary integration branch.

Then people started using multiple branches in a single repository a lot more than before. Running "git pull" when you are on a branch that is not your primary integration branch still merged the default branch you get from the remote into your current branch. This behaviour was unpopular. Users, especially with ones with shared repository workflow, wanted to have branches A and B at the remote to correspond to their local branches A and B, and wanted to merge A from the remote when they issued "git pull" while on branch A and remote B while on branch B.

This was made possible by allowing branch.*.merge configuration variable set for each branch to specify what remote branch to merge in during git-pull. Everybody was happier. But the default stayed the same to help old timers (like us). Without such a configuration, "first refspec configured" rule still apply.

Now, some users ran "git pull" without configuring branch.*.merge and got the default (typically, "master") remote branch merged into the branch they happened to have checked out. Again this was unpopular.

So there was an additional safety devised, early December 2006. If branch.*.merge is not configured, "git-pull" may not find any remote branch to merge to the current branch without being told explicitly from the command line (i.e. "git pull $there master"). For such a case, the help message you saw is issued, instead of silently failing, to instruct the user about the configuration variable. This message, from the point of view of users who complained about the unpopular behaviour described above, was a bugfix. The earlier behaviour of not issuing any help message when you did "git pull --tags" was a bug.

Now with that long background story in mind...

Still, it does not make sense to "integrate the changes reachable from the tags to my current branch" at all. While we could argue that use of "git pull --tags" is a nonsense to begin with, we can also argue that the command line is saying "I am not interested in integrating anything I got from the remote with this fetch" explicitly from the command line.

We could just honor that and be silent in such a case, instead of giving the message you saw.

We could do something like the following patch, but it does feel like a special hack to keep "traditional misuse" working, doesn't it?

---
 git-pull.sh |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)