From: greened@obbligato•org (David A. Greene)
To: Junio C Hamano <gitster@pobox•com>
Cc: Dave Ware <davidw@realtimegenomics•com>,
git@vger•kernel.org,
Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum•de>
Subject: Re: BUG: git subtree split gets confused on removed and readded directory
Date: Sun, 17 Jan 2016 17:23:07 -0600 [thread overview]
Message-ID: <87twmbaizo.fsf@waller.obbligato.org> (raw)
In-Reply-To: <xmqq4meeflws.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Fri, 15 Jan 2016 15:44:19 -0800")
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
next prev parent reply other threads:[~2016-01-17 23:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 16:23 BUG: git subtree split gets confused on removed and readded directory Marcus Brinkmann
2016-01-15 23:44 ` Junio C Hamano
2016-01-17 19:34 ` David Ware
2016-01-17 23:23 ` David A. Greene [this message]
2016-01-20 1:17 ` [PATCH] contrib/subtree: Split history with empty trees correctly (was: Re: BUG: git subtree split gets confused on removed and readded directory) Marcus Brinkmann
2016-01-20 4:05 ` [PATCH] contrib/subtree: Split history with empty trees correctly David A. Greene
2016-01-20 11:22 ` Marcus Brinkmann
2016-01-28 2:55 ` David A. Greene
2016-01-24 13:07 ` Marcus Brinkmann
2016-01-28 2:56 ` David A. Greene
2016-01-28 4:06 ` Marcus Brinkmann
2016-02-03 2:34 ` David A. Greene
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twmbaizo.fsf@waller.obbligato.org \
--to=greened@obbligato$(echo .)org \
--cc=davidw@realtimegenomics$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=marcus.brinkmann@ruhr-uni-bochum$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox