Re: [RFC/PATCH 0/7] Rework git core for native submodules

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 5, 2013, 16:02 UTC
Message-ID: <CA+55aFxyyqkS4XyE1as2TdeARce9g9BTK=jdY+XcomNtMdrArg@mail.gmail.com>
In-Reply-To: <CALkWK0n0uKTsPv2d20ESVd5OV5yfK5V1HecGWePYU=UFw5Jkfg@mail.gmail.com>

On Thu, Apr 4, 2013 at 1:04 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 5 quoted lines

> Linus Torvalds wrote:
>> Or you could also just edit and carry a dirty .gitmodules around for
>> your personal use-case.
>
> I'm sorry, but a dirty worktree is unnecessarily painful to work with.

Bzzt. Wrong.

A dirty worktree is not only easy to work with (I do it all the time, having random test-patches in my tree that I never even intend to commit), it's a *requirement*.

One thing that git does really really well is merging. And one of the reasons why git does merging well (apart from the obvious meta-issue: it's what I care about) is that it not only has the stable information in the object database, it also has the staging information in the index, *and* it has dirty data in the working tree.

You absolutely need all three. Having an "edit" command to edit stable
data (or staging data) is broken. Trust me, I've been there, done
that, got the T-shirt and know it is wrong. The whole "stable objects"
+ "index" + "dirty worktree" is FUNDAMENTALLY the right way to work,
and it *has* to work that way for merges to work well.

The only things that we don't have "dirty data" for in the worktree is creating commits and tags, but those aren't relevant for the merging process anyway, in the sense that you never change them for merging, you create them *after* merging (and this is fundamental, and not just a git implementation issue).

So you absolutely need a dirty worktree. You need it for testing, and you need it for merging. Having a model where you don't have a in-progress entity that works as a temporary is absolutely and entirely wrong.

               Linus