Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out

From: Eran Tromer <git2eran@tromer.org>
Date: Aug 8, 2007, 01:41 UTC
Message-ID: <46B91F4E.8050008@tromer.org>
In-Reply-To: <20070807085149.GH999MdfPADPa@greensroom.kotnet.org>

On 2007-08-07 04:51, Sven Verdoolaege wrote:

> Surely this is a lot worse than occasionally committing something you
> didn't plan to commit, and only if you are performing a known "dangerous"
> operation.
>

Are you saying that $ git reset --hard HEAD && vi foo && git commit -a is a "known dangerous" operation that can record corrupted content even though you didn't touch it? This is very bad news indeed! I don't see any such warnings in the documentation.

So, when I'm sure all the edits I did in the work tree are fine, how *do* I safely make a commit without manually inspecting the changed files list, or manually listing the changed files for "git add", or manually running "git submodule update", or manually checking whether there happens to be some submodules in this project, some other such cumbersome measure?

> You may have done several supermodule checkouts since you last changed
> the submodule.

True, that approach won't work. I can imagine some logic to conditionally update ORIG_HEAD, but it gets messy and fragile. Looks like brokenness is just inevitable when you let the state get stale and then merrily read it out as if it's fresh.

So.... Maybe we can tackle this head-on? Let index entries be explicitly marked as "adrift", meaning we just don't touch the work tree for these entries -- neither reads nor writes. It's used when the piece of content, say a submodule, is allowed to drift arbitrarily in the work tree in a way that doesn't represent meaningful edits that should be reflected in commits, diffs, etc.

For example:
- "git checkout" sets the "adrift" flag on all (modified?) submodules
- "git submodule update" undrifts ("moores?") the submodules
- "git commit -a" skips files that are adrift, and likewise "git add .",
  "git diff" etc. (perhaps with some warning?)
- "git add <path>" undrifts <path> and proceeds as usual
- "git status" reports drifting files as such and doesn't bother to
  check them in the work tree
- When merging into the work tree, drifting files are left as such

And why stop at submodules? If there's a large blob you don't want to check out, just "git drift <path>" it. To set whole *directories* adrift, we can piggybacking on the empty-directory support (i.e., add a directory entry to the index and set it adrift). So this could be the basis of partial-checkout support.

Does this sound reasonable?

  Eran