git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: RFC: grafts generalised

From
Dmitry Potapov <dpotapov@gmail.com>
Date
Jul 2, 2008, 20:42 UTC
Message-ID
<37fcd2780807021342j75f351a5sa525b892caedf965@mail.gmail.com>
In-Reply-To
<20080702193157.GA21297@leksak.fem-net>
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.

Show 9 quoted lines
>
> 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
Previous: Stephan BeyerNext: Stephan Beyer
Message 10 of 36 in “RFC: grafts generalised”
  1. Stephen R. van den BergJul 2, 2008
  2. Jakub NarebskiJul 2, 2008
  3. Michael J GruberJul 2, 2008
  4. Stephen R. van den BergJul 2, 2008
  5. Mike HommeyJul 2, 2008
  6. Michael J GruberJul 2, 2008
  7. Stephen R. van den BergJul 2, 2008
  8. Stephan BeyerJul 2, 2008
  9. Stephan BeyerJul 2, 2008
  10. Dmitry PotapovJul 2, 2008
  11. Stephan BeyerJul 2, 2008
  12. Stephen R. van den BergJul 3, 2008
  13. Andreas EricssonJul 7, 2008
  14. Stephen R. van den BergJul 7, 2008
  15. Stephen R. van den BergJul 2, 2008
  16. Petr BaudisJul 3, 2008
  17. Stephen R. van den BergJul 3, 2008
  18. Jakub NarebskiJul 4, 2008
  19. Dmitry PotapovJul 2, 2008
  20. Dmitry PotapovJul 2, 2008
  21. Stephen R. van den BergJul 2, 2008
  22. Dmitry PotapovJul 2, 2008
  23. Dmitry PotapovJul 2, 2008
  24. Stephen R. van den BergJul 2, 2008
  25. Avery PennarunJul 2, 2008
  26. Junio C HamanoJul 2, 2008
  27. Junio C HamanoJul 2, 2008
  28. Junio C HamanoJul 3, 2008
  29. Johannes SixtJul 3, 2008
  30. Stephen R. van den BergJul 3, 2008
  31. Johannes SixtJul 3, 2008
  32. Stephen R. van den BergJul 3, 2008
  33. Stephen R. van den BergJul 2, 2008
  34. Petr BaudisJul 3, 2008
  35. Petr BaudisJul 3, 2008
  36. Junio C HamanoJul 3, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.