Kevin Ballard <kevin@xxxxxx> 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.
--
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
