Junio C HamanoI often find myself frustrated when I receive an update to a part of the project and want to find the latest commit that merges the topic branch that touched the same area.
For example, I wanted to find the latest merge of any git-p4 related topic so that I can fork a new topic branch to keep Luke's updates posted today.
Without pathspec, "git log --first-parent" traverses the first-parent chain just fine, and "-m --stat" shows the list of paths touched by the merge, so we _could_ ask the question this way:
$ git log --first-parent --oneline -m --stat master |
sed -e '/^ contrib\/fast-import\/git-p4 /q' | tail
The above finds that 8cbfc11 (Merge branch 'pw/p4-view-updates',
2012-01-06) was such a commit.But a more natural way to spell it does not work as expected:
$ git log --first-parent --oneline -m --stat -1 master -- \
contrib/fast-import/git-p4This finds ecb7cf9 (git-p4: rewrite view handling, 2012-01-02), which is a part of the merged topic branch and is _not_ on the first-parent path from the 'master':
$ git show-branch 8cbfc11 ecb7cf9
! [8cbfc11] Merge branch 'pw/p4-view-updates'
! [ecb7cf9] git-p4: rewrite view handling
--
- [8cbfc11] Merge branch 'pw/p4-view-updates'
+ [8cbfc11^2] git-p4: view spec documentation
++ [ecb7cf9] git-p4: rewrite view handlingThe problem happens when the merge simplification logic kicks in when the traversal inspects the merge 8cbfc11. In this case, the history leading to the tip of 'master' did not touch git-p4 since 'pw/p4-view-updates' topic forked from it, and the result of the merge is simply a copy from the tip of the topic branch in the view limited by the given pathspec. The merge simplification logic discards the first-parent of the merge and pretends as if the sole parent of the merge is its second parent, i.e. the tip of the topic. The history traversal veers off to the side branch, possibly skipping a large swath of the mainline history if the topic forked from it long in the past, but that only happens when the mainline did not touch the paths in the limited view since the side topic forked, so it is not losing information---but it still is wrong to show the commits on the side topic when we are explicitly asked to show the first-parent chain.
Here is an attempt to fix this issue, by not allowing us to compare the merge result with anything but the first parent when --first-parent is in effect, to avoid the history traversal veering off to the side branch.
As this touches deep innards of a scary hairball that is the revision traversal machinery, I am obviously not considering it as a 1.7.9 material, but I think we would want to fix it at some point, hopefully soon.
With this patch, the "more natural way" finds the merge commit I am looking for.
Comments?
--- revision.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c index 064e351..9e4596d 100644 --- a/revision.c +++ b/revision.c @@ -416,7 +416,7 @@ static int rev_same_tree_as_empty(struct rev_info *revs, struct commit *commit) static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit) { struct commit_list **pp, *parent; - int tree_changed = 0, tree_same = 0; + int tree_changed = 0, tree_same = 0, nth_parent = 0; /* * If we don't do pruning, everything is interesting @@ -444,6 +444,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit) while ((parent = *pp) != NULL) { struct commit *p = parent->item; + if (revs->first_parent_only && nth_parent++) + break; if (parse_commit(p) < 0) die("cannot simplify commit %s (because of %s)", sha1_to_hex(commit->object.sha1),
