revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-21 04:48:39 +08:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='--ancestry-path'
|
|
|
|
|
|
|
|
# D---E-------F
|
|
|
|
# / \ \
|
|
|
|
# B---C---G---H---I---J
|
|
|
|
# / \
|
|
|
|
# A-------K---------------L--M
|
|
|
|
#
|
|
|
|
# D..M == E F G H I J K L M
|
|
|
|
# --ancestry-path D..M == E F H I J L M
|
2010-06-04 07:17:37 +08:00
|
|
|
#
|
|
|
|
# D..M -- M.t == M
|
|
|
|
# --ancestry-path D..M -- M.t == M
|
2013-05-13 23:00:46 +08:00
|
|
|
#
|
|
|
|
# F...I == F G H I
|
|
|
|
# --ancestry-path F...I == F H I
|
2013-05-16 23:32:28 +08:00
|
|
|
#
|
|
|
|
# G..M -- G.t == [nothing - was dropped in "-s ours" merge L]
|
2013-05-16 23:32:39 +08:00
|
|
|
# --ancestry-path G..M -- G.t == L
|
|
|
|
# --ancestry-path --simplify-merges G^..M -- G.t == G L
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-21 04:48:39 +08:00
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_merge () {
|
|
|
|
test_tick &&
|
|
|
|
git merge -s ours -m "$2" "$1" &&
|
|
|
|
git tag "$2"
|
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success setup '
|
|
|
|
test_commit A &&
|
|
|
|
test_commit B &&
|
|
|
|
test_commit C &&
|
|
|
|
test_commit D &&
|
|
|
|
test_commit E &&
|
|
|
|
test_commit F &&
|
|
|
|
git reset --hard C &&
|
|
|
|
test_commit G &&
|
|
|
|
test_merge E H &&
|
|
|
|
test_commit I &&
|
|
|
|
test_merge F J &&
|
|
|
|
git reset --hard A &&
|
|
|
|
test_commit K &&
|
|
|
|
test_merge J L &&
|
|
|
|
test_commit M
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'rev-list D..M' '
|
|
|
|
for c in E F G H I J K L M; do echo $c; done >expect &&
|
|
|
|
git rev-list --format=%s D..M |
|
|
|
|
sed -e "/^commit /d" |
|
|
|
|
sort >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'rev-list --ancestry-path D..M' '
|
|
|
|
for c in E F H I J L M; do echo $c; done >expect &&
|
|
|
|
git rev-list --ancestry-path --format=%s D..M |
|
|
|
|
sed -e "/^commit /d" |
|
|
|
|
sort >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2010-06-04 07:17:37 +08:00
|
|
|
test_expect_success 'rev-list D..M -- M.t' '
|
|
|
|
echo M >expect &&
|
|
|
|
git rev-list --format=%s D..M -- M.t |
|
|
|
|
sed -e "/^commit /d" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2013-05-13 23:00:46 +08:00
|
|
|
test_expect_success 'rev-list --ancestry-path D..M -- M.t' '
|
2010-06-04 07:17:37 +08:00
|
|
|
echo M >expect &&
|
|
|
|
git rev-list --ancestry-path --format=%s D..M -- M.t |
|
|
|
|
sed -e "/^commit /d" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2013-05-13 23:00:46 +08:00
|
|
|
test_expect_success 'rev-list F...I' '
|
|
|
|
for c in F G H I; do echo $c; done >expect &&
|
|
|
|
git rev-list --format=%s F...I |
|
|
|
|
sed -e "/^commit /d" |
|
|
|
|
sort >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2013-05-13 23:00:47 +08:00
|
|
|
test_expect_success 'rev-list --ancestry-path F...I' '
|
2013-05-13 23:00:46 +08:00
|
|
|
for c in F H I; do echo $c; done >expect &&
|
|
|
|
git rev-list --ancestry-path --format=%s F...I |
|
|
|
|
sed -e "/^commit /d" |
|
|
|
|
sort >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2013-05-16 23:32:28 +08:00
|
|
|
# G.t is dropped in an "-s ours" merge
|
|
|
|
test_expect_success 'rev-list G..M -- G.t' '
|
|
|
|
>expect &&
|
|
|
|
git rev-list --format=%s G..M -- G.t |
|
|
|
|
sed -e "/^commit /d" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
revision.c: Make --full-history consider more merges
History simplification previously always treated merges as TREESAME
if they were TREESAME to any parent.
While this was consistent with the default behaviour, this could be
extremely unhelpful when searching detailed history, and could not be
overridden. For example, if a merge had ignored a change, as if by "-s
ours", then:
git log -m -p --full-history -Schange file
would successfully locate "change"'s addition but would not locate the
merge that resolved against it.
Futher, simplify_merges could drop the actual parent that a commit
was TREESAME to, leaving it as a normal commit marked TREESAME that
isn't actually TREESAME to its remaining parent.
Now redefine a commit's TREESAME flag to be true only if a commit is
TREESAME to _all_ of its parents. This doesn't affect either the default
simplify_history behaviour (because partially TREESAME merges are turned
into normal commits), or full-history with parent rewriting (because all
merges are output). But it does affect other modes. The clearest
difference is that --full-history will show more merges - sufficient to
ensure that -m -p --full-history log searches can really explain every
change to the file, including those changes' ultimate fate in merges.
Also modify simplify_merges to recalculate TREESAME after removing
a parent. This is achieved by storing per-parent TREESAME flags on the
initial scan, so the combined flag can be easily recomputed.
This fixes some t6111 failures, but creates a couple of new ones -
we are now showing some merges that don't need to be shown.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16 23:32:34 +08:00
|
|
|
test_expect_success 'rev-list --ancestry-path G..M -- G.t' '
|
2013-05-16 23:32:39 +08:00
|
|
|
echo L >expect &&
|
2013-05-16 23:32:28 +08:00
|
|
|
git rev-list --ancestry-path --format=%s G..M -- G.t |
|
2013-05-16 23:32:39 +08:00
|
|
|
sed -e "/^commit /d" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'rev-list --ancestry-path --simplify-merges G^..M -- G.t' '
|
|
|
|
for c in G L; do echo $c; done >expect &&
|
|
|
|
git rev-list --ancestry-path --simplify-merges --format=%s G^..M -- G.t |
|
2013-05-16 23:32:28 +08:00
|
|
|
sed -e "/^commit /d" |
|
|
|
|
sort >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2011-08-26 00:49:13 +08:00
|
|
|
# b---bc
|
|
|
|
# / \ /
|
|
|
|
# a X
|
|
|
|
# \ / \
|
|
|
|
# c---cb
|
2011-09-15 16:34:31 +08:00
|
|
|
#
|
|
|
|
# All refnames prefixed with 'x' to avoid confusion with the tags
|
|
|
|
# generated by test_commit on case-insensitive systems.
|
2011-08-26 00:49:13 +08:00
|
|
|
test_expect_success 'setup criss-cross' '
|
|
|
|
mkdir criss-cross &&
|
|
|
|
(cd criss-cross &&
|
|
|
|
git init &&
|
|
|
|
test_commit A &&
|
2011-09-15 16:34:31 +08:00
|
|
|
git checkout -b xb master &&
|
2011-08-26 00:49:13 +08:00
|
|
|
test_commit B &&
|
2011-09-15 16:34:31 +08:00
|
|
|
git checkout -b xc master &&
|
2011-08-26 00:49:13 +08:00
|
|
|
test_commit C &&
|
2011-09-15 16:34:31 +08:00
|
|
|
git checkout -b xbc xb -- &&
|
|
|
|
git merge xc &&
|
|
|
|
git checkout -b xcb xc -- &&
|
|
|
|
git merge xb &&
|
2011-08-26 00:49:13 +08:00
|
|
|
git checkout master)
|
|
|
|
'
|
|
|
|
|
|
|
|
# no commits in bc descend from cb
|
|
|
|
test_expect_success 'criss-cross: rev-list --ancestry-path cb..bc' '
|
|
|
|
(cd criss-cross &&
|
2011-09-15 16:34:31 +08:00
|
|
|
git rev-list --ancestry-path xcb..xbc > actual &&
|
2011-08-26 00:49:13 +08:00
|
|
|
test -z "$(cat actual)")
|
|
|
|
'
|
|
|
|
|
|
|
|
# no commits in repository descend from cb
|
2011-08-26 08:51:50 +08:00
|
|
|
test_expect_success 'criss-cross: rev-list --ancestry-path --all ^cb' '
|
2011-08-26 00:49:13 +08:00
|
|
|
(cd criss-cross &&
|
2011-09-15 16:34:31 +08:00
|
|
|
git rev-list --ancestry-path --all ^xcb > actual &&
|
2011-08-26 00:49:13 +08:00
|
|
|
test -z "$(cat actual)")
|
|
|
|
'
|
|
|
|
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-21 04:48:39 +08:00
|
|
|
test_done
|