Re: linux-x86-tip: pilot error?

[Ingo Molnar <mingo@elte.hu>]

* 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.

( it's possible to do this without criss-cross merge commits - it just
  needs some more creative scripting in -tip. )

> 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

	Ingo