Brent Goodrick <bgoodr@xxxxxxxxx> 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@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
