Re: Fake linear history in a deterministic manner.

From: Eric Wong <normalperson@yhbt.net>
Date: Feb 16, 2006, 22:29 UTC
Message-ID: <20060216222956.GA5818@Muzzle>
In-Reply-To: <46a038f90602121746v5adb448ej73cc2be6dd3745ce@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com> wrote:

Show 5 quoted lines

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

Show 8 quoted lines

> 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