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

Re: [RFC] deprecating and eventually removing "git relink"?

From
Miles Bader <miles@gnu.org>
Date
Nov 15, 2011, 04:40 UTC
Message-ID
<buok472t2vb.fsf@dhlpc061.dev.necel.com>
In-Reply-To
<7vmxbzj927.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 11 quoted lines
>> It might be nice to have a mechanism where new objects would update
>> the _alternate_ rather than the object-store in the tree where the
>> command was run.
>
> With the alternate mechanism, your borrowing is read-only and that is
> exactly why you can borrow from other peoples' repositories to which you
> have no write permission to.
>
> What you are suggesting is fundamentally different from the alternates
> mechanism. I am not saying it is better or worse, though. Not yet at this
> point in this message.

Sure, and I don't even claim it's a viable idea, just something that "seems useful."

Show 11 quoted lines
>> .. then you could easily have a bunch of trees using a central
>> object store without needing to update the central store
>> occasionally by hand (and do gc in its "clients")...
>
> If you write objects to the central store, "gc" in the "clients"
> will be a no-op because they do not have their own objects. But
> instead, crufts your "clients" accumulate will be in the central
> store. There is still need for "gc" at the central store to remove
> things that are no longer used by any client, isn't it? Unless you
> declare that you do not care because perhaps the central store is
> large enough, that is.

Sure, if git had this mode of operation, it would seem desirable for "git gc" to act on the central store just at the same points it acts on the "local store" today.

As obviously a gc needs to know all the roots, that suggests the central store needs to have a list of clients it can scan for roots.

[I suppose the other "problem" is locking; I guess that would technically be no different that multiple git commands running simulataneously in the same tree today, but maybe the presence of a central store would make such situations occur more frequently...]

Show 5 quoted lines
> At least with the alternates, running "gc" in the "clients" is a
> safe operation and the only change necessary is to make fsck/repack
> aware of the repositories that borrow from the repository these
> commands are run, and the logic to do so is exactly the same as the
> case to run "gc" in your central store, I would think.
Hmmm sure.
-miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.
Previous: Junio C Hamano
Message 15 of 15 in “[RFC] deprecating and eventually removing "git relink"?”
  1. Junio C HamanoNov 14, 2011
  2. Miles BaderNov 14, 2011
  3. Junio C HamanoNov 14, 2011
  4. Chris PackhamNov 14, 2011
  5. Simon BrennerNov 14, 2011
  6. Jeff KingNov 14, 2011
  7. Junio C HamanoNov 14, 2011
  8. Jeff KingNov 14, 2011
  9. Junio C HamanoNov 14, 2011
  10. Miles BaderNov 15, 2011
  11. Phillip SusiNov 21, 2011
  12. Jeff KingNov 21, 2011
  13. Phillip SusiNov 22, 2011
  14. Junio C HamanoNov 14, 2011
  15. Miles BaderNov 15, 2011

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.