>> The change is not really lost, as you can get it via
>>
>> git checkout HEAD@{1}
>> git submodule update --init
>
> Sure, the commit isn't lost entirely. But a mixed reset is often used
> to mean "go back to before I committed", and here, that's not precisely
> what's happening.
Well, you ran the deinit after the commit, so I don't think
we expect to undo everything up to "just before the commit".
> In other words, it's not confusing to the user.
ok, great :)
>
>> This works most of the time, but it is unreliable as the
>> submodule may have had some gc inbetween which
>> threw away important objects.
>
> Sure; that's a separate issue.
>
>> Steping back a bit, rereading the subject line,
>> what do you think is the bug here?
>>
>> * git-status not reporting about uninitialized submodules?
>
> Here, I think git-status is correctly reporting the state of the repo.
>
>> * git reset --mixed not touching the submodule worktree
>
> Yes, possibly.
>
>> * lack of --recurse-submodules in git-reset? (and that not
>> being default, see prior point)
>
> Or possibly this.
Well even in this case a reset recursing into submodules doesn't change
the (de-)init status of a submodule. All it would alter is the
submodule HEAD pointing to, IMHO.
>
>> * submodules being in detached HEAD all the time?
>
> In this case, the submodule is not initialized, so it is not in any
> state at all.
Oh right.
>
>
> For me, the bug (if any) is the bad user experience of doing a mixed
> reset and expecting to be able to commit (possibly with some git-add
> operations) from there and get back something like the commit to which
> the user had git-reset.
Technically this is also doable,
git reset --mixed HEAD^ # as in the original email
git update-index --add --cacheinfo \
160000,$(git -C .git/modules/sub1 rev-parse HEAD),sub1
git add another_file
git commit -m "recreate the commit"
>
> That's why I have the question mark there -- it's not clear that this
> is a reasonable expectation.
Fuzzing around with gitlinks that are non-populated submodules is
a messy business.
So another way would be to populate the submodule manually
GIT_DIR=.git/modules/sub1 \
GIT_WORKTREE=sub1 \
git checkout -f # implies last HEAD
and then continue in the superproject.
I am making up excuses for poor UX here, though.
I do agree that the expectations may vary wildly because of poor UX
in submodules.
Stefan
