git-mailinfo doesn't get installed any more

git-mailinfo doesn't get installed any more

[Tony Luck]

Periodically after I upgrade git I do an "ls -lrt /usr/local/bin" to
find stray old binaries that aren't part of git anymore.  I was
a bit surprised to see that git-mailinfo had a mod-time a bit
older than the rest of git ... and looking at the Makefile it looks
like it got dropped in some rearrangement.

Two things:
1) Can someone put it back please, git-applymbox is very unhappy
without it.

2) What's the cute 1-line git way to see when this was broken. I'm
guessing that it involves using a --pickaxe.

Thanks

-Tony

Re: git-mailinfo doesn't get installed any more

[Linus Torvalds]

On Fri, 24 Feb 2006, Tony Luck wrote:
> 
> 2) What's the cute 1-line git way to see when this was broken. I'm
> guessing that it involves using a --pickaxe.

You've actually found an interesting misfeature in git. There's a merge 
error, and you can't see it in the diffs by default because it wasn't due 
to a _clashing_ content thing, but two edits that were far enough away 
from each other.

That "git-mailinfo" thing is there in rev 2a3763ef, but it's not there in 
the current Makefile. And doing a

	git-whatchanged -p 2a3763ef.. | grep git-mailinfo

results in nothing. Which is not good.

Anyway, the way to handle that is to do "git bisect" (and use "grep 
git-mailinfo Makefile" in between bisection points to see if git-mailinfo 
is still part of the list of programs):

	git-bisect start
	# bad: [20d23f554d6cd40ffa0d41ccc9416bca867667e0] gitview: Bump the rev
	git-bisect bad 20d23f554d6cd40ffa0d41ccc9416bca867667e0
	# good: [2a3763ef3d26eb38c0a47997b8e5fd2a7c5214cc] avoid makefile override warning
	git-bisect good 2a3763ef3d26eb38c0a47997b8e5fd2a7c5214cc
	# bad: [ee072260dbff6914c24d956bcc2d46882831f1a0] Merge branch 'jc/nostat'
	git-bisect bad ee072260dbff6914c24d956bcc2d46882831f1a0
	# good: [551ce28fe1f2777eee7dd9c02bd44f55f4b32361] git-svn: 0.9.1: add --version and copyright/license (GPL v2+) information
	git-bisect good 551ce28fe1f2777eee7dd9c02bd44f55f4b32361
	# good: [5508a616631fb41531b638f744bd92c701727014] New test to verify that when git-clone fails it cleans up the new directory.
	git-bisect good 5508a616631fb41531b638f744bd92c701727014
	# bad: [712b1dd389ad5bcdbaab0279641f0970702fc1f1] Merge branch 'js/portable'
	git-bisect bad 712b1dd389ad5bcdbaab0279641f0970702fc1f1
	# good: [d800795613a710fb18353af53730e75185861f41] gitview: Use monospace font to draw the branch and tag name
	git-bisect good d800795613a710fb18353af53730e75185861f41
	# good: [b992933853ccffac85f7e40310167ef7b8f0432e] Fix "gmake -j"
	git-bisect good b992933853ccffac85f7e40310167ef7b8f0432e

resulting in:

	712b1dd389ad5bcdbaab0279641f0970702fc1f1 is first bad commit

which shows that there was a bad merge by Junio.

You can use

	git show -c -p 712b1dd389ad5bcdbaab0279641f0970702fc1f1

to see why. It merged the thing perfectly fine, but sadly, incorrectly. 

Somebody should probably look at whether we could have done things better, 
but I suspect that merge errors are inevitable with any automated process.

Anyway, it might be worth remembering that 712b1dd3 merge for future 
testing. Make a test-case out of it.

		Linus