From: Eric Wong <normalperson@yhbt.net>
To: Andrew Myrick <amyrick@apple.com>
Cc: git@vger.kernel.org, Sam Vilain <sam@vilain.net>
Subject: Re: git-svn: handling merge-base failures
Date: Sun, 3 Jan 2010 19:45:41 -0800 [thread overview]
Message-ID: <20100104034540.GA4548@dcvr.yhbt.net> (raw)
In-Reply-To: <7878A426-9D87-43B5-A10A-38F3C9369165@apple.com>
Andrew Myrick <amyrick@apple.com> 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.
> I've created a small svn repository that demonstrates this failure
> with git v1.6.6. Its dump is attached.
Thanks. This (and a similar dump a few weeks back) will definitely
come in handy for writing test cases and fixing this long-standing
issue.
--
Eric Wong
next prev parent reply other threads:[~2010-01-04 3:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-23 19:54 git-svn: handling merge-base failures Andrew Myrick
2009-12-23 20:09 ` Eric Wong
2009-12-23 20:18 ` Andrew Myrick
2009-12-23 20:57 ` Eric Wong
2010-01-04 1:37 ` Andrew Myrick
2010-01-04 3:45 ` Eric Wong [this message]
2010-01-04 4:43 ` Andrew Myrick
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=20100104034540.GA4548@dcvr.yhbt.net \
--to=normalperson@yhbt.net \
--cc=amyrick@apple.com \
--cc=git@vger.kernel.org \
--cc=sam@vilain.net \
/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