{"thread":{"id":"14083","subject":"linux-x86-tip: pilot error?","startedAt":"2008-06-22T12:36:20Z","lastAt":"2008-06-23T16:14:56Z","messageCount":15,"participants":["Paul E. McKenney","Mikael Magnusson","Björn Steinbrink","Ingo Molnar","Jeff King","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"80604","messageId":"20080622123620.GA9328@linux.vnet.ibm.com","threadId":"14083","inReplyTo":null,"subject":"linux-x86-tip: pilot error?","fromName":"Paul E. McKenney","fromEmail":"paulmck@linux.vnet.ibm.com","sentAt":"2008-06-22T12:36:20Z","receivedAt":"2008-06-22T12:36:20Z","isPatch":false,"sender":{"key":"paulmck@linux.vnet.ibm.com","avatar":null},"body":"Hello, Ingo,\n\nI took the precaution of rebuilding my linux-2.6-tip from scratch as follows:\n\n 544 mkdir linux-2.6-tip\n 545 cd linux-2.6-tip\n 546 git-init-db\n 547 git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n 548 git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git\n 549 git-remote update\n 550 git-checkout tip-core-rcu-2008-06-16_09.23_Mon\n\nThe \"git-checkout\" command complained as follows:\n\n\twarning: You appear to be on a branch yet to be born.\n\twarning: Forcing checkout of tip-core-rcu-2008-06-16_09.23_Mon.\n\tChecking 24254 files out...\n\t 100% (24254/24254) done\n\tfatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.\n\tUse '--' to separate paths from revisions\n\tCannot detach HEAD\n\nIn addition, the kernel/rcutorture.c file does not have the \"stutter\"\nchanges in it after doing this checkout.\n\nDid I mess something up? Am I working with a too-old version of git\n(git version 1.5.2.5)? Or has git simply taken a deep and personal\ndisliking to me? ;-)\n\nMy next step will be to try a more recent version of git. In parallel,\nI will just re-do the patch on top of my patch stack.\n\n\t\t\t\t\t\t\tThanx, Paul\n\nPS. I am assuming that the repeated messages from git-update of\n the following form are expected behavior when there are tags:\n\n * refs/tags/tip-x86-xsave-2008-05-26_08_54_Mon: storing tag 'tip-x86-xsave-2008-05-26_08_54_Mon' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip\n commit: d40ace0\n"},{"id":"80607","messageId":"237967ef0806220548t3fd73211v354071efe2db22e4@mail.gmail.com","threadId":"14083","inReplyTo":"20080622123620.GA9328@linux.vnet.ibm.com","subject":"Re: linux-x86-tip: pilot error?","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2008-06-22T12:48:35Z","receivedAt":"2008-06-22T12:48:35Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2008/6/22 Paul E. McKenney :\n> Hello, Ingo,\n>\n> I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:\n>\n> 544 mkdir linux-2.6-tip\n> 545 cd linux-2.6-tip\n> 546 git-init-db\n> 547 git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> 548 git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git\n> 549 git-remote update\n> 550 git-checkout tip-core-rcu-2008-06-16_09.23_Mon\n\nWhen checking out remote branches, you have to specify the remote:\ngit checkout tip/tip-blabla\n(it'll warn about detaching HEAD, this is normal).\n\n-- \nMikael Magnusson\n"},{"id":"80608","messageId":"20080622132105.GD22569@linux.vnet.ibm.com","threadId":"14083","inReplyTo":"237967ef0806220548t3fd73211v354071efe2db22e4@mail.gmail.com","subject":"Re: linux-x86-tip: pilot error?","fromName":"Paul E. McKenney","fromEmail":"paulmck@linux.vnet.ibm.com","sentAt":"2008-06-22T13:21:05Z","receivedAt":"2008-06-22T13:21:05Z","isPatch":false,"sender":{"key":"paulmck@linux.vnet.ibm.com","avatar":null},"body":"On Sun, Jun 22, 2008 at 02:48:35PM +0200, Mikael Magnusson wrote:\n> 2008/6/22 Paul E. McKenney :\n> > Hello, Ingo,\n> >\n> > I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:\n> >\n> > 544 mkdir linux-2.6-tip\n> > 545 cd linux-2.6-tip\n> > 546 git-init-db\n> > 547 git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> > 548 git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git\n> > 549 git-remote update\n> > 550 git-checkout tip-core-rcu-2008-06-16_09.23_Mon\n> \n> When checking out remote branches, you have to specify the remote:\n> git checkout tip/tip-blabla\n> (it'll warn about detaching HEAD, this is normal).\n\nThank you, Mikael!\n\nBut when I try \"git-checkout tip/tip-core-rcu-2008-06-16_09.23_Mon\",\nit says:\n\n\terror: pathspec 'tip/tip-core-rcu-2008-06-16_09.23_Mon' did not match any file(s) known to git.\n\tDid you forget to 'git add'?\n\nTrying \"git-checkout tip/tip-core-rcu\" gets me:\n\n\terror: pathspec 'tip/tip-core-rcu' did not match any file(s) known to git.\n\tDid you forget to 'git add'?\n\nTrying \"git-checkout -b tip-core-rcu tip/tip-core-rcu\" gets me:\n\n\tgit checkout: updating paths is incompatible with switching branches/forcing\n\tDid you intend to checkout 'tip/tip-core-rcu' which can not be resolved as commit?\n\nTrying \"git-checkout -b tip-core-rcu tip/tip-core-rcu-2008-06-16_09.23_Mon\"\ngets me:\n\n\tgit checkout: updating paths is incompatible with switching branches/forcing\n\tDid you intend to checkout 'tip/tip-core-rcu-2008-06-16_09.23_Mon' which can not be resolved as commit?\n\nTrying \"git-checkout -b tip-core-rcu tip-core-rcu-2008-06-16_09.23_Mon\"\nacts like it is doing something useful, but doesn't find the recent updates,\nwhich I believe happened -before- June 16 2008.\n\nHelp???\n\n\t\t\t\t\t\t\tThanx, Paul\n"},{"id":"80643","messageId":"237967ef0806221411x39f57434p949b0ff13dfce8a@mail.gmail.com","threadId":"14083","inReplyTo":"20080622132105.GD22569@linux.vnet.ibm.com","subject":"Re: linux-x86-tip: pilot error?","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2008-06-22T21:11:07Z","receivedAt":"2008-06-22T21:11:07Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2008/6/22 Paul E. McKenney :\n> On Sun, Jun 22, 2008 at 02:48:35PM +0200, Mikael Magnusson wrote:\n>> 2008/6/22 Paul E. McKenney :\n>> > Hello, Ingo,\n>> >\n>> > I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:\n>> >\n>> > 544 mkdir linux-2.6-tip\n>> > 545 cd linux-2.6-tip\n>> > 546 git-init-db\n>> > 547 git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n>> > 548 git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git\n>> > 549 git-remote update\n>> > 550 git-checkout tip-core-rcu-2008-06-16_09.23_Mon\n>>\n>> When checking out remote branches, you have to specify the remote:\n>> git checkout tip/tip-blabla\n>> (it'll warn about detaching HEAD, this is normal).\n>\n> Thank you, Mikael!\n>\n> But when I try \"git-checkout tip/tip-core-rcu-2008-06-16_09.23_Mon\",\n> it says:\n>\n> error: pathspec 'tip/tip-core-rcu-2008-06-16_09.23_Mon' did not match any file(s) known to git.\n> Did you forget to 'git add'?\n>\n> Trying \"git-checkout tip/tip-core-rcu\" gets me:\n>\n> error: pathspec 'tip/tip-core-rcu' did not match any file(s) known to git.\n> Did you forget to 'git add'?\n>\n> Trying \"git-checkout -b tip-core-rcu tip/tip-core-rcu\" gets me:\n>\n> git checkout: updating paths is incompatible with switching branches/forcing\n> Did you intend to checkout 'tip/tip-core-rcu' which can not be resolved as commit?\n>\n> Trying \"git-checkout -b tip-core-rcu tip/tip-core-rcu-2008-06-16_09.23_Mon\"\n> gets me:\n>\n> git checkout: updating paths is incompatible with switching branches/forcing\n> Did you intend to checkout 'tip/tip-core-rcu-2008-06-16_09.23_Mon' which can not be resolved as commit?\n>\n> Trying \"git-checkout -b tip-core-rcu tip-core-rcu-2008-06-16_09.23_Mon\"\n> acts like it is doing something useful, but doesn't find the recent updates,\n> which I believe happened -before- June 16 2008.\n>\n> Help???\n\nOh, i didn't realize you were trying to check out a tag... In that case\nthe commands you gave were correct. I could successfully run your commands\nhere (though i have no idea if the file you talk about is up to date or not).\n\nIt's probably worth trying a newer version of git, could be a bug I guess.\nGiven the error message you could also try first checking out a branch, and\nthen the tag. ie git checkout -b master linus/master; git checkout tip-foo\nIt could also be that the tag just doesn't point to the commit you expect..\n\n-- \nMikael Magnusson\n"},{"id":"80646","messageId":"20080622214202.GA15311@atjola.homenet","threadId":"14083","inReplyTo":"20080622132105.GD22569@linux.vnet.ibm.com","subject":"Re: linux-x86-tip: pilot error?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-06-22T21:42:02Z","receivedAt":"2008-06-22T21:42:02Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.06.22 06:21:05 -0700, Paul E. McKenney wrote:\n> Trying \"git-checkout -b tip-core-rcu tip-core-rcu-2008-06-16_09.23_Mon\"\n> acts like it is doing something useful, but doesn't find the recent updates,\n> which I believe happened -before- June 16 2008.\n\nDo you mean these?\nrcu: make rcutorture more vicious: reinstate boot-time testing\nrcu: make rcutorture more vicious: add stutter feature\n\nI just fetched tip, and here, those two were committed on June 18 2008.\nThey're in tip/core/rcu, but not in the tag you mentioned.\n\nJFYI, I found those by using \"git log --grep=stutter --all\", and then\npassing the commit hash to \"git describe\":\n\n$ git describe --contains --all 31a72bce0bd6f3e0114009288bccbc96376eeeca\nremotes/tip/core/rcu\n\nBjörn\n"},{"id":"80649","messageId":"20080622222138.GG22569@linux.vnet.ibm.com","threadId":"14083","inReplyTo":"20080622214202.GA15311@atjola.homenet","subject":"Re: linux-x86-tip: pilot error?","fromName":"Paul E. McKenney","fromEmail":"paulmck@linux.vnet.ibm.com","sentAt":"2008-06-22T22:21:38Z","receivedAt":"2008-06-22T22:21:38Z","isPatch":false,"sender":{"key":"paulmck@linux.vnet.ibm.com","avatar":null},"body":"On Sun, Jun 22, 2008 at 11:42:02PM +0200, Björn Steinbrink wrote:\n> On 2008.06.22 06:21:05 -0700, Paul E. McKenney wrote:\n> > Trying \"git-checkout -b tip-core-rcu tip-core-rcu-2008-06-16_09.23_Mon\"\n> > acts like it is doing something useful, but doesn't find the recent updates,\n> > which I believe happened -before- June 16 2008.\n> \n> Do you mean these?\n> rcu: make rcutorture more vicious: reinstate boot-time testing\n> rcu: make rcutorture more vicious: add stutter feature\n\nIndeed those are the ones that I am looking for!\n\n> I just fetched tip, and here, those two were committed on June 18 2008.\n> They're in tip/core/rcu, but not in the tag you mentioned.\n> \n> JFYI, I found those by using \"git log --grep=stutter --all\", and then\n> passing the commit hash to \"git describe\":\n> \n> $ git describe --contains --all 31a72bce0bd6f3e0114009288bccbc96376eeeca\n> remotes/tip/core/rcu\n\nThank you -- that does find those commits for me as well. \n\n\t\t\t\t\t\t\tThanx, Paul\n"},{"id":"80680","messageId":"20080623071441.GA28887@elte.hu","threadId":"14083","inReplyTo":"20080622132105.GD22569@linux.vnet.ibm.com","subject":"Re: linux-x86-tip: pilot error?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-06-23T07:14:41Z","receivedAt":"2008-06-23T07:14:41Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Paul E. McKenney wrote:\n\n> Trying \"git-checkout -b tip-core-rcu \n> tip-core-rcu-2008-06-16_09.23_Mon\" acts like it is doing something \n> useful, but doesn't find the recent updates, which I believe happened \n> -before- June 16 2008.\n\nfinding the rcu topic branch in -tip can be done the following way:\n\n $ git-branch -a | grep rcu\n tip/core/rcu\n\nand doing a \"git-log tip/core/rcu..linus/master\" will show you the \ncommits that are in the tip/core/rcu topic branch.\n\nif you check out that branch for your own use, you should also do:\n\n $ git-merge linus/master\n\nTo bring it up to latest upstream. That merge, even if tip/core/rcu \nlooks \"old\" will always be conflict-free, due to scripting we do:\n\ntip-core-rcu-2008-06-16_09.23_Mon is not a snapshot of the rcu topic - \nit is \"technical\" tag of the upstream Linus -git tree against which the \nrcu topic is based.\n\nWe have to track the 'base' of every topic separately because otherwise \nwe'd pollute the topic branches with the frequent merges to Linus's \ntree. (occasionally we merge to Linus's tree several times a day, that \nwould lead to tons of merge commits that pollute the tree)\n\nSo instead we do \"on-demand virtual merges\": we have scripting which do \nthe following: in each iteration step they merge to latest Linus, check \nwhether there's any files touched by the merge that are changed by the \ntopic branch too - if yes then the merge is made permanent and the \"this \nis this topic's latest upstream\" tag is updated. If the merge was \nconflict-free, we roll back the merge.\n\nIs there a Git way of finding the common ancestor of a topic branch, \nwhen compared to upstream?\n\n\tIngo\n"},{"id":"80688","messageId":"20080623095732.GL22569@linux.vnet.ibm.com","threadId":"14083","inReplyTo":"20080623071441.GA28887@elte.hu","subject":"Re: linux-x86-tip: pilot error?","fromName":"Paul E. McKenney","fromEmail":"paulmck@linux.vnet.ibm.com","sentAt":"2008-06-23T09:57:32Z","receivedAt":"2008-06-23T09:57:32Z","isPatch":false,"sender":{"key":"paulmck@linux.vnet.ibm.com","avatar":null},"body":"On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:\n> \n> * Paul E. McKenney wrote:\n> \n> > Trying \"git-checkout -b tip-core-rcu \n> > tip-core-rcu-2008-06-16_09.23_Mon\" acts like it is doing something \n> > useful, but doesn't find the recent updates, which I believe happened \n> > -before- June 16 2008.\n> \n> finding the rcu topic branch in -tip can be done the following way:\n> \n> $ git-branch -a | grep rcu\n> tip/core/rcu\n\nAh!!! Good, that does show me this branch. I created a new branch\n\"paulmck-rcu-2008-06-23\" just out of paranoia.\n\n> and doing a \"git-log tip/core/rcu..linus/master\" will show you the \n> commits that are in the tip/core/rcu topic branch.\n> \n> if you check out that branch for your own use, you should also do:\n> \n> $ git-merge linus/master\n> \n> To bring it up to latest upstream.\n\nOK, that did pull in a number of changes. The gitk tool then shows my\n\"Merge commit 'linus/master' into paulmck-rcu-2008-06-23\" at the head\nof the display, with parents as follows:\n\nParent: 31a72bce0bd6f3e0114009288bccbc96376eeeca (rcu: make rcutorture more vicious: reinstate boot-time testing)\nParent: bec95aab8c056ab490fe7fa54da822938562443d (Merge branch 'release' of git://lm-sensors.org/kernel/mhoffman/hwmon-2.6)\n\nThis means that the RCU-related changes show up discontinuously in\nthe gitk display, but clicking on the left-most connector and selecting\n\"parent\" gets me to the rest of the tip/core/rcu branch, so should be OK,\nI guess. ;-)\n\nI then applied my two patches from yesterday (EDT timezone), just for\npractice.\n\nThese show up after the merge.\n\nBut now when I do \"git-log tip/core/rcu..linus/master\", I get one very\nlarge pile of patches. It apparently includes the stuff I merged from\nlinus/master. This is expected behavior, correct?\n\nSo, if I want to identify the RCU patches since some specific Linus\nrelease (for example, 2.6.26-rc7), I follow the RCU parents down until\nI find the desired release tag, then generate diffs from the ranges I\nfind, right?\n\nHmmm, actually, no, this bypasses the v2.6.26-rcN tags.\n\nOne approach is apparently to use gitk to create a view that includes\nthe patches touching the RCU-related files. The git-log command\nalso takes pathname arguments, so that allows me to get an approximation\nas well.\n\nI will have to look more at git-log and gitk -- probably I should be\npaying more attention to patches adding or deleting the strings\n\"RCU\" or \"rcu\" to the kernel. ;-)\n\nIs there some way to determine whether a give patch has a tagged\npatch (e.g., v2.6.26-rc7) as a child? It would be very cool to\nbe able to dump only those patches that are not part of v2.6.26-rc7,\nas this would allow me to automatically generate the list of\nRCU-related patches from linux-2.6-tip to test against this RC.\n\n> That merge, even if tip/core/rcu \n> looks \"old\" will always be conflict-free, due to scripting we do:\n> \n> tip-core-rcu-2008-06-16_09.23_Mon is not a snapshot of the rcu topic - \n> it is \"technical\" tag of the upstream Linus -git tree against which the \n> rcu topic is based.\n> \n> We have to track the 'base' of every topic separately because otherwise \n> we'd pollute the topic branches with the frequent merges to Linus's \n> tree. (occasionally we merge to Linus's tree several times a day, that \n> would lead to tons of merge commits that pollute the tree)\n> \n> So instead we do \"on-demand virtual merges\": we have scripting which do \n> the following: in each iteration step they merge to latest Linus, check \n> whether there's any files touched by the merge that are changed by the \n> topic branch too - if yes then the merge is made permanent and the \"this \n> is this topic's latest upstream\" tag is updated. If the merge was \n> conflict-free, we roll back the merge.\n\nSounds like also tracking patches/transformations as first-class objects\nwould be a good research project. ;-)\n\n\t\t\t\t\t\t\tThanx, Paul\n\n> Is there a Git way of finding the common ancestor of a topic branch, \n> when compared to upstream?\n> \n> \tIngo\n"},{"id":"80690","messageId":"20080623102424.GA28192@elte.hu","threadId":"14083","inReplyTo":"20080623095732.GL22569@linux.vnet.ibm.com","subject":"Re: linux-x86-tip: pilot error?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-06-23T10:24:24Z","receivedAt":"2008-06-23T10:24:24Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Paul E. McKenney wrote:\n\n> On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:\n> > \n> > * Paul E. McKenney wrote:\n> > \n> > > Trying \"git-checkout -b tip-core-rcu \n> > > tip-core-rcu-2008-06-16_09.23_Mon\" acts like it is doing something \n> > > useful, but doesn't find the recent updates, which I believe happened \n> > > -before- June 16 2008.\n> > \n> > finding the rcu topic branch in -tip can be done the following way:\n> > \n> > $ git-branch -a | grep rcu\n> > tip/core/rcu\n> \n> Ah!!! Good, that does show me this branch. I created a new branch\n> \"paulmck-rcu-2008-06-23\" just out of paranoia.\n\nthat's OK - having more branches never hurts.\n\nif, while juggling branches, you lose some commit somewhere it makes \nsense to check .git/logs/. [ Up until the point Git does a \ngarbage-collection run and zaps any orphaned commits ;-) ]\n\n> > if you check out that branch for your own use, you should also do:\n> > \n> > $ git-merge linus/master\n> > \n> > To bring it up to latest upstream.\n> \n> OK, that did pull in a number of changes. The gitk tool then shows my \n> \"Merge commit 'linus/master' into paulmck-rcu-2008-06-23\" at the head \n> of the display, with parents as follows:\n> \n> Parent: 31a72bce0bd6f3e0114009288bccbc96376eeeca (rcu: make rcutorture more vicious: reinstate boot-time testing)\n> Parent: bec95aab8c056ab490fe7fa54da822938562443d (Merge branch 'release' of git://lm-sensors.org/kernel/mhoffman/hwmon-2.6)\n> \n> This means that the RCU-related changes show up discontinuously in the \n> gitk display, but clicking on the left-most connector and selecting \n> \"parent\" gets me to the rest of the tip/core/rcu branch, so should be \n> OK, I guess. ;-)\n\ni have just talked to Thomas about it and we'll change our scripting so \nthat the tip/core/rcu branch will always be very recent and merged up to \nlatest -git.\n\nAs one of the goals of the tip/* structure is to distribute topics to \nothers (or as Linus has put it, Thomas and me needs to become more \nmanagerial about maintenance ;), there's real value in having the topics \nappear up-to-date when people try them out.\n\n( it's possible to do this without criss-cross merge commits - it just\n needs some more creative scripting in -tip. )\n\n> I then applied my two patches from yesterday (EDT timezone), just for \n> practice.\n> \n> These show up after the merge.\n> \n> But now when I do \"git-log tip/core/rcu..linus/master\", I get one very \n> large pile of patches. It apparently includes the stuff I merged from \n> linus/master. This is expected behavior, correct?\n\nThat would be expected behavior, yes. You can try a \"test-pull\" into \ncore/rcu:\n\n git-checkout -b test-rcu tip/core/rcu\n git-merge paulmck-rcu-2008-06-23 # replace with git-pull and an URI\n\n... and then look at how \"git-log test-rcu..linus/master\" looks like. It \nshould show all the changes of the RCU topic, your two new commits \nincluded.\n\n> So, if I want to identify the RCU patches since some specific Linus \n> release (for example, 2.6.26-rc7), I follow the RCU parents down until \n> I find the desired release tag, then generate diffs from the ranges I \n> find, right?\n> \n> Hmmm, actually, no, this bypasses the v2.6.26-rcN tags.\n> \n> One approach is apparently to use gitk to create a view that includes \n> the patches touching the RCU-related files. The git-log command also \n> takes pathname arguments, so that allows me to get an approximation as \n> well.\n> \n> I will have to look more at git-log and gitk -- probably I should be \n> paying more attention to patches adding or deleting the strings \"RCU\" \n> or \"rcu\" to the kernel. ;-)\n\nYou can use the filenames as a commit filter, for example:\n\n git-shortlog v2.6.25.. kernel/rcu* include/linux/rcu*\n\nWill give you a rather good view about what things changed in RCU land \nin v2.6.26 so far.\n\nTo see what is queued up in -tip for v2.6.27 that affect RCU, you can \ndo:\n\n git-shortlog linus/master..tip/master kernel/rcu* include/linux/rcu*\n\nThis will show tip/core/rcu changes. Not unsurprisingly this will show \nsomething quite similar to:\n\n git-shortlog linus/master..tip/core/rcu\n\n... as all RCU patches are supposed to be in that topic branch. [ But it \ndoes not hurt to double check me on that :-) ]\n\nThe widest search that doesnt involve the checking of around 100,000 \ncommits is the tip-log-line utility you can find in the tip/tip branch. \nVia that utility you can filter out all interesting RCU commits:\n\n tip-log-line kernel/rcu* include/linux/rcu*\n\nit will output a tidy list of branches, sha1's and subject lines.\n\n(you'll probably first need to run tip-create-local-branches.sh to \ncreate local branches out of all the tip topics.)\n\nfor example, to see RCU affecting changes not queued up in tip/core/rcu, \nyou can do:\n\n ~/tip> tip-log-line kernel/rcu* include/linux/rcu* | grep -v ' core/rcu:'\n # core/softirq: 962cf36: Remove argument from open_softirq which is always NULL\n # core/softirq: a60b33c: Merge branch 'linus' into core/softirq\n # cpus4096: 363ab6f: core: use performance variant for_each_cpu_mask_nr\n\n> Is there some way to determine whether a give patch has a tagged patch \n> (e.g., v2.6.26-rc7) as a child? It would be very cool to be able to \n> dump only those patches that are not part of v2.6.26-rc7, as this \n> would allow me to automatically generate the list of RCU-related \n> patches from linux-2.6-tip to test against this RC.\n\nif i understood you correctly, git-describe will do that for you \nnormally. If you have an sha1 you can do:\n\n $ git-describe 481c5346d0981940ee63037eb53e4e37b0735c10\n v2.6.26-rc7-25-g481c534\n\n\tIngo\n"},{"id":"80691","messageId":"20080623111144.GP22569@linux.vnet.ibm.com","threadId":"14083","inReplyTo":"20080623102424.GA28192@elte.hu","subject":"Re: linux-x86-tip: pilot error?","fromName":"Paul E. McKenney","fromEmail":"paulmck@linux.vnet.ibm.com","sentAt":"2008-06-23T11:11:44Z","receivedAt":"2008-06-23T11:11:44Z","isPatch":false,"sender":{"key":"paulmck@linux.vnet.ibm.com","avatar":null},"body":"On Mon, Jun 23, 2008 at 12:24:24PM +0200, Ingo Molnar wrote:\n> \n> * Paul E. McKenney wrote:\n> \n> > On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:\n> > > \n> > > * Paul E. McKenney wrote:\n> > > \n> > > > Trying \"git-checkout -b tip-core-rcu \n> > > > tip-core-rcu-2008-06-16_09.23_Mon\" acts like it is doing something \n> > > > useful, but doesn't find the recent updates, which I believe happened \n> > > > -before- June 16 2008.\n> > > \n> > > finding the rcu topic branch in -tip can be done the following way:\n> > > \n> > > $ git-branch -a | grep rcu\n> > > tip/core/rcu\n> > \n> > Ah!!! Good, that does show me this branch. I created a new branch\n> > \"paulmck-rcu-2008-06-23\" just out of paranoia.\n> \n> that's OK - having more branches never hurts.\n> \n> if, while juggling branches, you lose some commit somewhere it makes \n> sense to check .git/logs/. [ Up until the point Git does a \n> garbage-collection run and zaps any orphaned commits ;-) ]\n\nThank you -- I have had some things disappear on me in the past. ;-)\n\n> > > if you check out that branch for your own use, you should also do:\n> > > \n> > > $ git-merge linus/master\n> > > \n> > > To bring it up to latest upstream.\n> > \n> > OK, that did pull in a number of changes. The gitk tool then shows my \n> > \"Merge commit 'linus/master' into paulmck-rcu-2008-06-23\" at the head \n> > of the display, with parents as follows:\n> > \n> > Parent: 31a72bce0bd6f3e0114009288bccbc96376eeeca (rcu: make rcutorture more vicious: reinstate boot-time testing)\n> > Parent: bec95aab8c056ab490fe7fa54da822938562443d (Merge branch 'release' of git://lm-sensors.org/kernel/mhoffman/hwmon-2.6)\n> > \n> > This means that the RCU-related changes show up discontinuously in the \n> > gitk display, but clicking on the left-most connector and selecting \n> > \"parent\" gets me to the rest of the tip/core/rcu branch, so should be \n> > OK, I guess. ;-)\n> \n> i have just talked to Thomas about it and we'll change our scripting so \n> that the tip/core/rcu branch will always be very recent and merged up to \n> latest -git.\n> \n> As one of the goals of the tip/* structure is to distribute topics to \n> others (or as Linus has put it, Thomas and me needs to become more \n> managerial about maintenance ;), there's real value in having the topics \n> appear up-to-date when people try them out.\n\n;-)\n\n> ( it's possible to do this without criss-cross merge commits - it just\n> needs some more creative scripting in -tip. )\n\nI am keeping the hints in a README file on my machine -- thank you!!!\n\n> > I then applied my two patches from yesterday (EDT timezone), just for \n> > practice.\n> > \n> > These show up after the merge.\n> > \n> > But now when I do \"git-log tip/core/rcu..linus/master\", I get one very \n> > large pile of patches. It apparently includes the stuff I merged from \n> > linus/master. This is expected behavior, correct?\n> \n> That would be expected behavior, yes. You can try a \"test-pull\" into \n> core/rcu:\n> \n> git-checkout -b test-rcu tip/core/rcu\n> git-merge paulmck-rcu-2008-06-23 # replace with git-pull and an URI\n> \n> ... and then look at how \"git-log test-rcu..linus/master\" looks like. It \n> should show all the changes of the RCU topic, your two new commits \n> included.\n\nThe git-merge seemed to run normally, but the git-log command showed\nno output. Hmmm...\n\n> > So, if I want to identify the RCU patches since some specific Linus \n> > release (for example, 2.6.26-rc7), I follow the RCU parents down until \n> > I find the desired release tag, then generate diffs from the ranges I \n> > find, right?\n> > \n> > Hmmm, actually, no, this bypasses the v2.6.26-rcN tags.\n> > \n> > One approach is apparently to use gitk to create a view that includes \n> > the patches touching the RCU-related files. The git-log command also \n> > takes pathname arguments, so that allows me to get an approximation as \n> > well.\n> > \n> > I will have to look more at git-log and gitk -- probably I should be \n> > paying more attention to patches adding or deleting the strings \"RCU\" \n> > or \"rcu\" to the kernel. ;-)\n> \n> You can use the filenames as a commit filter, for example:\n> \n> git-shortlog v2.6.25.. kernel/rcu* include/linux/rcu*\n\nOK, this does seem to give a good list.\n\n> Will give you a rather good view about what things changed in RCU land \n> in v2.6.26 so far.\n> \n> To see what is queued up in -tip for v2.6.27 that affect RCU, you can \n> do:\n> \n> git-shortlog linus/master..tip/master kernel/rcu* include/linux/rcu*\n\nThis also looks good at first glance.\n\n> This will show tip/core/rcu changes. Not unsurprisingly this will show \n> something quite similar to:\n> \n> git-shortlog linus/master..tip/core/rcu\n> \n> ... as all RCU patches are supposed to be in that topic branch. [ But it \n> does not hurt to double check me on that :-) ]\n\nThis looks good at first glance.\n\n> The widest search that doesnt involve the checking of around 100,000 \n> commits is the tip-log-line utility you can find in the tip/tip branch. \n> Via that utility you can filter out all interesting RCU commits:\n> \n> tip-log-line kernel/rcu* include/linux/rcu*\n> \n> it will output a tidy list of branches, sha1's and subject lines.\n\nI will dig up the tip-log-line utility.\n\n> (you'll probably first need to run tip-create-local-branches.sh to \n> create local branches out of all the tip topics.)\n> \n> for example, to see RCU affecting changes not queued up in tip/core/rcu, \n> you can do:\n> \n> ~/tip> tip-log-line kernel/rcu* include/linux/rcu* | grep -v ' core/rcu:'\n> # core/softirq: 962cf36: Remove argument from open_softirq which is always NULL\n> # core/softirq: a60b33c: Merge branch 'linus' into core/softirq\n> # cpus4096: 363ab6f: core: use performance variant for_each_cpu_mask_nr\n> \n> > Is there some way to determine whether a give patch has a tagged patch \n> > (e.g., v2.6.26-rc7) as a child? It would be very cool to be able to \n> > dump only those patches that are not part of v2.6.26-rc7, as this \n> > would allow me to automatically generate the list of RCU-related \n> > patches from linux-2.6-tip to test against this RC.\n> \n> if i understood you correctly, git-describe will do that for you \n> normally. If you have an sha1 you can do:\n> \n> $ git-describe 481c5346d0981940ee63037eb53e4e37b0735c10\n> v2.6.26-rc7-25-g481c534\n\nSo this shows the last linus/master commit -not- containing the patch,\ncorrect? Ah, the most recent -tag-. So I have to be a bit careful\nabout creating tags if I want this to work for me. Fair enough!\n\n\t\t\t\t\t\tThanx, Paul\n"},{"id":"80692","messageId":"20080623112233.GB7485@elte.hu","threadId":"14083","inReplyTo":"20080623111144.GP22569@linux.vnet.ibm.com","subject":"Re: linux-x86-tip: pilot error?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-06-23T11:22:33Z","receivedAt":"2008-06-23T11:22:33Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Paul E. McKenney wrote:\n\n> > That would be expected behavior, yes. You can try a \"test-pull\" into \n> > core/rcu:\n> > \n> > git-checkout -b test-rcu tip/core/rcu\n> > git-merge paulmck-rcu-2008-06-23 # replace with git-pull and an URI\n> > \n> > ... and then look at how \"git-log test-rcu..linus/master\" looks like. It \n> > should show all the changes of the RCU topic, your two new commits \n> > included.\n> \n> The git-merge seemed to run normally, but the git-log command showed\n> no output. Hmmm...\n\nsorry, i accidentally reversed the arguments, that should have been:\n\n git-shortlog linus/master..test-rcu\n git-log linus/master..test-rcu\n\nthe way such things can be noticed is to replace git-log with git-diff:\n\n git-diff test-rcu..linus/master\n\nand if that does not come empty (and it didnt), it's an ordering \nproblem.\n\n> > $ git-describe 481c5346d0981940ee63037eb53e4e37b0735c10\n> > v2.6.26-rc7-25-g481c534\n> \n> So this shows the last linus/master commit -not- containing the patch, \n> correct? Ah, the most recent -tag-. So I have to be a bit careful \n> about creating tags if I want this to work for me. Fair enough!\n\nyou most definitely need to be careful about creating tags. Tags have \nextra security value (Linus signs them, etc.) and Git will not override \nan existing tag by default in any case. So you definitely dont want to \ncreate a tag that collides with any expected future upstream tag. (such \nas \"v2.6.26\" or \"2.6.26-rc8\")\n\ntags are mostly meant for release management - our use of tags to save \nthe \"merge base\" of topic branches in -tip can be considered mild abuse. \n\n( But we did not want to pullute the already crowded branch space with \n extra technical branches. -tip has 127 branches at this moment, 89 of \n which are topic branches - creating a base branch for each topic would \n add another 89 branches and bring it all up to 216 branches. )\n\n\tIngo\n"},{"id":"80709","messageId":"20080623151257.GC20902@sigill.intra.peff.net","threadId":"14083","inReplyTo":"20080623071441.GA28887@elte.hu","subject":"Re: linux-x86-tip: pilot error?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-23T15:12:58Z","receivedAt":"2008-06-23T15:12:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:\n\n> Is there a Git way of finding the common ancestor of a topic branch, \n> when compared to upstream?\n\nTry:\n\n git merge-base topic upstream\n\n-Peff\n"},{"id":"80712","messageId":"20080623153159.GC28394@elte.hu","threadId":"14083","inReplyTo":"20080623151257.GC20902@sigill.intra.peff.net","subject":"Re: linux-x86-tip: pilot error?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-06-23T15:31:59Z","receivedAt":"2008-06-23T15:31:59Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Jeff King wrote:\n\n> On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:\n> \n> > Is there a Git way of finding the common ancestor of a topic branch, \n> > when compared to upstream?\n> \n> Try:\n> \n> git merge-base topic upstream\n\nturns out we already use that as a fallback:\n\n if [ -z \"$TREF\" ]\n then\n echo \"No topic reference found. Using git-merge-base\"\n MBASE=`git-merge-base linus HEAD`\n TD=`get_date_for_tag`\n TB=`echo $B | sed \"s@/@-@\"`\n git-tag \"tip-\"$TB\"-\"$TD $MBASE\n TREF=\"tip-\"$TB\"-\"$TD\n [...]\n\ni guess we could use that unconditionally.\n\n\tIngo\n"},{"id":"80717","messageId":"20080623160532.GA10540@elte.hu","threadId":"14083","inReplyTo":"20080623151257.GC20902@sigill.intra.peff.net","subject":"Re: linux-x86-tip: pilot error?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-06-23T16:05:32Z","receivedAt":"2008-06-23T16:05:32Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Jeff King wrote:\n\n> On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:\n> \n> > Is there a Git way of finding the common ancestor of a topic branch, \n> > when compared to upstream?\n> \n> Try:\n> \n> git merge-base topic upstream\n\nsmall (and stupid) feature suggestion for git-merge-base.\n\ni was working on a topic branch when i wanted to figure out its base to \nlinus/master, and i typed:\n\n ~/tip> git-merge-base linus\n usage: git-merge-base [--all] \n\nit might make sense to implicitly use the current 'HEAD' as a second, \ndefault parameter to git-merge-base. (unless i'm missing some particular \ndetail about why that would be a bad idea)\n\n\tIngo\n"},{"id":"80720","messageId":"alpine.LNX.1.00.0806231208460.19665@iabervon.org","threadId":"14083","inReplyTo":"20080623112233.GB7485@elte.hu","subject":"Re: linux-x86-tip: pilot error?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-23T16:14:56Z","receivedAt":"2008-06-23T16:14:56Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 23 Jun 2008, Ingo Molnar wrote:\n\n> tags are mostly meant for release management - our use of tags to save \n> the \"merge base\" of topic branches in -tip can be considered mild abuse. \n> \n> ( But we did not want to pullute the already crowded branch space with \n> extra technical branches. -tip has 127 branches at this moment, 89 of \n> which are topic branches - creating a base branch for each topic would \n> add another 89 branches and bring it all up to 216 branches. )\n\nIf these are only internal details, and not something you expect other \npeople to use, you could get yourself a directory for refs that doesn't \nmean anything to the rest of git. If you use \"refs/bases/\", git \nshould (a) accept that as a name you can use for a commit; (b) preserve \nanything referenced by it; (c) copy it in a \"git clone --mirror\"; and \npretty much ignore it otherwise.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}