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

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

[Jeff Garzik]

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.

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

[Johannes Schindelin]

Hi,

On Mon, 3 Dec 2007, Jeff Garzik wrote:

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

Oops.

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

Ciao,
Dscho

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

[Jeff King]

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

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

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

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

[Junio C Hamano]

Jeff Garzik <jeff@garzik.org> writes:

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

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

diff --git a/git-pull.sh b/git-pull.sh
index 74bfc16..00f73d1 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -97,6 +97,13 @@ case "$merge_head" in
 	esac
 	curr_branch=${curr_branch#refs/heads/}
 
+	nontag=$(sed -e '/	not-for-merge	tag/d' "$GIT_DIR/FETCH_HEAD")
+	case "$nontag" in
+	'')
+		exit 0 ;# git pull --tags
+		;;
+	esac
+
 	echo >&2 "You asked me to pull without telling me which branch you"
 	echo >&2 "want to merge with, and 'branch.${curr_branch}.merge' in"
 	echo >&2 "your configuration file does not tell me either.  Please"