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

Re: RFC: grafts generalised

From
Stephen R. van den Berg <srb@cuci.nl>
Date
Jul 2, 2008, 17:59 UTC
Message-ID
<20080702175944.GC16235@cuci.nl>
In-Reply-To
<37fcd2780807021019t76008bbfq265f8bf15f59c178@mail.gmail.com>
Dmitry Potapov wrote:
>I don't think that the grafts file is the right place for this kind of
>information.

Yet the grafts file is exactly the place where this type of "overlay-information" is being placed now. It seems to be the natural place.

> Perhaps, it would be better to have a separate file or
>even a directory with files where commit-id identifies a text file with
>a new commit object, which should be placed instead of an old one.  So,
>it will be easy to tell git filter-branch to use this new information.

Not quite sure why this makes it easier. The point is that there is not supposed to be a grafts file in a proper repository. Thus, having a lot of these files means a larger disruption to the core, and I'd like the core to be as efficient and lean as possible given an empty grafts file. So I'd prefer to keep it to one file.

Show 5 quoted lines
>However, if you want more than just ability to edit commits in a text
>file but also inspect changes using normal git commands and gitk (as it
>is possible with grafts), it will require changes to the git core, which,
>perhaps, not difficult to implement using pretend_sha1_file(), but I am
>not sure that everyone will welcome that...

I'd want to avoid a plethora of files, and the changes that can be specified are supposed to be partial overrides, not complete rewrites. So using pretend_sha1_file() is a bit overkill and more than I was aiming for.

The point is, that the changes in grafts (as they are now) are *not* used when cloning. I.e. the only thing you mess up is your *own* repository, not someone else's. I.e. you can't make someone remote think that the repository has been altered. That would require git filter-branch, which immediately changes all the historical SHA1s, and makes the changes in history blatantly visible.

-- 
Sincerely,
           Stephen R. van den Berg.

You are confused; but this is your normal state.
Previous: Stephen R. van den BergNext: Petr Baudis
Message 33 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.