Re: [wishlist] git submodule update --reset-hard

From: Stefan Beller <sbeller@google.com>
Date: Dec 6, 2018, 18:29 UTC
Message-ID: <CAGZ79kY8uv8zDm3f8Jb6aC-nit7OZduixyOekGYWa_xnqFqw-w@mail.gmail.com>
In-Reply-To: <20181206173554.GH4633@hopa.kiewit.dartmouth.edu>

On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko <yoh@onerussian.com> wrote:

Show 6 quoted lines

>
> Dear Git Gurus,
>
> I wondered what would be your take on my wishlist request to add
> --reset-hard option, which would be very similar to regular "update" which
> checks out necessary commit, but I want it to remain in the branch.

What if the branch differs from the sha1 recorded in the superproject?

Show 9 quoted lines

> Rationale: In DataLad we heavily rely on submodules, and we have established
> easy ways to do some manipulations across full hierarchies of them. E.g. a
> single command could introduce a good number of commits across deep hierarchy
> of submodules, e.g. while committing changes within deep submodule, while also
> doing all necessary commits in the repositories leading to that submodule so
> the entire tree of them stays in a "clean" state. The difficulty comes when
> there is a need to just "forget" some changes.  The obvious way is to e.g.
>
>    git reset --hard PREVIOUS_STATE

  git reset --hard --recurse-submodules HEAD

would do the trick

> in the top level repository.  But that leaves all the submodules now in
> the undesired state.  If I do

undesirable in the sense of still having local changes (that is what the above reset with `--recurse` would fix) or changed the branch state? (i.e. is detached but was on a branch before?)

Show 6 quoted lines

>   git submodule update --recursive
>
> I would end up in the detached HEADs within submodules.
>
> What I want is to retain current branch they are at (or may be possible
> "were in"? reflog records might have that information)

So something like

  git submodule foreach --recursive git reset --hard

You may be interested in https://public-inbox.org/git/20180927221603.148025-1-sbeller@google.com/ which introduces a switch `submodule.repoLike [ = true]`, which when set would not detach HEAD in submodules.

Can you say more about the first question above: Would you typically have situations where the submodule branch is out of sync with the superproject and how do you deal with that?

Adding another mode to `git submodule update` sounds reasonable to me, too.

Stefan