kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Kevin Bracey	4d826608e9	revision.c: discount side branches when computing TREESAME 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>	12 years ago
Kevin Bracey	d0af663e42	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>	12 years ago
Kevin Bracey	c72424b1b5	t6019: test file dropped in -s ours merge 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>	12 years ago
Kevin Bracey	a765499a08	revision.c: treat A...B merge bases as if manually specified 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>	12 years ago
Kevin Bracey	f659031c1c	t6019: demonstrate --ancestry-path A...B breakage Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Thomas Rast	c05b988a69	t6019: avoid refname collision on case-insensitive systems 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>	13 years ago
Junio C Hamano	c3502fa882	revision: do not include sibling history in --ancestry-path output 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>	13 years ago
Brad King	81f4953120	rev-list: Demonstrate breakage with --ancestry-path --all 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>	13 years ago
Johan Herland	cb7529e13b	revision: Turn off history simplification in --ancestry-path mode 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>	15 years ago
Junio C Hamano	ebdc94f3be	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>	15 years ago