Re: linux-x86-tip: pilot error?

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

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.

> and doing a "git-log tip/core/rcu..linus/master" will show you the 
> commits that are in the tip/core/rcu topic branch.
> 
> 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 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?

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.  ;-)

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.

>                                    That merge, even if tip/core/rcu 
> looks "old" will always be conflict-free, due to scripting we do:
> 
> tip-core-rcu-2008-06-16_09.23_Mon is not a snapshot of the rcu topic - 
> it is "technical" tag of the upstream Linus -git tree against which the 
> rcu topic is based.
> 
> We have to track the 'base' of every topic separately because otherwise 
> we'd pollute the topic branches with the frequent merges to Linus's 
> tree. (occasionally we merge to Linus's tree several times a day, that 
> would lead to tons of merge commits that pollute the tree)
> 
> So instead we do "on-demand virtual merges": we have scripting which do 
> the following: in each iteration step they merge to latest Linus, check 
> whether there's any files touched by the merge that are changed by the 
> topic branch too - if yes then the merge is made permanent and the "this 
> is this topic's latest upstream" tag is updated. If the merge was 
> conflict-free, we roll back the merge.

Sounds like also tracking patches/transformations as first-class objects
would be a good research project.  ;-)

							Thanx, Paul

> Is there a Git way of finding the common ancestor of a topic branch, 
> when compared to upstream?
> 
> 	Ingo