git.el: Make it easy to add unmerged files
PATCH 1/1 git.el: Make it easy to add unmerged files
(Resending as I managed to mangle the previous patch despite trying not to...)
It is nice and easy to git-add ignored and unknown files in a git-status buffer. Make it equally easy to add unmerged files which is a common use case.
--- contrib/emacs/git.el | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
contrib/emacs/git.el +1 -1
@@ -1046,7 +1046,7 @@ The FILES list must be sorted." (defun git-add-file () "Add marked file(s) to the index cache." (interactive) - (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored)))) + (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored 'unmerged)))) ;; FIXME: add support for directories (unless files (push (file-relative-name (read-file-name "File to add: " nil nil t)) files))
Signature · 1 line
1.6.2.5
Quoted 5 lines · Martin Nordholts
(Resending as I managed to mangle the previous patch despite trying not to...)
It is nice and easy to git-add ignored and unknown files in a git-status buffer. Make it equally easy to add unmerged files which is a common use case.
That's not quite what adding a file means in git.el, unmerged files are considered added already, and marking them resolved is done through the git-resolve-file command. Of course that was implemented before git overloaded the meaning of git-add to mean git-update-index, so maybe we should follow the trend and use git-add-file for all index updates. In that case git-resolve-file should probably be removed.
Signature · 2 lines
Alexandre Julliard [email protected]
Quoted 8 lines · Alexandre Julliard
Quoted 5 lines · Martin Nordholts
(Resending as I managed to mangle the previous patch despite trying not to...)
It is nice and easy to git-add ignored and unknown files in a git-status buffer. Make it equally easy to add unmerged files which is a common use case.
Quoted 6 lines
That's not quite what adding a file means in git.el, unmerged files are considered added already, and marking them resolved is done through the git-resolve-file command. Of course that was implemented before git overloaded the meaning of git-add to mean git-update-index, so maybe we should follow the trend and use git-add-file for all index updates. In that case git-resolve-file should probably be removed.
Since git instructs the user to use git-add for marking unmerged files as resolved ("After resolving the conflicts, mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.") and doesn't even mention git-update-index, I think we should change git.el accordingly.
But why do we need to also remove and disable git-resolve-file from git.el? It doesn't hurt to keep that function and the keybinding, does it?
/ Martin
Quoted 22 lines · Martin Nordholts
Quoted 8 lines · Alexandre Julliard
Quoted 5 lines · Martin Nordholts
(Resending as I managed to mangle the previous patch despite trying not to...)
It is nice and easy to git-add ignored and unknown files in a git-status buffer. Make it equally easy to add unmerged files which is a common use case.
Quoted 6 lines
That's not quite what adding a file means in git.el, unmerged files are considered added already, and marking them resolved is done through the git-resolve-file command. Of course that was implemented before git overloaded the meaning of git-add to mean git-update-index, so maybe we should follow the trend and use git-add-file for all index updates. In that case git-resolve-file should probably be removed.
Since git instructs the user to use git-add for marking unmerged files as resolved ("After resolving the conflicts, mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.") and doesn't even mention git-update-index, I think we should change git.el accordingly.
Quoted 3 lines
But why do we need to also remove and disable git-resolve-file from git.el? It doesn't hurt to keep that function and the keybinding, does it?
It doesn't hurt much, but having two keybindings for the same thing is a bit wasteful since there aren't that many simple bindings available. If we remove it, it opens the door to later reusing the 'R' key for something else (a git-rename function would be the obvious choice).
Signature · 2 lines
Alexandre Julliard [email protected]