Re: [PATCH] Fix file mark handling and sort side-effects in git.el

Brent Goodrick [off-list ref] writes:

My rationale for adding append function calls to the sort calls is to
leave the callers value alone since the caller needs to make use of
the list value in subsequent operations, especially for issuing
messages.

My point is that the callers that need it should take care of it
themselves, instead of forcing a copy even in cases where it's not
necessary. And the copy can most likely be avoided completely by
changing how the success message is printed.

 > If you mean using git-add-file to do an update-index on an already
 > tracked file, that's not what it's meant to do.

That would be fine in, say, Perforce where once a file is added it
stays added even if the user mades additional edits. I don't agree
that is the best approach in the case the Emacs interface to git in
git.el, since there is that "third" state where I could have added the
file, then edited it, then forgot that I had edited it and proceeded
naively to commit, only to be surprised later that the subsequent edit
to the file was not committed. 

The design of git.el is that the index is not exposed directly, it's
treated as an implementation detail. So "add" in git.el is only for
adding an untracked file, it's not for updating the index contents of an
already tracked file; that's an unnecessary operation since git.el uses
the file marks to determine what gets committed.

It does get a bit confusing if you constantly mix command-line and
git.el commands, but you are not supposed to do that, you should be able
to do everything from the git.el buffer. I'm sure hiding the index
offends the git purists, but IMHO it makes things more Emacs-ish and
easier to use, especially if you are used to things like dired or
pcl-cvs or vc-dir with other VC systems.

-- 
Alexandre Julliard
julliard@winehq.org