summaryrefslogtreecommitdiff
path: root/t/t6019-rev-list-ancestry-path.sh
AgeCommit message (Collapse)AuthorFilesLines
2013-05-16revision.c: discount side branches when computing TREESAMELibravatar Kevin Bracey1-2/+10
Use the BOTTOM flag to define relevance for pruning. Relevant commits are those that are !UNINTERESTING or BOTTOM, and this allows us to identify irrelevant side branches (UNINTERESTING && !BOTTOM). If a merge has relevant parents, and it is TREESAME to them, then do not let irrelevant parents cause the merge to be treated as !TREESAME. When considering simplification, don't always include all merges - merges with exactly one relevant parent can be simplified, if TREESAME according to the above rule. These two changes greatly increase simplification in limited, pruned revision lists. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16revision.c: Make --full-history consider more mergesLibravatar Kevin Bracey1-1/+1
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-16t6019: test file dropped in -s ours mergeLibravatar Kevin Bracey1-0/+19
In preparation for upcoming TREESAME work, check the result for G.t, which is dropped in "-s ours" merge L. The default rev-list is empty, as expected - it follows the first parent path where it never existed. Unfortunately, --ancestry-path is also empty. Merges H J and L are all TREESAME to 1 parent, so are treated as TREESAME and not shown. This is clearly undesirable in the case of merge L, which dropped our G.t by taking the non-ancestry-path version. Document this as a known failure, and expect "H J L", the 3 merges along the path that had to chose G.t versions. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16revision.c: treat A...B merge bases as if manually specifiedLibravatar Kevin Bracey1-1/+1
The documentation assures users that "A...B" is defined as "A B --not $(git merge-base --all A B)". This wasn't in fact quite true, because the calculated merge bases were not sent to add_rev_cmdline(). The main effect of this was that although git rev-list --ancestry-path A B --not $(git merge-base --all A B) worked, the simpler form git rev-list --ancestry-path A...B failed with a "no bottom commits" error. Other potential users of bottom commits could also be affected by this problem, if they examine revs->cmdline_info; I came across the issue in my proposed history traversal refinements series. So ensure that the calculated merge bases are sent to add_rev_cmdline(), flagged with new 'whence' enum value REV_CMD_MERGE_BASE. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-13t6019: demonstrate --ancestry-path A...B breakageLibravatar Kevin Bracey1-1/+20
Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-15t6019: avoid refname collision on case-insensitive systemsLibravatar Thomas Rast1-8/+11
The criss-cross tests kept failing for me because of collisions of 'a' with 'A' etc. Prefix the lowercase refnames with an extra letter to disambiguate. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-25revision: do not include sibling history in --ancestry-path outputLibravatar Junio C Hamano1-1/+1
If the commit specified as the bottom of the commit range has a direct parent that has another child commit that contributed to the resulting history, "rev-list --ancestry-path" was confused and listed that side history as well, due to the command line parser subtlety corrected by the previous commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-25rev-list: Demonstrate breakage with --ancestry-path --allLibravatar Brad King1-0/+35
The option added by commit ebdc94f3 (revision: --ancestry-path, 2010-04-20) does not work properly in combination with --all, at least in the case of a criss-cross merge: b---bc / \ / a X \ / \ c---cb There are no descendants of 'cb' in the history. The command git rev-list --ancestry-path cb..bc correctly reports no commits. However, the command git rev-list --ancestry-path --all ^cb reports 'bc'. Add a test case to t6019-rev-list-ancestry-path demonstrating this breakage. Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-06revision: Turn off history simplification in --ancestry-path modeLibravatar Johan Herland1-0/+17
When using --ancestry-path together with history simplification (typically triggered by path limiting), history simplification would get in the way of --ancestry-path by prematurely removing the parent links between commits on which the ancestry path calculations are made. This patch disables this history simplification when --ancestry-path is enabled. This is similar to what e.g. --full-history already does. The patch also includes a simple testcase verifying that --ancestry-path works together with path limiting. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-21revision: --ancestry-pathLibravatar Junio C Hamano1-0/+56
"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>