On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote: > > * Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
