Re: Alternates and push

Theodore Tso [off-list ref] writes:

On Sat, Sep 06, 2008 at 11:06:49AM -0700, Junio C Hamano wrote:

quoted

We could instead redefine the semantics of the existing alternates
mechanism.  This technically *breaks* backward compatibility, but I
suspect it won't hurt many existing installations:

 - Declare that a freestanding object store is illegal.  In other words,
   if a directory "$D/objects" is (1) used as $GIT_OBJECT_DIRECTORY's
   value, (2) pointed by some repository's "alternates" file, or (3)
   listed in $GIT_ALTERNATE_OBJECT_DIRECTORIES's value, this change makes
   it illegal for "$D" not being a proper git repository.

   This will not break your example of your repository's object store
   borrowing from the object store inside Linus's repository.

 - When you have "$D/objects" in alternates, start relying on "$D/refs"
   being correct (i.e. repository $D is not corrupt).  This technically
   makes the system slightly less robust, as we are depending on _other
   people's_ good behaviour even more when you use alternates, but you are
   already depending on them having good objects in $D/objects anyway, so
   it is not a big deal.

One way that wouldn't break backwards compatibility would be to use
$D/refs if it exists, but if it isn't, fall back to existing behavior
(which is to say, only use the refs in the repository, not in the
borrowed repository/object store).  Is there a reason why this would
be problematic?

I think you just reiterated what I said in "we could instead", and I think
we are in agreement.

I already stated the reason this could be problematic and also I said I do
not think it is a big deal in the above.

I think the question to ask at this point is not "is there a reason why
this would be problematic", but "is it really not a big deal as Junio
claims?" and "aren't there _other_ reasons than the above that makes it
problematic?".

The arguments to make are "Junio is worrying too much; depending on the
other repository's ref is no worse than depending on the objects the other
repository uses, and here is a proof that it is not just 'not a big deal'
but 'no problem at all'", "I've polled the userbase and there is no
existing configuration that will be broken by this change", and "I have
this configuration that will be broken by above change, don't do it".

On Sun, Sep 07, 2008 at 05:02:05PM -0700, Junio C Hamano wrote:

I think you just reiterated what I said in "we could instead", and I think
we are in agreement.

Sorry, I misunderstood what you were saying.  I thought you were
proposing that if $D/refs didn't exist, then if alternates pointed at
$D/objects, git would reject using it.  But that makes no sense, which
is why I didn't understand why you proposed it.  (Turns out I
misunderstood you.  :-)

The arguments to make are "Junio is worrying too much; depending on the
other repository's ref is no worse than depending on the objects the other
repository uses, and here is a proof that it is not just 'not a big deal'
but 'no problem at all'", "I've polled the userbase and there is no
existing configuration that will be broken by this change", and "I have
this configuration that will be broken by above change, don't do it".

So the only configuration I can think of that would be broken by this
is where $D/refs exists, but is insane.  (i.e., such that git fsck for
$D would result in errors).  That seems pretty unlikely...

   	 	   	     	  	       - Ted