git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miles Bader <miles@gnu.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] deprecating and eventually removing "git relink"?
Date: Tue, 15 Nov 2011 13:40:24 +0900	[thread overview]
Message-ID: <buok472t2vb.fsf@dhlpc061.dev.necel.com> (raw)
In-Reply-To: <7vmxbzj927.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:
>> 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."

>> .. 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...]

> 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.

      reply	other threads:[~2011-11-15  4:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-14  0:38 [RFC] deprecating and eventually removing "git relink"? Junio C Hamano
2011-11-14  6:06 ` Miles Bader
2011-11-14  6:27   ` Junio C Hamano
2011-11-14  9:03     ` Chris Packham
2011-11-14  8:48   ` Simon Brenner
2011-11-14 10:34     ` Jeff King
2011-11-14 20:18       ` Junio C Hamano
2011-11-14 20:25         ` Jeff King
2011-11-14 22:08           ` Junio C Hamano
2011-11-15  4:48             ` Miles Bader
2011-11-21 22:09       ` Phillip Susi
2011-11-21 22:19         ` Jeff King
2011-11-22  1:58           ` Phillip Susi
2011-11-14 10:24   ` Junio C Hamano
2011-11-15  4:40     ` Miles Bader [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=buok472t2vb.fsf@dhlpc061.dev.necel.com \
    --to=miles@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).