RE: new file leaked onto release branch

Should I be using something different than git merge? is Documentation/howto/using-topic-branches out of date?

$ git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566 d2149b542382bfc206cb28485108f6470c979566

Doesn't appear to be the case, as I don't have a /usr/bin/git IIR, months ago I tried to install the rpm and it failed due to some incompatibility like not groking a SuSE destination. I got Dave's git tarball according to Jeff's howto: http://linux.yyz.us/git-howto.html and have been building and installing from a git repo since. (I found git-current tarball dated 7/21/05, so maybe it was then) I did, however a few months ago copy my i386 home directory over to the x86_64 box I use now, re-build and re-install. Dunno if there may have been a hickup in that process... I found a backup copy of my i386 bin directory from 2005-08-25 -- binaries still in i386 format. But I don't think I ran that b/c it isn't on any PATH. Git lives in ~/bin which is 1st in my PATH.

I think the lesson I'm taking away from this is that as I continue to stumble forward using git I should immediately report anything that doesn't look quite right while I can still guarantee that all the clues are still at the scene of the crime. I expect that I've re-built and re-installed git several times since the merge in question was made.

-Len

On Wed, 14 Dec 2005, Brown, Len wrote:

No, "git merge" should be fine. It's what "git pull" ends up doing internally, which is why I suspected an old git version: "git merge" should be well-tested, since it's very much what I end up using every day when I pull stuff.

Ok, that's correct.

git-merge does:

	common=$(git-merge-base --all $head "$@")

and then it _should_ have triggered this case:

	case "$#,$common,$no_commit" in
	..
	1,"$1",*)
		# If head can reach all the merge then we are up to date.
		# but first the most common case of merging one remote
		echo "Already up-to-date."
		dropsave
		exit 0
		;;
	..

and thus never have created any merge messages.

That's what I get when I try this:

	git checkout -b test-merge 0a47c906342e2447003e207d23917dfa5c912071
	git merge "Testing merging" HEAD d2149b542382bfc206cb28485108f6470c979566

results in a very immediate

	"Already up-to-date."

message. Does it do that for you too?

I tested not only with current git, but also the gits that were valid on Nov 29 and Nov 30. All of them did this.

Hmm. It really looks like it should have been impossible to generate that commit with current git, which is why I'm still a bit suspicious.

I think this list has been pretty responsive to reports of strange behaviour, so yes.

			Linus

Linus Torvalds <torvalds@osdl.org> writes:

Two good news (one puzzle fully explained, one bug fixed) and one not so good news (one puzzle still remains).

First good news. I solved this puzzle. This has been fixed as a part of a seemingly independent fix:

    commit 9954f5b876abb6118f9bdf1d113239d86acca7bd
    Author: Junio C Hamano <junkio@cox.net>
    Date:   Tue Dec 13 17:01:23 2005 -0800

        [PATCH] allow merging any committish

        Although "git-merge" is advertised as the end-user level command
        (instead of being a "git-pull" backend), it was not prepared to
        take tag objects that point at commits and barfed when fed one.
        Sanitize the input while we validate them, for which we already
        have a loop.

        Signed-off-by: Junio C Hamano <junkio@cox.net>

There was a bug in git-merge which used the user input without converting them to object names. When the part you quoted above was executed, $1..${$#} were remote ref parameters from the command line, so in the case of Len's commit, which did:

      git merge "Auto-update from upstream" release linus

"$1" at that point was string "linus", not the object name returned from "git-rev-parse --verify linus". The case pattern match did not match because $common was object name and $1 was not. This was fixed by the above commit; the user supplied refs are already converted into object names at that point with the current code.

I have never seen this problem myself because git-pull feeds object names after converting refnames to git-merge, but people who used the git-merge command themselves could have been affected by the bug.

So I think I am done with the "this is "already-up-to-date"; why does that commit exists in the first place?" commit we have discussed in this thread.

Second good news. I have been working on a theory on the "where did this file come from?" problem. I found a real bug that can cause a bad mismerge that can introduce completely unrelated changes to the tree, but after digging a bit deeper, I do not think it matches Len's problematic commit. It still is a bug.

If you run the sequence attached at the end in an empty repository, you will have a repository suitable for this demonstration. After the script runs, the commit structure would look like this:

! [heads/7589] add xyzzy
 * [master] Merge 7589 branch
  ! [nitfol] add nitfol
---
+   [8eec60c] add xyzzy			<tag 7589>
 +  [db5bc99] edit frotz
  + [758916c] add nitfol
+++ [70c4319] initial

There are three branches: master, nitfol, and "7589". They all start from the initial commit which has one file "frotz" and each branch adds one commit. Also the tip of 7589 branch is tagged as "7589". Now, we will run this:

	$ git merge "Merge 7589 branch" HEAD 7589

With this setup, the current tip of the "master" branch mismerges and adds "nitfol" file which did not exist in either branch heads (and it is not fixed with the 9954f5 commit above).

A change I introduced mid November causes get_sha1_basic() to misinterpret "7589" to be neither the tag 7589 nor branch 7589 tip, but by mistake it does not outright fail, but returns the 758916c commit! This merge ends up pulling nitfol branch head into master branch, not 7589 branch as the user intended. The resulting merge commit has db5bc99 and 758916c as its parents.

The "revert misguided disambiguation" patch I posted earlier fixes this problem. I'll push it out tonight.

This theory however does not seem to match what really happened. Len did mention that he has "5165" branch (there is a commit marked "Pull 5165 into release branch" near a problematic merge), but he did not say he also has a 5165 tag; the bug does not trigger if you do not have the tag of the same name. Also if this theory holds true, the problematic commit should have a commit whose object name begins with 5165 as the second parent but that is not the case. And the problem happened with a commit that is not a merge between release/test and topic branch anyway; it is with an "Auto-update from upstream" commit.

So I am still puzzled by the "where did this file come from" problem. The most plausible explanation was the driver error mentioned already in the thread: "update-index --add" in the middle of merge with manual committing.

---------------------------------------------------------------- #!/bin/sh

GIT_AUTHOR_DATE='1995-01-29T15:00:00 -0800' GIT_AUTHOR_EMAIL='author@example.com' GIT_AUTHOR_NAME='A U Thor' GIT_COMMITTER_DATE='1995-01-29T15:00:00 -0800' GIT_COMMITTER_EMAIL='committer@example.com' GIT_COMMITTER_NAME='C O Mmitter'

export GIT_AUTHOR_DATE export GIT_AUTHOR_EMAIL export GIT_AUTHOR_NAME export GIT_COMMITTER_DATE export GIT_COMMITTER_EMAIL export GIT_COMMITTER_NAME

git init-db

echo frotz >frotz git add frotz git commit -m 'initial'

git checkout -b nitfol echo nitfol >nitfol git add nitfol git commit -m 'add nitfol'

git checkout -b 7589 master echo xyzzy >xyzzy git add xyzzy git commit -m 'add xyzzy' git tag 7589

git checkout master echo FROTZ >frotz git update-index frotz git commit -m 'edit frotz'

"Brown, Len" <len.brown@intel.com> writes:

I reviewed it once again right now. The document claims to be last updated for 0.99.9f, but I do not see anything outdated in there for the latest. Tony's procedure looks valid [*1*], so do the scripts you sent in this thread.

Sorry, but I do not seem to be able to spot anything obviously wrong with your troubled commits nor scripts. I'll do some more digging, including rewinding to an older git and trying them, but I am pessimistic.

I pointed out one anomaly which is the commit should never have been created because it was not even a fast forward but already up-to-date case, and it was followed up with exchange of a few messages between Linus and you. But even if we got that mixed up, the resulting merge should not have contained the file neither parents had. That part worries me the most.

One question. You mentioned these in your message, you have a "git.commit wrapper" that contains these lines:

    git-update-index --add --remove `quilt files`
    git commit

I am not familiar with 'quilt', but is "quilt files" the command to show the list of files with patches applied to the working tree?

If so, the above do tell git about the modified (including added or removed) files that the applied quilt patches touch, which sounds like the correct thing to do.

But the resulting commit from that procedure would not be a merge commit, and the commit in question that had the rsinfo file magically appeared from nowhere is a merge, so this does not seem to have much to do with the current problem...

Still puzzlled, sorry.

[Footnote]

*1* Except that the rsync transport is probably suboptimal for people who stay reasonably up-to-date with Linus and I would apply the following change if I were Tony, but that shouldn't have anything to do with the trouble we are discussing here.

---

On Wed, Dec 14, 2005 at 12:45:51PM -0800, Junio C Hamano wrote:

I don't remember any of the details now, but I remember that an old version of git or cogito would create bogus fast-forward merges, if they were used without GNU coreutils. The machine it happend on was running FreeBSD 4.10, but current versions work fine.

  Tom