Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules

[Lars Hjemli <hjemli@gmail.com>]

On Fri, Jan 23, 2009 at 20:57, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> On Fri, 23 Jan 2009, Lars Hjemli wrote:
>>
>> That's too bad, I hoped on some feedback from you on the part of the
>> commit message which you didn't quote:
>
> Well, you ignored my comments,

I might have misunderstood your comments, but I certainly didn't
ignore them. I actually tried to come up with a solution that would
solve your concerns about which submodules to include in the archive
(which is why I hoped for some feedback on that proposal).


> so what do you expect me to do?  Be happy?
>
> There are two issues there:
>
> - presence of a specific commit object being present in the repository
>  does not necessarily mean that it is reachable by any ref, and therefore
>  can mean that the tree/blob objects are not reachable, because it could
>  be an interrupted fetch;

This part I agree with.


>  in all of Git, we try to assume that only
>  reachable objects are valid objects.

I don't think this is true (most git commands accepts their arguments
as valid objects without verifying if they are reachable from a ref).
Do you feel it is necessary to perform a reachability check of the
gitlink'd commit before traversing into a submodule tree?


> - presence of a specific commit in the supermodule is a _lousy_ indicator
>  that the user wants to include that submodule in the archive.

This is the issue I tried to address with my
`--submodules=[a|c|r][g:<name>]` proposal in the commit message for
this patch. I hoped you would find it interesting, given your comments
in http://thread.gmane.org/gmane.comp.version-control.git/106167/focus=106235
(i.e. my 'a' flag would match your 'look-in-superprojects-odb', while
the 'c', 'r' and 'g' options would address your issues about how to
select the correct set of submodules).

--
larsh