Jens Lehmann <> writes:

> Am 17.06.2014 00:49, schrieb Junio C Hamano:
>> Jens Lehmann <> writes:
>>> +           git checkout -b "add_sub1" &&
>>> +           git submodule add ./. sub1 &&
>> This is not technically wrong per-se, but having the project's
>> history itself as its own submodule *is* something nobody sane would
>> do in the real life.  Do we really have to do it this unusual way?
> I agree that this isn't a sane setup for real world usage, but I did
> that because it makes things easier when adding tests for recursive
> submodule update later, as we can then use the same test setup just
> one submodule level deeper.

Hmmm... ok....

>>> +           GIT_WORK_TREE=. git config --unset core.worktree
>> Hmph.  What does GIT_WORK_TREE=. alone without GIT_DIR=<somewhere>
>> do?  It's not like it is a workaround for "git config" that complains
>> when you do not have a working tree, right?  Puzzled...
> It is, it overrides the core.worktree config that would stop us
> from unsetting the core.worktree config with this error message:
>   fatal: Could not chdir to '../../../sub1': No such file or directory
> (We use the same pattern in and some other tests)

Is this a work-around for a bug in "git config"?  Or is this an
expected failure and it is unusual and not realistic outside of test
setup to want to unset core.worktree?  I am inclined to think it is
the latter, but I dunno.

>>> +           sha1=$(git ls-tree HEAD "sub1" 2>/dev/null | grep 160000 | tr 
>>> '\t' ' ' | cut -d ' ' -f3) &&
>> Why discard the standard error stream?
> Because we sometimes reset to commits where "sub1" isn't present:
>   fatal: Path 'sub1' does not exist in 'HEAD'

Huh?  We shouldn't.

        $ git ls-tree HEAD no-such; echo $?

It discards errors that may happen in other situations, too---is
that something we do not have to worry about?

> Cool, that's much better. Due to the sometimes missing "sub1" I
> needed to modify it to drop the error and not fail:
>   sha1=$(git rev-parse HEAD:sub1 2>/dev/null || true) &&

The "HEAD:sub1" notation does require that the path exists in the
specified tree-ish.  Even if we tried to express the above in a more
carefully written form:

        # We may or may not have sub1 in HEAD
        if "sub1 exists in HEAD"
                sha1=$(git rev-parse HEAD:sub1)
                sha1= # empty

we would end up using "git rev-parse HEAD:sub1" to implement "sub1
exists in HEAD" part, so your updated alternative would be the best
we could do, I would think.

>>> +# Test that the given submodule at path "$1" contains the content according
>>> +# to the submodule commit recorded in the superproject's commit "$2"
>>> +test_submodule_content () {
>>> +   if test $# != 2
>>> +   then
>>> +           echo "test_submodule_content needs two arguments"
>>> +           return 1
>>> +   fi &&
>>> +   submodule="$1" &&
>>> +   commit="$2" &&
>>> +   test -d "$submodule"/ &&
>>> +   if ! test -f "$submodule"/.git && ! test -d "$submodule"/.git
>> I wonder if we can get away with a single "test -e" (we do not
>> expect us to be creating device nodes or fifos there, do we?).
> But a symbolic link maybe?

Symlinks should pose no problems, I would say, without loosening

        $ test -f RelNotes; echo $?; test -e RelNotes; echo $?
        $ ln -s t tests; test -d tests; echo $?; test -e tests; echo $?
        $ ln -s no-such x; test -f x; echo $?; test -e x; echo $?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to