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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:04

Junio C Hamano [off-list ref] writes:
Linus Torvalds [off-list ref] writes:
quoted
On Wed, 11 Apr 2007, Junio C Hamano wrote:
quoted
The small detail in the last step is wrong, though.  Even if
they EXIST, they may be isolated commits that are note connected
to refs, and fsck in the repository would not have warned about
unreachable trees from such unconnected commits.
The superproject *is* a ref.
But when you fsck the subproject repository in isolation in the
earlier step in your procedure, that is not taken into account,
is it?
Ah, forget about this.  The HEAD, which is in the tree of the
higher-level project, is a ref.  Silly me.

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:04


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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help