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

Hi,

On Sat, 24 Jan 2009, Lars Hjemli wrote:

On Fri, Jan 23, 2009 at 20:57, Johannes Schindelin
[off-list ref] wrote:

quoted

 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).

The fact that a user can ask for some object directly, and that we do not 
try to validate it in that case has nothing to do with said assumption.

If something is pushed to a remote, and the connection fails, some commit 
could be pushed already, but some of its reachable objects lacking.

The user on the remote side can still try to salvage parts by accessing 
the objects directly, by their name.

But the only guarantee that the objects are reachable is to start from a 
ref.

Concretely, if your patch is applied as-is, such a half-pushed state could 
affect git-archive in a nasty way: even if the user started from a ref, 
there could be missing objects!

Do you feel it is necessary to perform a reachability check of the 
gitlink'd commit before traversing into a submodule tree?

No.  Because HEAD is a ref, too.

Now, there is still a problem when your submodule is missing the objects 
for the commit your superproject is referring to.

IMO that is a serious issue, as it just asks for confused users.

quoted

- 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.

Nope, doing this "in the future" does not please me one bit.

Besides, I find the semantics, uhm, "interesting".  (The other word would 
be "unintuitive".  Why do you have to be so cryptic that I have to read 
the proposal to understand what the heck "c" is about?)

Ciao,
Dscho