git-whatchanged -p anomoly?

git-whatchanged -p anomoly?

[Luck, Tony]

Yesterday I was all happy ... Linus pulled a couple of changes from
my tree, and after I did a pull back from his tree into my "linus"
tracking branch, my status scripts correctly identified the branches
that I'd been using to track those changes as being no longer needed.

But this morning I ran another one of my status scripts that does

 $ git-whatchanged -p test ^linus | diffstat -p1

and was surprised when it reported changes in 10 files that I knew
I hadn't touched (the other 18 files it reported looked correct).

So I ran:

 $ git-whatchanged test ^linus | git-shortlog

and this just reported the changesets that I expected.

 $ git-diff-tree -p linus test | diffstat -p1

shows what I expect to see.

The current heads of the two branches are:

linus=30d5b64b63fa69af31b2cba32e6d71d68526eec9
test=0e595ad82db1b42d631e581630eb3fbeebb3c285

my tree is at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git

The spurious changes reported by "git-whatchanged -p" are:

>  Documentation/acpi-hotkey.txt              |    3 
>  Documentation/kernel-parameters.txt        |    5 
>  drivers/acpi/osl.c                         |    6 
>  fs/jfs/inode.c                             |    4 
>  fs/jfs/jfs_logmgr.c                        |   36 -
>  fs/jfs/jfs_logmgr.h                        |    2 
>  fs/jfs/jfs_txnmgr.c                        |   12 
>  fs/jfs/super.c                             |    4 
>  include/asm-i386/processor.h               |    2 
>  include/asm-x86_64/processor.h             |    2 

Is this a bug, or am I just confused about how "git-whatchanged" works?

-Tony

Re: git-whatchanged -p anomoly?

[Linus Torvalds]

On Thu, 18 Aug 2005, Luck, Tony wrote:
> 
> The spurious changes reported by "git-whatchanged -p" are:
> 
> >  Documentation/acpi-hotkey.txt              |    3 
> >  Documentation/kernel-parameters.txt        |    5 
> >  drivers/acpi/osl.c                         |    6 
> >  fs/jfs/inode.c                             |    4 


Ehh. These are all from:

	Author: Alex Williamson <alex.williamson@hp.com>

	    [IA64, X86_64] fix swiotlb sizing

in commit b63d6e09b432e6873d072a767c87218f8e73e66c.

And you've signed off on it.

Do a

	git-diff-tree -p --pretty b63d6e09b432e6873d072a767c87218f8e73e66c | less -S

to see it in all its glory.

Now, I suspect you didn't mean to commit that thing: it really looks like 
you've mixed up your patches somehow, because the commit message seems to 
match only a very small portion of the patch.

Did you perhaps have a failed merge or something that was in your index 
when you applied that patch? If you have a dirty index when you do 
"git-applymbox", it the commit done as part of the applymbox might commit 
other state too.

(git-applymbox _does_ verify that the files that it patches are up-to-date 
in the index, but it does _not_ verify that the index matches the current 
HEAD. I guess I could add a sanity check for that...)

> Is this a bug, or am I just confused about how "git-whatchanged" works?

It's definitely not a bug in git-whatchanged, and I don't think you're 
confused about how git-whatchanged is supposed to work. But I think you've 
committed a bad patch.

		Linus

git-applymbox: verify that index is clean

[Linus Torvalds]

This makes git-applymbox verify that the index matches the current HEAD 
before it starts applying patches.

Otherwise, you might have updated the index with unrelated changes, and 
the first patch will commit not just the patch from the mbox, but also any 
changes you had in your index.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----

This was brough on by: Tony Luck's problem, which _might_ be due to index
file change contents that got committed together with a real patch. This
will make it much harder to make that particular mistake.

On Thu, 18 Aug 2005, Linus Torvalds wrote:
>
> (git-applymbox _does_ verify that the files that it patches are up-to-date 
> in the index, but it does _not_ verify that the index matches the current 
> HEAD. I guess I could add a sanity check for that...)

diff --git a/tools/git-applymbox b/tools/git-applymbox
--- a/tools/git-applymbox
+++ b/tools/git-applymbox
@@ -18,6 +18,8 @@
 ## use a Signoff_file, because applypatch wants to append the sign-off
 ## message to msg-clean every time it is run.
 
+. git-sh-setup-script || die "Not a git archive"
+
 keep_subject= query_apply= continue= resume=t
 while case "$#" in 0) break ;; esac
 do
@@ -39,6 +41,12 @@ case "$continue" in
 	shift
 esac
 
+files=$(git-diff-cache --cached --name-only HEAD) || exit
+if [ "$files" ]; then
+   echo "Dirty index: cannot apply patches (dirty: $files)" >&2
+   exit 1
+fi
+
 case "$query_apply" in
 t)	touch .dotest/.query_apply
 esac

Re: git-whatchanged -p anomoly?

[Junio C Hamano]

"Luck, Tony" <tony.luck@intel.com> writes:

>  $ git-whatchanged -p test ^linus | diffstat -p1
>  $ git-diff-tree -p linus test | diffstat -p1

git-whatchanged internally uses git-rev-list which skips merge
commits.  You need '-m' to cause it not to.

    $ git-whatchanged -m -p linus..test | diffstat -p1

would still not _match_ "git-diff-tree -p linus test | diffstat
-p1" output because conflict-resolving merges inevitably causes
the same file to be touched twice (hence diffstat shows patches
for the same fime twice, adding up the count of the changes), so
in practice, my "use -m if you want to see merges" advice would
not be much useful if you want to _count_ lines using diffstat.

For example, one of the files you had trouble with are touched
by the following commits; only the last one is a non-merge and
that is what you get when you do not give -m to whatchanged:

$ git-whatchanged -m --pretty=oneline test ^linus \
	-p Documentation/acpi-hotkey.txt

diff-tree 75304b938dcc2cb89c2bb1174a92ffc76520a899 (from 470ceb05d9a2b4d61c19fac615a79e56e8401565)
Pull ngam-maule-steiner into test branch
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
--- a/Documentation/acpi-hotkey.txt
+++ b/Documentation/acpi-hotkey.txt
@@ -33,3 +33,6 @@ The result of the execution of this aml
 attached to /proc/acpi/hotkey/poll_method, which is dnyamically
 created.  Please use command "cat /proc/acpi/hotkey/polling_method"
 to retrieve it.
+
+Note: Use cmdline "acpi_generic_hotkey" to over-ride
+loading any platform specific drivers.

diff-tree 2dbff4d454d3ee733f120ad531560a734a6e39d6 (from 715caa83e762c86241ae4450693bb969d03027c4)
Auto-update from upstream
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
--- a/Documentation/acpi-hotkey.txt
+++ b/Documentation/acpi-hotkey.txt
@@ -33,3 +33,6 @@ The result of the execution of this aml
 attached to /proc/acpi/hotkey/poll_method, which is dnyamically
 created.  Please use command "cat /proc/acpi/hotkey/polling_method"
 to retrieve it.
+
+Note: Use cmdline "acpi_generic_hotkey" to over-ride
+loading any platform specific drivers.

diff-tree f812175c8007fdb614833830ca107062df2845dd (from c1ffb910f7a4e1e79d462bb359067d97ad1a8a25)
Pull prarit-bus-sysdata into test branch
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
--- a/Documentation/acpi-hotkey.txt
+++ b/Documentation/acpi-hotkey.txt
@@ -33,6 +33,3 @@ The result of the execution of this aml
 attached to /proc/acpi/hotkey/poll_method, which is dnyamically
 created.  Please use command "cat /proc/acpi/hotkey/polling_method"
 to retrieve it.
-
-Note: Use cmdline "acpi_generic_hotkey" to over-ride
-loading any platform specific drivers.

diff-tree b63d6e09b432e6873d072a767c87218f8e73e66c (from 12aaa0855b39b5464db953fedf399fa91ee365ed)
[IA64, X86_64] fix swiotlb sizing
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
--- a/Documentation/acpi-hotkey.txt
+++ b/Documentation/acpi-hotkey.txt
@@ -33,6 +33,3 @@ The result of the execution of this aml
 attached to /proc/acpi/hotkey/poll_method, which is dnyamically
 created.  Please use command "cat /proc/acpi/hotkey/polling_method"
 to retrieve it.
-
-Note: Use cmdline "acpi_generic_hotkey" to over-ride
-loading any platform specific drivers.

RE: git-whatchanged -p anomoly?

[Luck, Tony]

>Now, I suspect you didn't mean to commit that thing: it really looks like 
>you've mixed up your patches somehow, because the commit message seems to 
>match only a very small portion of the patch.
>
>Did you perhaps have a failed merge or something that was in your index 
>when you applied that patch? If you have a dirty index when you do 
>"git-applymbox", it the commit done as part of the applymbox might commit 
>other state too.

Yes I had a failed merge ... I thought that I had cleaned up from it, but
clearly I hadn't.  Bother.

I guess I have a bit of tree maintenance to do ... But I think that it
should be easy ... I can just step "test" back to before I merged in
the Alex patch.  Redo the Alex patch properly.  Then re-merge all the
branches that happened after this.  Followed by crossing my fingers and
running "git prune".

Maybe I'll try all that in a *copy" of my GIT tree first!

-Tony

RE: git-whatchanged -p anomoly?

[Linus Torvalds]

On Thu, 18 Aug 2005, Luck, Tony wrote:
> 
> Yes I had a failed merge ... I thought that I had cleaned up from it, but
> clearly I hadn't.  Bother.

The simplest way of cleaning up after a failed merge is just a simple "git
reset", which will also tell you if you need to perhaps clean up
afterwards (equally easily done with "git checkout -f" if you just want to 
blow all the changes away.

> I guess I have a bit of tree maintenance to do ... But I think that it
> should be easy ... I can just step "test" back to before I merged in
> the Alex patch.  Redo the Alex patch properly.  Then re-merge all the
> branches that happened after this.  Followed by crossing my fingers and
> running "git prune".
> 
> Maybe I'll try all that in a *copy" of my GIT tree first!

Yup. Think of it as a good exercise in git ;)

Btw, it's a shame that git has all these "git rebase" etc helper scripts, 
which rebase whole series of patches, but the simple "git re-do" which 
basically ends up being a

	git-diff-tree -p $old | git-apply --index &&
		git commit --reedit=$old

doesn't have a nice helper script.

Anyway, the easiest approach may be to just do

	git branch new-test-branch <good-point>
	git format-patch -o patchdir --mbox <good-point>
	git checkout new-test-branch
	.. edit the individual patches in patchdir/* to taste ..
	cat git-applymbox patchdir/* | git-applymbox

or similar. 

		Linus

RE: git-whatchanged -p anomoly?

[Johannes Schindelin]

Hi,

On Thu, 18 Aug 2005, Linus Torvalds wrote:

> Btw, it's a shame that git has all these "git rebase" etc helper scripts, 
> which rebase whole series of patches, but the simple "git re-do" which 
> basically ends up being a
> 
> 	git-diff-tree -p $old | git-apply --index &&
> 		git commit --reedit=$old

How about "git-cherry-pick-script"? Junio?

Ciao,
Dscho

RE: git-whatchanged -p anomoly?

[Luck, Tony]

>Yup. Think of it as a good exercise in git ;)

Fixed now (I hope).

-Tony