From: Linus Torvalds <torvalds@osdl.org>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: Fake linear history in a deterministic manner.
Date: Mon, 13 Feb 2006 08:34:19 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0602130819490.3691@g5.osdl.org> (raw)
In-Reply-To: <46a038f90602122158n51fc94a8h2ff2631c16cd28b5@mail.gmail.com>
On Mon, 13 Feb 2006, Martin Langhoff wrote:
>
> In any case, I'm undecided whether to use --topo-order or
> --merge-order. Does it really matter?
Use topo-order.
merge-order is much more expensive to calculate, and doesn't even exist if
NO_OPENSSL is set.
Anyway, while linearization in general is impossible, I'd suggest a few
heuristics:
- you obviously must remember the head of the previous linearization. Any
tree choices you made in the past are not something you can change any
more for cvs export.
This may sound obvious, but the fact is, especially if you do the cvs
export frequently, and the main maintainer updates the tree in a timely
manner, it will limit your choices a LOT. In fact, most of the time
you'll have no choice at all: you will have an unambiguous "TRUNK" that
is defined by the fact that there is only one linear path from the
previous export-head to the current HEAD.
In short, most of the time you won't have any issues in a stable system.
You'll see a true "fork in the road" choice only when the maintainer
hasn't pushed his tree to the thing you export in a while, long enough
that no CVS exporting has taken place over a whole parallel cycle. It's
probably rare.
So the main issue of "which child to choose" becomes one of the initial
export, and then just occasionally thereafter. And in that case, there's
really just one obvious algorithm:
- simply enumerate the possible paths (not that hard - it's just
enumerating a tree once you've generated the graph in memory with child
and parent pointers), and just selecting the one with the "longest
weighted path".
I say "weighted path", because you might want to consider different
commits to have different weights. For example, you might want to consider
merge commits to be less interesting (so weight them as 0.5 commits) in
order to get as many "real" commits as possible. And you might consider
commits made by a certain person to be "more TRUNKish", and give them a
weight of 2, so that you'll be more likely to follow the "maintainer view"
over any other linearized history.
No other algorithm seems very sane.
Linus
next prev parent reply other threads:[~2006-02-13 16:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-13 1:46 Fake linear history in a deterministic manner Martin Langhoff
2006-02-13 5:24 ` Junio C Hamano
2006-02-13 5:58 ` Martin Langhoff
2006-02-13 16:34 ` Linus Torvalds [this message]
2006-02-16 22:29 ` Eric Wong
2006-02-16 23:29 ` Martin Langhoff
2006-02-16 23:54 ` Junio C Hamano
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=Pine.LNX.4.64.0602130819490.3691@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=martin.langhoff@gmail.com \
/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).