git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcus Brinkmann <m.brinkmann@semantics.de>
To: "David A. Greene" <greened@obbligato.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Dave Ware <davidw@realtimegenomics.com>, <git@vger.kernel.org>
Subject: Re: [PATCH] contrib/subtree: Split history with empty trees correctly
Date: Sun, 24 Jan 2016 14:07:17 +0100	[thread overview]
Message-ID: <56A4CC85.90705@semantics.de> (raw)
In-Reply-To: <871t9cvqsp.fsf@waller.obbligato.org>

With my patch, "git subtree split -P" produces the same result (for my
data set) as "git filter-branch --subdirectory-filter", which is much
faster, because it selects the revisions to rewrite before rewriting.
As I am not using any of the advanced features of "git subtree", I will
just use "git filter-branch" instead.

Thanks!
Marcus

On 01/20/2016 05:05 AM, David A. Greene wrote:
> Marcus Brinkmann <m.brinkmann@semantics.de> writes:
> 
>> 'git subtree split' will fail if the history of the subtree has empty
>> tree commits (or trees that are considered empty, such as submodules).
>> This fix keeps track of this condition and correctly follows the history
>> over such commits.
> 
> Thanks for working on this!  Please add a test to t7900-subtree.sh.
> 
>> @@ -625,12 +629,16 @@ cmd_split()
>>  		
>>  		# ugly.  is there no better way to tell if this is a subtree
>>  		# vs. a mainline commit?  Does it matter?
>> -		if [ -z $tree ]; then
>> -			set_notree $rev
>> -			if [ -n "$newparents" ]; then
>> -				cache_set $rev $rev
>> +		if [ -z $found_first_commit ]; then
>> +			if [ -z $tree ]; then
>> +				set_notree $rev
>> +				if [ -n "$newparents" ]; then
>> +					cache_set $rev $rev
>> +				fi
>> +				continue
>> +			else
>> +				found_first_commit=yes
>>  			fi
>> -			continue
>>  		fi
>>
>>  		newrev=$(copy_or_skip "$rev" "$tree" "$newparents") || exit $?
> 
> Can you explain the logic here?  The old code appears to be using the
> lack of a tree to filter out "mainline" commits from the subtree history
> when splitting.  If that test is only done before seeing a proper
> subtree commit and never after, then any commit mainline commit
> following the first subtree commit in the rev list will miss being
> marked with set_notree and the cache will not have the identity entry
> added.
> 
> Test #36 in t7900-subtree.sh has a mainline commit listed after the
> first subtree commit in the rev list, I believe.
> 
> I'm not positive your change is wrong, I'd just like to understand it
> better.  I'd also like a comment explaining why it works so future
> developers don't get confused.  Overall, I am trying to better comment
> the code as I make my own changes.
> 
>                            -David
> 


-- 
s<e>mantics GmbH
Viktoriaallee 45
52066 Aachen
Web: www.semantics.de
Registergericht  : Amtsgericht Aachen, HRB 8189
Geschäftsführer  : Kay Heiligenhaus M.A.
                   Dipl. Ing. José de la Rosa

  parent reply	other threads:[~2016-01-24 13:08 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
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 [this message]
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=56A4CC85.90705@semantics.de \
    --to=m.brinkmann@semantics.de \
    --cc=davidw@realtimegenomics.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=greened@obbligato.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).