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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Marcus Brinkmann <marcus.brinkmann@xxxxxxxxxxxxxxxxxx> 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
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]