Re: Submodules can't work recursively because Git implements policy?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 6, 2009 at 4:51 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:

> What, like a secret shadow repository that you move the objects into?
>
> That could be very expensive in terms of disk IO if those objects
> are in large packs.  You'd need to break the pack apart into the
> "ok" and "sekret" parts.  Ick.

Well, ok. Just popping then?
Or adding the wrong publication to a forbidden fetch list?

>> But anyway: If I implement support for fetching SHA keys and full
>> recursive behaviour in the presence of submodules; would my patches
>> automatically be rejected because of the rationale for the current
>> behaviour?
>
> See my recent email (like ~10-15 minutes ago).  It will be rejected
> due to the issue that unreachable objects are subjected to GC and
> you'd easily see your repository delete that data on the next "git
> gc" invocation.  Automatic data destruction is not something that
> users come to git for.

Indeed not. But I don't want to suggest that named references
shouldn't be necessary. Just that it should be possible to fetch based
on the SHA key if that commit is (still) available on the remote end.

BR / Klas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]