RE: git-whatchanged -p anomoly?
>Yup. Think of it as a good exercise in git ;) Fixed now (I hope). -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
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 git format-patch -o patchdir --mbox git checkout new-test-branch .. edit the individual patches in patchdir/* to taste .. cat git-applymbox patchdir/* | git-applymbox or similar. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
>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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-whatchanged -p anomoly?
"Luck, Tony" <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-whatchanged -p anomoly?
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 <[EMAIL PROTECTED]> [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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-whatchanged -p anomoly?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
