Re: [PATCH] contrib/subtree: Split history with empty trees correctly

[Marcus Brinkmann]

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  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
> 


-- 
smantics 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] contrib/subtree: Split history with empty trees correctly

[Marcus Brinkmann]

On 01/28/2016 03:56 AM, David A. Greene wrote:

Marcus Brinkmann  writes:


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.


Heh.  :)

I hope to replace all that ugly split code with filter-branch as you
describe but there are some cases where it differs.  It may be that your
changes fix some of that.

Are you still able to do a re-roll on this?


I have to admit that my interest has declined steeply since discovering 
that subtree-split and filter-branch --subtree-filter give different 
results from "git svn" on the subdirectory.  The reason is that git-svn 
includes all commits for revisions that regular "svn log" gives on that 
directory, which includes commits that serve as branch points only or 
that are empty except for unhandled properties.


While empty commits for unhandled properties wouldn't be fatal, missing 
branch points make "git svn" really unhappy when asked to rebuild .git/svn.


As migration from SVN is my main motivation at this point to use a 
subtree filter at this point (git-svn is just very slow - about one week 
on our repository), I am somewhat stuck and back to using git-svn. 
Although hacking up something with filter-branch seems like a remote 
option, it's probably nothing that generalizes.


It didn't help that "make test" in contrib/subtree gives me 27 out of 29 
failed tests (with no indication how to figure out what exactly failed).


Oh well :)

Marcus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html