Re: [PATCH v8 4/8] submodule: allow add_submodule_odb to work even if path is not checked out

Jacob Keller [off-list ref] writes:

submodule. I think we already have the complete path. Or is the name
*not* equivalent to the path?

A submodule that is bound to top-level at "path" originally gets
"path" as its name.  If you move it elsewhere, you do not want it to
lose its identity (and its place in .git/modules/* of the
top-level).  so a submodule whose name is "path" can reside in the
new place after such a move.

There was no empty line in the place I copied from.

Is that "because I copied from a source that is mistaken, I refuse
to make it right"?  Or just an explanation why there is a mistake?
Or something else (like "we should update the original one while we
are at it as a pure clean-up")?

If we put them in test_expect_success setup they aren't.

Yes, that is why I said they are unnecessary.  Let's minimize the
amount of random code that sits outside the control of the test
framework (i.e. test_expect_{success,failure}).

Thanks.

On Fri, Aug 19, 2016 at 2:11 PM, Junio C Hamano [off-list ref] wrote:

Jacob Keller [off-list ref] writes:

quoted

submodule. I think we already have the complete path. Or is the name
*not* equivalent to the path?

A submodule that is bound to top-level at "path" originally gets
"path" as its name.  If you move it elsewhere, you do not want it to
lose its identity (and its place in .git/modules/* of the
top-level).  so a submodule whose name is "path" can reside in the
new place after such a move.

Is there a way to do this lookup? I couldn't find it.

quoted

There was no empty line in the place I copied from.

Is that "because I copied from a source that is mistaken, I refuse
to make it right"?  Or just an explanation why there is a mistake?
Or something else (like "we should update the original one while we
are at it as a pure clean-up")?

That was an explanation for "I didn't understand that was a mistake"
and a "if we fix this we might want to fix them also to avoid this
same problem in the future".

quoted

If we put them in test_expect_success setup they aren't.

Yes, that is why I said they are unnecessary.  Let's minimize the
amount of random code that sits outside the control of the test
framework (i.e. test_expect_{success,failure}).

Yes I agree.

Thanks,
Jake

Thanks.