On Mon, Apr 21, 2014 at 05:38:34PM -0700, Luis R. Rodriguez wrote:
> [0] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.5| grep
> ^commit | wc -l
> 24878
> [1] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.4| grep
> ^commit | wc -l
> 13106
> [2] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.3| grep
> ^commit | wc -l
> 1360

From gitrevisions(7), r1..r2 is “commits that are reachable from r2
excluding those that are reachable from r1”.  Using Peff's example:

On Thu, Apr 17, 2014 at 06:16:20PM -0400, Jeff King wrote:
>  ---A---B---C-----D---E---F (maint, v3.4)
>      \   \       /
>       \   ---G-----H---I (master, v4.0)
>        \       /  /
>         ------J---
> The fix is J, and it got merged up to maint at D, and to master at H.
> v4.0 does not contain v3.4. What's the best description of J?

J..v3.4 is going to include B, C, D, E and F.  However, the “distance”
used by ‘git describe’ uses the shortest path between the commits
(J-D-E-F), which doesn't care about development between A and D.

> The results for command [2] above however a bit surprising, I'd take a
> look but I should go back to look at other stuff, figured I'd at least
> bring it up now as it seems relevant.

Here's a simplified graph with d1-* tags for the v3.5-rc1~120^3~76^2
description and d2-* tags for the v3.4~479^2~9^2 description [1]:

  * f8f5701 (tag: v3.5-rc1) Linux 3.5-rc1
  * 912afc3 (tag: d1-F) Merge tag 'dm-3.5-changes-1' of 
  *   56edab3 (tag: d1-E) Merge branches 'perf-urgent-for-linus' and 
'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
  | * ab0cce5 (tag: d1-D) Revert "sched, perf: Use a single callback into the 
  | * 26252ea (tag: d1-C-1, tag: d1-C) perf evlist: Show event attribute details
  | *   a385ec4 (tag: d1-C-64) Merge tag 'v3.4-rc2' into perf/core
  | |\
  | * \ 659c36f (tag: d1-C-65) Merge tag 'perf-core-for-mingo' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
  | |\ \
  | | * | 5a7ed29 (tag: d1-C-65-2) perf record: Use sw counter only if hw pmu 
is not detected
  * | |/  76e10d1 (tag: v3.4) Linux 3.4
  | |/|  
  |/| |  
  * |/ dd775ae (tag: v3.4-rc1) Linux 3.4-rc1
  * |  c5bc437 Merge tag 'perf-core-for-mingo' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
  | * 9521d83 (tag: d1-C-66) Merge tag 'perf-core-for-mingo' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
  * |   9c2b957 (tag: d2-E) Merge branch 'perf-core-for-linus' of 
  |\ \  
  | |/  
  | * bea95c1 (tag: d2-D, tag: d1-C-67) Merge branch 'perf/hw-branch-sampling' 
into perf/core
  | * f9b4eeb (tag: d2-C, tag: d1-C-68) perf/x86: Prettify pmu config literals
  | * a706d4f (tag: d2-B, tag: d1-C-76, tag: d1-B) Merge branch 
'perf/jump-labels' into perf/core
  | * c5905af (tag: A) static keys: Introduce 'struct static_key', 
static_key_true()/false() and static_key_slow_[inc|dec]()
  * | c16fa4f (tag: v3.3) Linux 3.3
  * dcd6c92 (tag: v3.3-rc1) Linux 3.3-rc1

This shows the v3.4-rc1 bypass from 9521d83 (d1-C-66) to 659c36f
(d1-C-65) which sets up the v3.5-rc1~120^3~76 description.  It also
shows the c5905afb..v3.3 commits on the branch from c5905af's fork
(between v3.3-rc1 and v3.3) and v3.3.


[1]: The simplified graph is from:

  $ git tag A c5905afb
  $ git tag d1-B v3.5-rc1~120^3~76
  $ git tag d1-C v3.5-rc1~120^3~1
  $ git tag d1-D v3.5-rc1~120^3
  $ git tag d1-E v3.5-rc1~120
  $ git tag d1-F v3.5-rc1~1
  $ for x in $(seq 76); do git tag d1-C-$x v3.5-rc1~120^3~$x; done
  $ git tag d1-C-65-2 d1-C-65^2
  $ git tag d2-B v3.4~479^2~9
  $ git tag d2-C v3.4~479^2~1
  $ git tag d2-D v3.4~479^2
  $ git tag d2-E v3.4~479
  $ git tag -d sound-fixes sound-3.4 v3.3-rc{2,3,4,5,6,7} v3.4-rc{2,3,4,5,6,7}
  $ git log --graph --topo-order --oneline --decorate --simplify-by-decoration 
  …simplified graph…
  $ git tag -d A d1-{B,C,D,E,F} d2-{B,C,D,E} d1-C-65-2 
  $ for x in $(seq 76); do git tag -d d1-C-$x; done

With some additional tweaks to cull the d1-C-* bits we don't care
about and clear up the 659c36f (d1-C-65) merge.

This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to