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

Re: .gitlink for Summer of Code

From
JWJosef Weidendorfer <josef.weidendorfer@gmx.de>
Date
Mar 26, 2007, 23:00 UTC
Message-ID
<200703270100.12920.Josef.Weidendorfer@gmx.de>
In-Reply-To
<20070326220302.GH22773@admingilde.org>
On Tuesday 27 March 2007, Martin Waitz wrote:
Show 12 quoted lines
> On Mon, Mar 26, 2007 at 09:33:44PM +0200, Josef Weidendorfer wrote:
> > The idea was to make this a possible building block for submodules.
> > A simple symlink does not work there when you want the checkout to
> > work even after moving the whole checkout directory around (e.g. to move the
> > submodule around inside of the superproject).
> 
> Well the submodule use case is a bit different than the lightweight
> checkout.
> When you store the submodule object database inside the supermodule then
> you only need to store the position of the submodule relative to its
> supermodule.  As you wrote this is neccessary in order to find the part
> of the object database which belongs to this one submodule.
Where do you store this in your module3 branch?
> Finding the supermodule repository is obviously not difficult, only
> finding the right part of it.
> But for lightweight checkouts you need something which is closer to a
> symlink.
Yes, of course.
Show 10 quoted lines
> > > So having an almost empty .git directory 
> > > and reusing parts from another .git directory makes a lot of sense to
> > > me.
> > 
> > This would work. However, you can not clone from an almost empty .git
> > directory with current git.
> 
> You can't clone from a .gitlink with current git, eighter ;-).
> But if you e.g. set git_dir according to your link then everything
> should work quite easily.
Yes.
Show 8 quoted lines
> > The original proposal was to have a standard .git directory for every
> > light-weight checkout inside of the base .git directory, e.g.
> > in <base>/.git/ext/<name>.git where <name> is some identifier for the
> > lightweight checkout, either provided in the .gitlink file or
> > automatically determined.
> 
> What would you store in these per-checkout directories?
> The index and HEAD?  Anything more?

To make it easy to implement, I thought about a standard .git layout, with most directories being symlinks.

> For submodules I currently use <parent>/.git/objects/module/<submodule>/
> to store the objects belonging to the submodule.
> Perhaps it makes sense to extend this to a full .git directory per
> submodule, I'm not yet decided on that.

IMHO this would be a nice property. As the submodule could exist independently with its own remote heads/tags, you probably would want to at least track these, even if it is a submodule in your superproject. And then it makes sense to move it directly to .git/module/...

There also was a use case where one library project is used in >10 superprojects. It would be nice to be able to make the submodule git dir be outside of the supermodules git dir. However, this also can be done with symlinks without any special support (aside from sharing the head namespace).

Josef
> For submodules the object store has to be different, but for normal
> lightweight checkout this should of course be shared.
Previous: Linus TorvaldsNext: Martin Waitz
Message 56 of 61 in “.gitlink for Summer of Code”
  1. Eric LeshMar 25, 2007
  2. Matthieu MoyMar 25, 2007
  3. Shawn O. PearceMar 25, 2007
  4. Johannes SchindelinMar 25, 2007
  5. Shawn O. PearceMar 25, 2007
  6. Junio C HamanoMar 25, 2007
  7. Shawn O. PearceMar 25, 2007
  8. Petr BaudisMar 27, 2007
  9. Eric LeshMar 26, 2007
  10. Matthieu MoyMar 26, 2007
  11. Eric LeshMar 26, 2007
  12. Martin WaitzMar 26, 2007
  13. Josef WeidendorferMar 26, 2007
  14. Matthieu MoyMar 26, 2007
  15. Josef WeidendorferMar 26, 2007
  16. Matthieu MoyMar 27, 2007
  17. Martin WaitzMar 26, 2007
  18. Junio C HamanoMar 26, 2007
  19. Submodule object storeMartin Waitz, Mar 26, 2007
  20. Junio C HamanoMar 26, 2007
  21. Martin WaitzMar 26, 2007
  22. David LangMar 26, 2007
  23. Martin WaitzMar 26, 2007
  24. David LangMar 26, 2007
  25. Martin WaitzMar 27, 2007
  26. David LangMar 27, 2007
  27. Junio C HamanoMar 27, 2007
  28. Martin WaitzMar 27, 2007
  29. Uwe Kleine-KönigMar 27, 2007
  30. Uwe Kleine-KönigMar 27, 2007
  31. Martin WaitzMar 27, 2007
  32. Josef WeidendorferMar 27, 2007
  33. Martin WaitzMar 27, 2007
  34. Uwe Kleine-KönigMar 27, 2007
  35. Linus TorvaldsMar 27, 2007
  36. Uwe Kleine-KönigMar 27, 2007
  37. Linus TorvaldsMar 27, 2007
  38. Linus TorvaldsMar 27, 2007
  39. Martin WaitzMar 27, 2007
  40. Josef WeidendorferMar 26, 2007
  41. Junio C HamanoMar 26, 2007
  42. Linus TorvaldsMar 27, 2007
  43. David LangMar 27, 2007
  44. Linus TorvaldsMar 27, 2007
  45. Martin WaitzMar 27, 2007
  46. Daniel BarkalowMar 27, 2007
  47. Linus TorvaldsMar 27, 2007
  48. Daniel BarkalowMar 27, 2007
  49. Linus TorvaldsMar 27, 2007
  50. David LangMar 27, 2007
  51. Jakub NarebskiMar 27, 2007
  52. David LangMar 27, 2007
  53. Steven GrimmMar 27, 2007
  54. Daniel BarkalowMar 27, 2007
  55. Linus TorvaldsMar 27, 2007
  56. Josef WeidendorferMar 26, 2007
  57. Martin WaitzMar 26, 2007
  58. Jakub NarebskiMar 26, 2007
  59. Matthieu MoyMar 26, 2007
  60. Jakub NarebskiMar 27, 2007
  61. Shawn O. PearceMar 25, 2007

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.