git-2.22.0/list-objects.c
/*
 * Processing a gitlink entry currently does nothing, since
 * we do not recurse into the subproject.
 *
 * We *could* eventually add a flag that actually does that,
 * which would involve:
 *  - is the subproject actually checked out?
 *  - if so, see if the subproject has already been added
 *    to the alternates list, and add it if not.
 *  - process the commit (or tag) the gitlink points to
 *    recursively.
 *
 * However, it's unclear whether there is really ever any
 * reason to see superprojects and subprojects as such a
 * "unified" object pool (potentially resulting in a totally
 * humongous pack - avoiding which was the whole point of
 * having gitlinks in the first place!).
 *
 * So for now, there is just a note that we *could* follow
 * the link, and how to do it. Whether it necessarily makes
 * any sense what-so-ever to ever do that is another issue.
 */
Processing a gitlink entry currently does nothing, since
we do not recurse into the subproject.

We *could* eventually add a flag that actually does that,
which would involve:
- is the subproject actually checked out.
- if so, see if the subproject has already been added
to the alternates list, and add it if not.
- process the commit (or tag) the gitlink points to
recursively.

However, it's unclear whether there is really ever any
reason to see superprojects and subprojects as such a
"unified" object pool (potentially resulting in a totally
humongous pack - avoiding which was the whole point of
having gitlinks in the first place!).

So for now, there is just a note that we *could* follow
the link, and how to do it. Whether it necessarily makes
any sense what-so-ever to ever do that is another issue.
Processing a gitlink entry currently does nothing since we do not recurse into the subproject . We * could * eventually add a flag that actually does that which would involve : - is the subproject actually checked out . - if so see if the subproject has already been added to the alternates list and add it if not . - process the commit ( or tag ) the gitlink points to recursively . However it ' s unclear whether there is really ever any reason to see superprojects and subprojects as such a " unified " object pool ( potentially resulting in a totally humongous pack - avoiding which was the whole point of having gitlinks in the first place! ) . So for now there is just a note that we * could * follow the link and how to do it . Whether it necessarily makes any sense what - so - ever to ever do that is another issue .
static void process_gitlink(struct traversal_context *ctx,
			    const unsigned char *sha1,
			    struct strbuf *path,
			    const char *name)
{
}
static void process_gitlink ( struct traversal_context * ctx , const unsigned char * sha1 , struct strbuf * path , const char * name ) { }
Processing a gitlink entry currently does nothing, since
 we do not recurse into the subproject.
Processing a gitlink entry currently does nothing since we do not recurse into the subproject .
/* Nothing to do */