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

[Alexandre Julliard <julliard@winehq.org>]

Brent Goodrick <bgoodr@gmail.com> 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