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

Re: [PATCH] t4202 (log): add failing test for log with subtree

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Apr 23, 2013, 16:29 UTC
Message-ID
<CALkWK0mACae7VEe2M-UXhmnU9PUDxu1Ph5HSXb7S4fOGecsFrw@mail.gmail.com>
In-Reply-To
<7vobd5jktd.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> If you need the history context (i.e. M, M^1, M^2) around it to
> interpret that additional information, isn't it essentially the same
> as storing renames in the merge commit M?
There's one big difference.

The point is that for any kind of repository composition, you're going to have to store tree renames at some level if you want to be able to move the submodule around in the tree. In the current submodule system, you could say that you're storing tree renames in a blob (submodule.<name>.path in .gitmodules). Ofcourse, the difference is that the other side of the tree entry is completely opaque to the superproject (and I think we can do better than that now). You should use heuristics for all other kinds of renames, but I'm arguing that repository composition is a special case that needs more thought.

You shouldn't be against storing renames in principle, because we already do that in a way. What you should be against is storing renames in a way that will lock up the repository if a different path is taken to the same state.

What I'm proposing is an optional field to speed up (and make more reliable) rename detection in a very specific case. I'm not putting the information in a commit because that will lock up our repository: If there are two different commits representing the same tree, but one contains bind lines and the other doesn't, we've done something seriously wrong: rebase and merge are screwed. In my case, if there are two perfectly identical trees except that one contains auxiliary information, nothing goes wrong: the tree without the auxiliary information will just be a little slower and can't support DWIM git operations.

> Not very impressed, at least not yet.

Please bear with me. I really think the repository composition problem is worth solving.

Previous: Junio C HamanoNext: Junio C Hamano
Message 29 of 34 in “t4202 (log): add failing test for log with subtree”
  1. t4202 (log): add failing test for log with subtreeRamkumar Ramachandra, Apr 22, 2013
  2. Matthieu MoyApr 22, 2013
  3. Thomas RastApr 22, 2013
  4. Ramkumar RamachandraApr 22, 2013
  5. Ramkumar RamachandraApr 22, 2013
  6. Ramkumar RamachandraApr 22, 2013
  7. Matthieu MoyApr 22, 2013
  8. Thomas RastApr 22, 2013
  9. Thomas RastApr 22, 2013
  10. Ramkumar RamachandraApr 22, 2013
  11. Ramkumar RamachandraApr 22, 2013
  12. Thomas RastApr 22, 2013
  13. Ramkumar RamachandraApr 22, 2013
  14. Ramkumar RamachandraApr 22, 2013
  15. Ramkumar RamachandraApr 22, 2013
  16. Ramkumar RamachandraApr 22, 2013
  17. Thomas RastApr 22, 2013
  18. Ramkumar RamachandraApr 22, 2013
  19. Philip OakleyApr 22, 2013
  20. Ramkumar RamachandraApr 22, 2013
  21. Ramkumar RamachandraApr 22, 2013
  22. Matthieu MoyApr 22, 2013
  23. Junio C HamanoApr 22, 2013
  24. Ramkumar RamachandraApr 22, 2013
  25. Ramkumar RamachandraApr 22, 2013
  26. Junio C HamanoApr 22, 2013
  27. Ramkumar RamachandraApr 23, 2013
  28. Junio C HamanoApr 23, 2013
  29. Ramkumar RamachandraApr 23, 2013
  30. Junio C HamanoApr 22, 2013
  31. Ramkumar RamachandraApr 22, 2013
  32. Matthieu MoyApr 22, 2013
  33. Junio C HamanoApr 22, 2013
  34. Ramkumar RamachandraApr 22, 2013

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.