From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 16 Feb 2006 22:29:57 GMT
Subject: Re: Fake linear history in a deterministic manner.
Message-ID: <20060216222956.GA5818@Muzzle>
In-Reply-To: <46a038f90602121746v5adb448ej73cc2be6dd3745ce@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com> wrote:
> To emulate `cvs log somepath` I need to munge history to look linear.
> I am working on the theory that I will tell the cvs client about *one*
> linear history, and show merges from parallel histories as a merge
> commit, "flattened" so to speak, and with a commit message where I'll
> list the hash and first line of each commit that it involves.

I'd be interested in exporting from git to SVN with something like this.

> I thought briefly about delaying the decision until I see the merge,
> and pick the leftmost, or rightmost, if there is some bias in
> git-merge or cg-merge on putting whatever origin has on a particular
> side. It'd mean running backwards through history and that the very
> last merge can flip the decision entirely. Hmmm... any strategy I can
> come up with means that each new merge throws the dice again entirely.
> 
> Ideas?

I'd actually like to do this interactively in gitk.  Just browse history
visually and pick the path you want to choose each time there's a merge,
and then having it output the revisions to stdout or saved to a file
after you're done picking.  Ideally you'd be able to use saved output
interactively, as well.

-- 
Eric Wong