Re: [PATCH] Documentation/git-filter-branch.txt: Fix description of --commit-filter

> Kevin Ballard <kevin@sb.org> writes:
>
>>> But I am also confused by the new description:
>>>
>>>       In that history, we will make sure that rewritten D (original
>>>       commit being C) have A as parent.  IOW, we will have
>>>
>>>               --A'--C'  D'
>>>                        /
>>>                       A
>>>
>>> which is not what happens.  What it does is that the commits in the
>>> output
>>> from the filter (i.e. A) are first mapped to the corresponding
>>> commits in
>>> the rewritten history (i.e. A'), and they will be used as the
>>> parents of
>>> the rewritten commit, to form this history:
>>>
>>>               --A'--C'
>>>
>>> isn't it?
>>
>> So basically, you think it's missing the fact that the emitted id is
>> mapped to rewritten commits? From reading the git-filter-branch code,
>> I don't think that's correct. When each commit is created, its
>> original parents get mapped to new values, but the results of the
>> commit-filter are dumped straight into the map.
>
> Ah, I misread this part of the code:
>
> 	parentstr=
> 	for parent in $parents; do
> 		for reparent in $(map "$parent"); do
> 			parentstr="$parentstr -p $reparent"
> 		done
> 	done
> 	if [ "$filter_parent" ]; then
> 		parentstr="$(echo "$parentstr" | eval "$filter_parent")" ||
> 				die "parent filter failed: $filter_parent"
> 	fi
>
> You get the commit object names from the new history, and you are  
> supposed
> to give back names from the new history from the filter.
>
> So "the rewritten commit will have the output from parent-filter as  
> its
> parents" is what happens, right?
>
> IOW, in the history in the previous message, when rewriting C (to  
> create
> C'), the filter will get A' and B' (i.e. from the new history), and  
> can
> choose to return A', and that is recorded when creating C'.  "the
> rewritten children of the commit" in your:
>
>    +commit ids; in that case, the rewritten children of the original
>    +commit will have all of them as parents.
>
> sounded as if you are talking about D' not C', and that was what I was
> confused about.

>> To give an example, let's examine your tree. A will be processed
>> first, and A' gets put into the map for A. B gets processed next (or
>> maybe before A, but that's irrelevant) and B' gets put into the map
>> for B. C gets processed, and it emits A, so A goes into the map for  
>> C.
>
> Hmm?  I meant C is rewritten to become C' but when it does so filter  
> can
> remove B from its parent set (iow, the filter is told that unless it
> intervenes C' will have A' and B' as its parents, but the filter can
> choose to return only A').  So I do not quite get "it emits A"  
> part.  Do
> you mean "the filter outputs A'"?  Also do you mean by "map" the  
> mapping
> from <A, B, C> to <A', B', C'> commit namespace?  If so, even when the
> filter "emits A'", I do not think it "goes into the map for C".   
> When the
> filter "emits A'", it is used as _the_ single parent to create C',  
> and it
> is C' that "goes into the map for C".  Am I still confused?
>
> Now, I admit that I did not look at the implementation of the "map"  
> in the
> code quoted above.  Perhaps that thing is busted, I dunno.