git-whatchanged -p anomoly?

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

git-whatchanged -p anomoly?

From: "Luck, Tony" <tony.luck@intel.com>
Date: 2016-06-15 22:42:04

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?

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:04


On Thu, 18 Aug 2005, Luck, Tony wrote:
The spurious changes reported by "git-whatchanged -p" are:
quoted
 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 [off-list ref]

	    [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

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:04

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help