Log for specific files or directories #594

oscarfv opened this Issue Mar 19, 2013 · 7 comments


None yet
4 participants

oscarfv commented Mar 19, 2013

Currently there is no easy way on magit for restricting the Log to the commits that touch a given file or directory. The syntax on the command line is

git log -- file-or-directory ...

The attached diff implements this feature as a new subcommand under "log". Using an Arg is not correct because the list of files and directories must be at the end of the command, and the keygroups infrastructure does not provide a method for that.

    Modified   magit-key-mode.el
diff --git a/magit-key-mode.el b/magit-key-mode.el
index dd69988..e16e7bc 100644
--- a/magit-key-mode.el
+++ b/magit-key-mode.el
@@ -27,6 +27,7 @@
       ("l" "Short" magit-log)
       ("L" "Long" magit-log-long)
       ("h" "Reflog" magit-reflog)
+      ("p" "Paths" magit-log-for-paths)
       ("rl" "Ranged short" magit-log-ranged)
       ("rL" "Ranged long" magit-log-long-ranged)
       ("rh" "Ranged reflog" magit-reflog-ranged))
    Modified   magit.el
diff --git a/magit.el b/magit.el
index ad5569d..11d9f5d 100644
--- a/magit.el
+++ b/magit.el
@@ -2397,6 +2397,7 @@ magit-topgit and magit-svn"
      ["Short Log" magit-log t]
      ["Long Log" magit-log-long t]
+     ["Files or directories" magit-log-for-paths t]
      ["Reflog" magit-reflog t]
      ["Extended..." magit-key-mode-popup-logging t])
@@ -5229,6 +5230,11 @@ With a non numeric prefix ARG, show all entries"
     (magit-mode-init topdir 'magit-log-mode #'magit-refresh-log-buffer range
                      'long args)))

+(magit-define-command log-for-paths ()
+  (interactive)
+  (let ((paths (read-string "Files or directories: ")))
+    (apply 'magit-log nil "--" (split-string paths))))
 ;;; Reflog

 (defvar magit-reflog-head nil

mbunkus commented Apr 26, 2013

It would be really nice to use the usual functions for reading file and directory names so you can use the same functions you've grown accustomed to over the years (for me: isearch with find-file). Tab completion, partial matching, etc. Do that multiple times, collect results in a list and you don't even have to split a string.

oscarfv commented Apr 26, 2013

AFAIK, those functions accept only one file or directory, while the proposed feature supports multiple files and/or directories.


mbunkus commented Apr 26, 2013

True. Which is why I said something vague about calling those functions "multiple times" (yeah, you do need some way for the user to signal that he's done adding files). Still, using a bare-bones read-string completely defeats what makes Emacs so great to use.

tarsius was assigned May 29, 2013


tarsius commented Jul 6, 2013

Maybe the built-in library crm can be used for this. It does "read multiple strings with completion".

oscarfv commented Jul 6, 2013

crm, apart of being awkward (IMHO), is directed to do completion on pre-computed lists of candidates. That's not the same as completing files/directories (possibly deep on the file tree.) And it ignores the completion system preferred by the user (ido-mode, for instance)

I guess that asking for the files on a loop, using the empty string as termination signal, would work well enough, although it is not obvious how to enter an empty string on some completion methods (ido-mode), so even C-g could be considered for this.


afrepues commented Jul 8, 2013

There is also the problem of entering the wrong path and being able to fix that, and removing ones already entered.

One solution that could be very nice IMHO, is to have a mode similar to the one used for interactive rebase, but that adds a command to add a path using autocompletion.


tarsius commented Dec 5, 2013

I am closing this in favour of #876. Once the "better rev reading" mentioned using that to improve the various magit-log* commands is the next logical steps. Doing the latter also requires some changes to the "popup" framework, which I am currently working on and expect to merge soon.

tarsius closed this Dec 5, 2013

tarsius removed the 11 popup label May 29, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment