Re: [PATCH 5/6] Teach "fsck" not to follow subproject links

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

 




On Wed, 11 Apr 2007, Junio C Hamano wrote:
> 
> Ah, forget about this.  The HEAD, which is in the tree of the
> higher-level project, is a ref.  Silly me.

Well, not entirely "silly you".

If you do a "git reset" in the superproject, that will obviously have to 
rewrite the heads in the subproject.

I do suspect that we should always enable reflogs for the subprojects, so 
that pruning is safe even for these kinds of situations, but that 
doesn't resolve all issues.

For example: to manage *cloning* of the extra stuff, you might actually 
want to have externally visible refs, and while I suspect the main 
solution will always be to just do good maintenance (ie "don't do 'git 
bisect' and _never_ rewrite history in the main superproject!!"), I don't 
think it's out of the question to add other safety nets too..

So for example, while I'm not sure it's necessary, I don't think it would 
be *wrong* if we might eventually end up having *other* safety features 
like adding a totally separate "refs/superprojects/xyzzy" ref structure. 

Or something like that.. Just to make the refs more visible both 
externally and internally, and to make it much harder to make stupid 
mistakes without realizing it.

I suspect a lot of this will depend on just how many mistakes people make. 
I don't think we've so far had a single problem with alternates files, 
re-basing, and people then pruning away objects used by other repositories 
by mistake, so maybe people really don't make those kinds of mistakes.

So maybe we don't need any extra safety nets at all. But who knows..

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