Re: RFC: grafts generalised

["Dmitry Potapov" <dpotapov@gmail.com>]

On Wed, Jul 2, 2008 at 11:31 PM, Stephan Beyer <s-beyer@gmx.net> wrote:
>
> I'm somehow quite confused about the desired workflow but I try an
> answer.

I don't think we speak about any normal workflow but about importing
"initially disjunct CVS and SVN repositories into larger complete
histories inside a single git repository." This is one-time work, not
a regular workflow.

>
> Stephen R. van den Berg wrote:
>> As far as I understood it, the new git sequencer rewrites history
>> proper.  That is timeconsuming by definition, and thus it is *not*
>> possible to make a tool based on the sequencer that supports the desired
>> iterative-history-rewrite workflow.
>
> If I got the problem right, it is possible.
> But you have to rewrite and cannot just fake history, of course.

Using grafts allows you to fake history, which is very useful during
import, because it allows you to edit history without running any
filter-branch, which is very timeconsuming. Of course, at the end
you have to run git filter-branch to have the "true" history, otherwise
anyone who clones from you will end up with a broken repo.

The purpose of rebase (and I believe the sequencer too) is rather
different -- to allow you to keep your changes as patches to the
upstream.

> I wonder if grafts can be used in combination with sequencer in such a
> way that you rewrite foo~20000..foo~19950 and then fake the parents of
> foo~19949 to be the rewritten once.

I don't think it is a good idea. During the normal work you should never
use grafts. Well, you can use grafts to add old history, but using it for
anything else is really dangerous, because its *fakes* history. git rebase
(and AFAIK sequencer too) just re-write history of some branch. IOW, it
creates another branch from a different starting point using patches from
some existing branch and then reassign the branch name to it.

Dmitry