Re: linux-x86-tip: pilot error?

> 
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> 
> > On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:
> > > 
> > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > > 
> > > > Trying "git-checkout -b tip-core-rcu 
> > > > tip-core-rcu-2008-06-16_09.23_Mon" acts like it is doing something 
> > > > useful, but doesn't find the recent updates, which I believe happened 
> > > > -before- June 16 2008.
> > > 
> > > finding the rcu topic branch in -tip can be done the following way:
> > > 
> > >  $ git-branch -a | grep rcu
> > >    tip/core/rcu
> > 
> > Ah!!!  Good, that does show me this branch.  I created a new branch
> > "paulmck-rcu-2008-06-23" just out of paranoia.
> 
> that's OK - having more branches never hurts.
> 
> if, while juggling branches, you lose some commit somewhere it makes 
> sense to check .git/logs/. [ Up until the point Git does a 
> garbage-collection run and zaps any orphaned commits ;-) ]

> > > if you check out that branch for your own use, you should also do:
> > > 
> > >  $ git-merge linus/master
> > > 
> > > To bring it up to latest upstream.
> > 
> > OK, that did pull in a number of changes.  The gitk tool then shows my 
> > "Merge commit 'linus/master' into paulmck-rcu-2008-06-23" at the head 
> > of the display, with parents as follows:
> > 
> > Parent: 31a72bce0bd6f3e0114009288bccbc96376eeeca (rcu: make rcutorture more vicious: reinstate boot-time testing)
> > Parent: bec95aab8c056ab490fe7fa54da822938562443d (Merge branch 'release' of git://lm-sensors.org/kernel/mhoffman/hwmon-2.6)
> > 
> > This means that the RCU-related changes show up discontinuously in the 
> > gitk display, but clicking on the left-most connector and selecting 
> > "parent" gets me to the rest of the tip/core/rcu branch, so should be 
> > OK, I guess.  ;-)
> 
> i have just talked to Thomas about it and we'll change our scripting so 
> that the tip/core/rcu branch will always be very recent and merged up to 
> latest -git.
> 
> As one of the goals of the tip/* structure is to distribute topics to 
> others (or as Linus has put it, Thomas and me needs to become more 
> managerial about maintenance ;), there's real value in having the topics 
> appear up-to-date when people try them out.

> > I then applied my two patches from yesterday (EDT timezone), just for 
> > practice.
> > 
> > These show up after the merge.
> > 
> > But now when I do "git-log tip/core/rcu..linus/master", I get one very 
> > large pile of patches.  It apparently includes the stuff I merged from 
> > linus/master.  This is expected behavior, correct?
> 
> That would be expected behavior, yes. You can try a "test-pull" into 
> core/rcu:
> 
>   git-checkout -b test-rcu tip/core/rcu
>   git-merge paulmck-rcu-2008-06-23   # replace with git-pull and an URI
> 
> ... and then look at how "git-log test-rcu..linus/master" looks like. It 
> should show all the changes of the RCU topic, your two new commits 
> included.

> > So, if I want to identify the RCU patches since some specific Linus 
> > release (for example, 2.6.26-rc7), I follow the RCU parents down until 
> > I find the desired release tag, then generate diffs from the ranges I 
> > find, right?
> > 
> > Hmmm, actually, no, this bypasses the v2.6.26-rcN tags.
> > 
> > One approach is apparently to use gitk to create a view that includes 
> > the patches touching the RCU-related files.  The git-log command also 
> > takes pathname arguments, so that allows me to get an approximation as 
> > well.
> > 
> > I will have to look more at git-log and gitk -- probably I should be 
> > paying more attention to patches adding or deleting the strings "RCU" 
> > or "rcu" to the kernel.  ;-)
> 
> You can use the filenames as a commit filter, for example:
> 
>    git-shortlog v2.6.25.. kernel/rcu* include/linux/rcu*

> Will give you a rather good view about what things changed in RCU land 
> in v2.6.26 so far.
> 
> To see what is queued up in -tip for v2.6.27 that affect RCU, you can 
> do:
> 
>    git-shortlog linus/master..tip/master kernel/rcu* include/linux/rcu*

> This will show tip/core/rcu changes. Not unsurprisingly this will show 
> something quite similar to:
> 
>    git-shortlog linus/master..tip/core/rcu
> 
> ... as all RCU patches are supposed to be in that topic branch. [ But it 
> does not hurt to double check me on that :-) ]

> The widest search that doesnt involve the checking of around 100,000 
> commits is the tip-log-line utility you can find in the tip/tip branch. 
> Via that utility you can filter out all interesting RCU commits:
> 
>    tip-log-line kernel/rcu* include/linux/rcu*
> 
> it will output a tidy list of branches, sha1's and subject lines.

> (you'll probably first need to run tip-create-local-branches.sh to 
> create local branches out of all the tip topics.)
> 
> for example, to see RCU affecting changes not queued up in tip/core/rcu, 
> you can do:
> 
>  ~/tip> tip-log-line kernel/rcu* include/linux/rcu* | grep -v ' core/rcu:'
>  # core/softirq: 962cf36: Remove argument from open_softirq which is always NULL
>  # core/softirq: a60b33c: Merge branch 'linus' into core/softirq
>  # cpus4096: 363ab6f: core: use performance variant for_each_cpu_mask_nr
> 
> > Is there some way to determine whether a give patch has a tagged patch 
> > (e.g., v2.6.26-rc7) as a child?  It would be very cool to be able to 
> > dump only those patches that are not part of v2.6.26-rc7, as this 
> > would allow me to automatically generate the list of RCU-related 
> > patches from linux-2.6-tip to test against this RC.
> 
> if i understood you correctly, git-describe will do that for you 
> normally. If you have an sha1 you can do:
> 
>  $ git-describe 481c5346d0981940ee63037eb53e4e37b0735c10
>  v2.6.26-rc7-25-g481c534