On Mon, 2017-03-13 at 14:19 -0700, Stefan Beller wrote:
> > > 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".
Sure, but other workdir changes after the commit would have been blown
away; so why not this one?
> > > * 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.
That's OK with me. It's weird, but at least it's explicable.
> > 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"
Yeah, unless the user had done various other operations that messed
with .git/modules/sub1 (e.g. if they had first checked out another
branch with --recurse-submodules).
Also, this updates the index, which a mixed reset isn't supposed to
touch.
> > 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.
Agreed.
> 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.
(see above for why this is not a general solution)
> 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.
I agree that it's not quite clear what to expect. I can just say that
I was quite surprised when my colleague demoed this one for me.
