On May 31, 2008, at 3:33 PM, Junio C Hamano wrote:
Junio C Hamano <gitster@xxxxxxxxx> writes:
Kevin Ballard <kevin@xxxxxx> writes:
You're still talking about the parent-filter here. I think you're
quite confused.
Blush. I should go to bed.
Now after following the codepath, your original
diff --git a/Documentation/git-filter-branch.txt b/Documentation/
git-filter-branch.txt
index 506c37a..541bf23 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -113,8 +113,8 @@ OPTIONS
stdin. The commit id is expected on stdout.
+
As a special extension, the commit filter may emit multiple
-commit ids; in that case, ancestors of the original commit will
-have all of them as parents.
+commit ids; in that case, the rewritten children of the original
commit will
+have all of them as parents. You probably don't want to do this.
+
You can use the 'map' convenience function in this filter, and
other
convenience functions, too. For example, calling 'skip_commit
"$@"'
does make sense to me. Except for "You probably don't want to do
this."
part. It is just "the utility of this feature is unknown to us" ;-)
I dug the code with "git blame" and the basic logic has been the same
since its introduction to git with 6f6826c (Add git-filter-branch,
2007-06-03). The commit-filter itself appeared first in Cogito as
d690516
(cg-admin-rewritehist --commit-filter for omitting commits,
2006-03-26),
and the commit log message claims that it was primarily meant to
_omit_
unwanted commits from the history, but at the same time it
advertises the
multiple commits case as a "feature" without telling why somebody
wants to
do so.
Except for this gem, which may have been lost in our copy:
# ... Note that this handles merges properly! In case Darl
# committed a merge between P1 and P2, it will be propagated
properly
# and all children of the merge will become merge commits with
P1,P2
# as their parents instead of the merge commit.
IOW, to rewrite this history:
---A---C---D---E
/
B
to pretend C never happened, you would give A' and B' back when you
rewrite C, to end up with this history:
---A'--D'--E'
/
B'
I'd agree with "You probably don't want to do this", but perhaps it
needs
a bit of clarification as to _why_ you would not:
- If the history is being rewritten for the whole tree, this will
make D' an evil merge that contains difference between C to D.
- If the filtering of the history is done to ignore parts of the tree
that is touched between C and D (iow, history simplification would
leave trees C and D the same), you would want to simplify away D'
not
C'. IOW, you would want the resulting history to look like:
---A'--C'--E'
/
B'
and for that you do not need to use this "feature".
Yeah, this utility of omitting commits occurred to me last night after
I went to bed. It does seem pretty limited in use, but I guess someone
might want to do it. For example, if C resolved merge conflicts
incorrectly and D fixed it, and then later somebody said "why do I
have two commits when I should just have one?" and wanted to omit C
and leave D behind as the merge.
I'll submit a new patch later that has better wording and perhaps a
diagram or two.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@xxxxxx
http://www.tildesoft.com
--
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
