From: Keith Packard <keithp@keithp.com>
To: Chris Shoemaker <c.shoemaker@cox.net>
Cc: keithp@keithp.com, Linus Torvalds <torvalds@osdl.org>,
David Mansfield <centos@dm.cobite.com>,
David Mansfield <cvsps@dm.cobite.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Fix branch ancestry calculation
Date: Fri, 24 Mar 2006 23:54:16 -0800 [thread overview]
Message-ID: <1143273256.6850.86.camel@neko.keithp.com> (raw)
In-Reply-To: <20060325014532.GB32522@pe.Belkin>
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On Fri, 2006-03-24 at 20:45 -0500, Chris Shoemaker wrote:
> If that last sentence was a typo then you already know this, but
> otherwise you may be disappointed to learn that it's not _always_
> possible to discern the correct ancestry tree.
Sure, it's possible to generate trees which can't be figured out. So
far, I haven't found any which can't be pieced back together, except in
cases where the tree was accidentally damaged (child branches created on
two separate parent branches)
> If you end up comparing the ancestry tree discovered by your tool and
> the tree output by a patched cvsps, I would be very interested in the
> results.
So far, I've found several concrete trees where cvsps (in any form)
assigns branch points many versions too early compared to the 'true'
history. My tool is getting better answers, but still can't compute the
tree for the X.org X server tree yet. That one has a wide variety of
damage, including the direct copying of ,v files between repositories
which had divered, and the accidental branching of files from different
parent branches. I keep poking at it...
> -chris
>
> (*) You can distinguish between A->B->head and B->A->head simply by
> date.
I'm doing a lot more date-based identification than I'm really
comfortable with; the bad thing here is that branch points can occur
long before any commits to that branch, when doing date-based
operations, you have a range of possible matching branch points and it's
hard to disambiguate.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
prev parent reply other threads:[~2006-03-25 7:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-23 1:29 Fix branch ancestry calculation Linus Torvalds
2006-03-23 1:50 ` [RFC] Make dot-counting ignore ".1" at the end Linus Torvalds
2006-03-23 6:26 ` Keith Packard
2006-03-23 6:34 ` Linus Torvalds
2006-03-23 7:17 ` Keith Packard
2006-03-24 14:40 ` David Mansfield
2006-03-24 14:45 ` Fix branch ancestry calculation David Mansfield
2006-03-24 15:46 ` Linus Torvalds
2006-03-24 16:38 ` Keith Packard
2006-03-25 1:45 ` Chris Shoemaker
2006-03-25 7:54 ` Keith Packard [this message]
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=1143273256.6850.86.camel@neko.keithp.com \
--to=keithp@keithp.com \
--cc=c.shoemaker@cox.net \
--cc=centos@dm.cobite.com \
--cc=cvsps@dm.cobite.com \
--cc=git@vger.kernel.org \
--cc=torvalds@osdl.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).