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

From: David A. Greene <greened@obbligato.org>
Date: Jan 17, 2016, 23:23 UTC
Message-ID: <87twmbaizo.fsf@waller.obbligato.org>
In-Reply-To: <xmqq4meeflws.fsf@gitster.mtv.corp.google.com>

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

Show 19 quoted lines

> 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