Re: bug?: git reset --mixed ignores deinitialized submodules

From: David Turner <novalis@novalis.org>
Date: Mar 13, 2017, 21:36 UTC
Message-ID: <1489440993.10192.58.camel@novalis.org>
In-Reply-To: <CAGZ79ka=OwSWGDBqiZ5X9LvOXphFe5=QjmH9DoeWLu2svmVtyg@mail.gmail.com>

On Mon, 2017-03-13 at 14:19 -0700, Stefan Beller wrote:

Show 13 quoted lines

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

Show 8 quoted lines

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

Show 15 quoted lines

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

Show 6 quoted lines

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

Show 7 quoted lines

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