Re: VC mode and git

[Sergey Organov]

Alan Mackenzie <address@hidden> writes:

> Hello, Eli.
>
> On Wed, Mar 25, 2015 at 08:03:17PM +0200, Eli Zaretskii wrote:
>> > From: Stefan Monnier <address@hidden>
>> > Date: Wed, 25 Mar 2015 11:04:51 -0400
>
>> > I tend not to use the index very heavily (I'm still a fairly young Git
>> > user, evidently), so I don't suffer from it too much, but it's clearly
>> > wrong (an obvious problem is when the file is modified in the index and
>> > this modification is undone in the actual file
>
>> That's because you are not radical enough in not-using the index.  I
>> never get to the situation where a file is modified in the index.  One
>> problem less.
>
>> (Of course, now I will be pounced upon by all the people who were
>> brainwashed to think the index is a good idea.  Please don't bother.)
>
> The index (stupid name) is an extra layer of complexity.  Even the git
> maintainers half-admit it's not (always) a good thing by allowing "git
> commit -a".
>
> I'm mystified as to what the git index is for.  What's its motivation,
> what's it used for, what does it gain me in exchange for the extra
> complexity?  Does anybody have a link to a justification?  I'm genuinely
> curious about this.

Did you ever mark a few files to commit from many, in either pcl-cvs or
vc-dir? That's one thing that git allows you to do using its
command-line interface and index, only better. You mark changes to
commit by putting them into the index (that is now officially called
"staging area"), and you can even do this per-diff-chunk. Magit supports
this, by not trying to hide staging area (it does ask to commit
everything when nothing is staged, but anyway.)

[Side note]: now comes reasonable question: how about testing exact
to-be-committed state before commit? That's what 'git stash
--keep-index' provides (see "Testing partial commits" in the git-stash
manual.) And yes, magit supports this as well.

There are other uses of the staging area, notably to save multiple trees
on merges and getting diffs w.r.t both sides of the merge, that helps in
not-trivial conflicts resolution, but the use-case above should be
rather familiar to many.

-- Sergey.

P.S. Haters will hate, anyway.