linux-x86-tip: pilot error?

linux-x86-tip: pilot error?

[Paul E. McKenney]

Hello, Ingo,

I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:

  544  mkdir linux-2.6-tip
  545  cd linux-2.6-tip
  546  git-init-db
  547  git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  548  git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
  549  git-remote update
  550  git-checkout tip-core-rcu-2008-06-16_09.23_Mon

The "git-checkout" command complained as follows:

	warning: You appear to be on a branch yet to be born.
	warning: Forcing checkout of tip-core-rcu-2008-06-16_09.23_Mon.
	Checking 24254 files out...
	 100% (24254/24254) done
	fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
	Use '--' to separate paths from revisions
	Cannot detach HEAD

In addition, the kernel/rcutorture.c file does not have the "stutter"
changes in it after doing this checkout.

Did I mess something up?  Am I working with a too-old version of git
(git version 1.5.2.5)?  Or has git simply taken a deep and personal
disliking to me?  ;-)

My next step will be to try a more recent version of git.  In parallel,
I will just re-do the patch on top of my patch stack.

							Thanx, Paul

PS.  I am assuming that the repeated messages from git-update of
     the following form are expected behavior when there are tags:

     * 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
       commit: d40ace0

Re: linux-x86-tip: pilot error?

[Mikael Magnusson]

2008/6/22 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> Hello, Ingo,
>
> I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:
>
>  544  mkdir linux-2.6-tip
>  545  cd linux-2.6-tip
>  546  git-init-db
>  547  git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>  548  git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
>  549  git-remote update
>  550  git-checkout tip-core-rcu-2008-06-16_09.23_Mon

When checking out remote branches, you have to specify the remote:
git checkout tip/tip-blabla
(it'll warn about detaching HEAD, this is normal).

-- 
Mikael Magnusson

Re: linux-x86-tip: pilot error?

[Paul E. McKenney]

On Sun, Jun 22, 2008 at 02:48:35PM +0200, Mikael Magnusson wrote:
> 2008/6/22 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> > Hello, Ingo,
> >
> > I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:
> >
> >  544  mkdir linux-2.6-tip
> >  545  cd linux-2.6-tip
> >  546  git-init-db
> >  547  git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >  548  git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
> >  549  git-remote update
> >  550  git-checkout tip-core-rcu-2008-06-16_09.23_Mon
> 
> When checking out remote branches, you have to specify the remote:
> git checkout tip/tip-blabla
> (it'll warn about detaching HEAD, this is normal).

Thank you, Mikael!

But when I try "git-checkout tip/tip-core-rcu-2008-06-16_09.23_Mon",
it says:

	error: pathspec 'tip/tip-core-rcu-2008-06-16_09.23_Mon' did not match any file(s) known to git.
	Did you forget to 'git add'?

Trying "git-checkout tip/tip-core-rcu" gets me:

	error: pathspec 'tip/tip-core-rcu' did not match any file(s) known to git.
	Did you forget to 'git add'?

Trying "git-checkout -b tip-core-rcu tip/tip-core-rcu" gets me:

	git checkout: updating paths is incompatible with switching branches/forcing
	Did you intend to checkout 'tip/tip-core-rcu' which can not be resolved as commit?

Trying "git-checkout -b tip-core-rcu tip/tip-core-rcu-2008-06-16_09.23_Mon"
gets me:

	git checkout: updating paths is incompatible with switching branches/forcing
	Did you intend to checkout 'tip/tip-core-rcu-2008-06-16_09.23_Mon' which can not be resolved as commit?

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.

Help???

							Thanx, Paul

Re: linux-x86-tip: pilot error?

[Mikael Magnusson]

2008/6/22 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> On Sun, Jun 22, 2008 at 02:48:35PM +0200, Mikael Magnusson wrote:
>> 2008/6/22 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
>> > Hello, Ingo,
>> >
>> > I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:
>> >
>> >  544  mkdir linux-2.6-tip
>> >  545  cd linux-2.6-tip
>> >  546  git-init-db
>> >  547  git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> >  548  git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
>> >  549  git-remote update
>> >  550  git-checkout tip-core-rcu-2008-06-16_09.23_Mon
>>
>> When checking out remote branches, you have to specify the remote:
>> git checkout tip/tip-blabla
>> (it'll warn about detaching HEAD, this is normal).
>
> Thank you, Mikael!
>
> But when I try "git-checkout tip/tip-core-rcu-2008-06-16_09.23_Mon",
> it says:
>
>        error: pathspec 'tip/tip-core-rcu-2008-06-16_09.23_Mon' did not match any file(s) known to git.
>        Did you forget to 'git add'?
>
> Trying "git-checkout tip/tip-core-rcu" gets me:
>
>        error: pathspec 'tip/tip-core-rcu' did not match any file(s) known to git.
>        Did you forget to 'git add'?
>
> Trying "git-checkout -b tip-core-rcu tip/tip-core-rcu" gets me:
>
>        git checkout: updating paths is incompatible with switching branches/forcing
>        Did you intend to checkout 'tip/tip-core-rcu' which can not be resolved as commit?
>
> Trying "git-checkout -b tip-core-rcu tip/tip-core-rcu-2008-06-16_09.23_Mon"
> gets me:
>
>        git checkout: updating paths is incompatible with switching branches/forcing
>        Did you intend to checkout 'tip/tip-core-rcu-2008-06-16_09.23_Mon' which can not be resolved as commit?
>
> 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.
>
> Help???

Oh, i didn't realize you were trying to check out a tag... In that case
the commands you gave were correct. I could successfully run your commands
here (though i have no idea if the file you talk about is up to date or not).

It's probably worth trying a newer version of git, could be a bug I guess.
Given the error message you could also try first checking out a branch, and
then the tag. ie git checkout -b master linus/master; git checkout tip-foo
It could also be that the tag just doesn't point to the commit you expect..

-- 
Mikael Magnusson

Re: linux-x86-tip: pilot error?

[Björn Steinbrink]

On 2008.06.22 06:21:05 -0700, Paul E. McKenney 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.

Do you mean these?
rcu: make rcutorture more vicious: reinstate boot-time testing
rcu: make rcutorture more vicious: add stutter feature

I just fetched tip, and here, those two were committed on June 18 2008.
They're in tip/core/rcu, but not in the tag you mentioned.

JFYI, I found those by using "git log --grep=stutter --all", and then
passing the commit hash to "git describe":

$ git describe --contains --all 31a72bce0bd6f3e0114009288bccbc96376eeeca
remotes/tip/core/rcu

Björn

Re: linux-x86-tip: pilot error?

[Paul E. McKenney]

On Sun, Jun 22, 2008 at 11:42:02PM +0200, Björn Steinbrink wrote:
> On 2008.06.22 06:21:05 -0700, Paul E. McKenney 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.
> 
> Do you mean these?
> rcu: make rcutorture more vicious: reinstate boot-time testing
> rcu: make rcutorture more vicious: add stutter feature

Indeed those are the ones that I am looking for!

> I just fetched tip, and here, those two were committed on June 18 2008.
> They're in tip/core/rcu, but not in the tag you mentioned.
> 
> JFYI, I found those by using "git log --grep=stutter --all", and then
> passing the commit hash to "git describe":
> 
> $ git describe --contains --all 31a72bce0bd6f3e0114009288bccbc96376eeeca
> remotes/tip/core/rcu

Thank you -- that does find those commits for me as well.  <scratches
head>

							Thanx, Paul

Re: linux-x86-tip: pilot error?

[Ingo Molnar]

* 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

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

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

	Ingo

Re: linux-x86-tip: pilot error?

[Paul E. McKenney]

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

Re: linux-x86-tip: pilot error?

[Ingo Molnar]

* 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

Re: linux-x86-tip: pilot error?

[Paul E. McKenney]

On Mon, Jun 23, 2008 at 12:24:24PM +0200, Ingo Molnar wrote:
> 
> * 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 ;-) ]

Thank you -- I have had some things disappear on me in the past.  ;-)

> > > 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 am keeping the hints in a README file on my machine -- thank you!!!

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

The git-merge seemed to run normally, but the git-log command showed
no output.  Hmmm...

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

OK, this does seem to give a good list.

> 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 also looks good at first glance.

> 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 :-) ]

This looks good at first glance.

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

I will dig up the tip-log-line utility.

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

So this shows the last linus/master commit -not- containing the patch,
correct?  Ah, the most recent -tag-.  So I have to be a bit careful
about creating tags if I want this to work for me.  Fair enough!

						Thanx, Paul

Re: linux-x86-tip: pilot error?

[Ingo Molnar]

* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> > 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.
> 
> The git-merge seemed to run normally, but the git-log command showed
> no output.  Hmmm...

sorry, i accidentally reversed the arguments, that should have been:

  git-shortlog linus/master..test-rcu
  git-log linus/master..test-rcu

the way such things can be noticed is to replace git-log with git-diff:

   git-diff test-rcu..linus/master

and if that does not come empty (and it didnt), it's an ordering 
problem.

> >  $ git-describe 481c5346d0981940ee63037eb53e4e37b0735c10
> >  v2.6.26-rc7-25-g481c534
> 
> So this shows the last linus/master commit -not- containing the patch, 
> correct?  Ah, the most recent -tag-.  So I have to be a bit careful 
> about creating tags if I want this to work for me.  Fair enough!

you most definitely need to be careful about creating tags. Tags have 
extra security value (Linus signs them, etc.) and Git will not override 
an existing tag by default in any case. So you definitely dont want to 
create a tag that collides with any expected future upstream tag. (such 
as "v2.6.26" or "2.6.26-rc8")

tags are mostly meant for release management - our use of tags to save 
the "merge base" of topic branches in -tip can be considered mild abuse. 

( But we did not want to pullute the already crowded branch space with 
  extra technical branches. -tip has 127 branches at this moment, 89 of 
  which are topic branches - creating a base branch for each topic would 
  add another 89 branches and bring it all up to 216 branches. )

	Ingo

Re: linux-x86-tip: pilot error?

[Jeff King]

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

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

Try:

  git merge-base topic upstream

-Peff

Re: linux-x86-tip: pilot error?

[Ingo Molnar]

* Jeff King <peff@peff.net> wrote:

> On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:
> 
> > Is there a Git way of finding the common ancestor of a topic branch, 
> > when compared to upstream?
> 
> Try:
> 
>   git merge-base topic upstream

turns out we already use that as a fallback:

    if [ -z "$TREF" ]
    then
        echo "No topic reference found. Using git-merge-base"
        MBASE=`git-merge-base linus HEAD`
        TD=`get_date_for_tag`
        TB=`echo $B | sed "s@/@-@"`
        git-tag "tip-"$TB"-"$TD $MBASE
        TREF="tip-"$TB"-"$TD
    [...]

i guess we could use that unconditionally.

	Ingo

Re: linux-x86-tip: pilot error?

[Ingo Molnar]

* Jeff King <peff@peff.net> wrote:

> On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:
> 
> > Is there a Git way of finding the common ancestor of a topic branch, 
> > when compared to upstream?
> 
> Try:
> 
>   git merge-base topic upstream

small (and stupid) feature suggestion for git-merge-base.

i was working on a topic branch when i wanted to figure out its base to 
linus/master, and i typed:

  ~/tip> git-merge-base linus
  usage: git-merge-base [--all] <commit-id> <commit-id>

it might make sense to implicitly use the current 'HEAD' as a second, 
default parameter to git-merge-base. (unless i'm missing some particular 
detail about why that would be a bad idea)

	Ingo

Re: linux-x86-tip: pilot error?

[Daniel Barkalow]

On Mon, 23 Jun 2008, Ingo Molnar wrote:

> tags are mostly meant for release management - our use of tags to save 
> the "merge base" of topic branches in -tip can be considered mild abuse. 
> 
> ( But we did not want to pullute the already crowded branch space with 
>   extra technical branches. -tip has 127 branches at this moment, 89 of 
>   which are topic branches - creating a base branch for each topic would 
>   add another 89 branches and bring it all up to 216 branches. )

If these are only internal details, and not something you expect other 
people to use, you could get yourself a directory for refs that doesn't 
mean anything to the rest of git. If you use "refs/bases/<something>", git 
should (a) accept that as a name you can use for a commit; (b) preserve 
anything referenced by it; (c) copy it in a "git clone --mirror"; and 
pretty much ignore it otherwise.

	-Daniel
*This .sig left intentionally blank*