Re: git-svn: handling merge-base failures

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

 



On Jan 3, 2010, at 7:45 PM, Eric Wong wrote:

> Andrew Myrick <amyrick@xxxxxxxxx> wrote:
>> On Dec 23, 2009, at 11:54 AM, Andrew Myrick wrote:
>>> One of my projects is failing to clone because merge-base is failing
>>> on one of the revisions; the branch is a partial branch, so
>>> merge-base can't find a common ancestor with trunk.  I'd like to
>>> catch the exception that command_oneline should throw when
>>> merge-base fails,
>> 
>> Instead of using the Error.pm module, I was able to handle the
>> exception with the more basic eval block.  However, there are some
>> details here I would like to discuss with the community.
>> 
>> When git-svn fetches a partial branch, it appears to refetch all of
>> the history of the subdirectory from which the branch was created.
>> This creates new commits for the old revisions, and these new commits
>> exist as a separate history for the partial branch.   When git-svn
>> fetches the revision at which this partial branch is merged back to
>> trunk, git-svn attempts to run merge-base to find a common ancestor.
>> However, because the partial branch has its own history, the
>> merge-base fails, and git-svn dies.
>> 
>> Naively handling the exception with an eval block and skipping the
>> merge ticket works fine in that it brings us back to parity with git
>> 1.6.5.7, but it means that the merge parent relationship between trunk
>> and the partial branch is lost.  Is there any way to preserve this
>> information, or does the separate commit history of the partial branch
>> make it fundamentally impossible?
> 
> Hi Andrew,
> 
> A method of preserving the $SVN_PATH <=> $PARENT@$REV mapping for
> reusing follow_parent-created branches is definitely desired.
> 
> I've just been lacking time and motivation these days with other
> projects taking priority.  Help (even if it's just to refactor/cleanup
> existing code) would definitely be appreciated here.

Thanks for the explanation, Eric.  Unfortunately, I also don't have the time to commit to taking this on for the foreseeable future.  I'll try to get my existing patches out in the next couple of days that at least fix the regressions from 1.6.5.7.

Regards,
Andrew

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