I 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-p4
This 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 handling
The 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),
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html