Re: linux-x86-tip: pilot error?

From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Jun 23, 2008, 09:57 UTC
Message-ID: <20080623095732.GL22569@linux.vnet.ibm.com>
In-Reply-To: <20080623071441.GA28887@elte.hu>

On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:

Show 12 quoted lines

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

Show 8 quoted lines

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

Show 18 quoted lines

>                                    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