Re: BUG: git subtree split gets confused on removed and readded directory

[greened@obbligato.org (David A. Greene)]

Junio C Hamano <gitster@pobox.com> writes:

> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
>
>> I made a simple test repository showing the problem here:
>> https://github.com/lambdafu/git-subtree-split-test>
>> After creating the master branch, I created the split/bar branch like this:
>>
>> $ git subtree split -P bar -b split/bar
>>
>> The resulting history is confused by the directory "bar" which was
>> added, removed and then re-added again.  The recent history up to adding
>> the directory the second time is fine.  But then it seems to loose track
>> and add the parent of that commit up to the initial commit in the history.
>>
>> I'd expect that the parent of the readding commit is an empty tree
>> commit (which removed the last files in the directory), and that before
>> that are commits that reflect the initial creation of that directory
>> with its files, but rewritten as a subtree, of course.
>
> Thanks for a report.

Yes, thank you!

> David, does this ring a bell?

No, I have not run into this before.  I'm actually going to be working
in the split code starting sometime this month (work allowing, of
course).  So it's great to get a report like this.

One of the things I want to do is eventually move over subtree split to
using a proper filter-branch instead of the entirely custom code that's
currently there.  This does, however, appear to cause a semntic
difference in preliminary testing which I am still tracking down.  The
filter-based split is *incredibly* faster than the current code.  The
current code can take hours on moderately-sized histories.

This should shake out a lot of these kinds of problems since the
filter-branch code is heavily used and tested while the subtree split
code is not.

Assuming this goes ahead, I plan to introduce a new switch to control
filter-branch vs. original code and migrate the default to filter-branch
if all goes well.

I'll write up a failing test for this so that I remember to address it
when I get to the code.

Thanks again, Marcus!

                         -David