git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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