git show

git show

[Lars Ingebrigtsen]

The only vc thing I find myself leaving Emacs for to do is "git show
<id>" (when people refer to a specific id in a bug report, for
instance).  I've looked through the vc-dir command set, and I can't find
anything like that.

Is that command missing from vc-dir?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: git show

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 01 Nov 2019 14:51:28 +0100
> 
> The only vc thing I find myself leaving Emacs for to do is "git show
> <id>" (when people refer to a specific id in a bug report, for
> instance).  I've looked through the vc-dir command set, and I can't find
> anything like that.
> 
> Is that command missing from vc-dir?

Type "C-x v L", then RET on a line for the commit you are interested
in.  If you want to see the diffs, press D after that.

Re: git show

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Type "C-x v L", then RET on a line for the commit you are interested
> in.  If you want to see the diffs, press D after that.

It's not very convenient -- if the commit is old, I have to hit either
"Show 2X entries" or "Show unlimited entries", which are slow.

Which means that it's faster to just go to a terminal and say "git
show".

But I take this to mean that there's no command like this implemented
already?  If so, I can take a whack at implementing it.  I'm guessing
that most SCMs have a command to show a specific commit based on an ID.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: git show

[Dmitry Gutov]

On 01.11.2019 16:00, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 01.11.2019 15:51, Lars Ingebrigtsen wrote:
>>> The only vc thing I find myself leaving Emacs for to do is "git show
>>> <id>" (when people refer to a specific id in a bug report, for
>>> instance).  I've looked through the vc-dir command set, and I can't find
>>> anything like that.
>>
>> vc-describe-revision, maybe?
> 
> Grepping through the tree shows no such function...

Just proposing a name. :)

>>> Is that command missing from vc-dir?
>>
>> You probably mean from VC.
> 
> I'd expect to find such a command in the vc-dir buffer.

Err, why? To describe the HEAD revision?

I would maybe expect it to work in the log buffers, but also anywhere a 
revision can be mentioned. Like email.

Re: git show

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>>> vc-describe-revision, maybe?
>> Grepping through the tree shows no such function...
>
> Just proposing a name. :)

Oh, OK.  :-)

>>>> Is that command missing from vc-dir?
>>>
>>> You probably mean from VC.
>> I'd expect to find such a command in the vc-dir buffer.
>
> Err, why? To describe the HEAD revision?

It would just prompt for an ID. 

> I would maybe expect it to work in the log buffers, but also anywhere
> a revision can be mentioned. Like email.

Outside of vc-related buffers (like email) it'd have to prompt for a SCM
directory, so perhaps that'd be a different command.  (That would call
the former command.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: git show

[Stefan Monnier]

> It's not very convenient -- if the commit is old, I have to hit either
> "Show 2X entries" or "Show unlimited entries", which are slow.

It's worse: if the commit is not in the current branch it won't be
listed at all, and `C-x v L` doesn't let you show the log corresponding
to another branch.

If `C-x v l` accepted a C-u to specify the "revision" for which to show
the log, then it would solve both problems: you could get the log
of other branches and you could see the commit message and the diff of
a specific REVision with:

    C-u C-x v l <REV> RET
    followed by hitting `D` on the first element to see the diff


-- Stefan

Re: git show

[Steinar Bang]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca>:

>> It's not very convenient -- if the commit is old, I have to hit either
>> "Show 2X entries" or "Show unlimited entries", which are slow.

> It's worse: if the commit is not in the current branch it won't be
> listed at all, and `C-x v L` doesn't let you show the log corresponding
> to another branch.

And don't forget this, which was never really fixed:
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756

Ie. history is not tracked across moves/renames.

Would it be OK to reopen this bug?  Alternatively create a new one?
(whatever is best...?)

Re: git show

[Dmitry Gutov]

On 02.11.2019 10:01, Steinar Bang wrote:

>> It's worse: if the commit is not in the current branch it won't be
>> listed at all, and `C-x v L` doesn't let you show the log corresponding
>> to another branch.
> 
> And don't forget this, which was never really fixed:
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756

It seems unrelated, but.

> Ie. history is not tracked across moves/renames.
> 
> Would it be OK to reopen this bug?  Alternatively create a new one?
> (whatever is best...?)

I think it's open, isn't it? The last comment proposes a patch, but with 
some known problems. Help welcome solving those.

Re: git show

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It's worse: if the commit is not in the current branch it won't be
> listed at all, and `C-x v L` doesn't let you show the log corresponding
> to another branch.
>
> If `C-x v l` accepted a C-u to specify the "revision" for which to show
> the log, then it would solve both problems: you could get the log
> of other branches and you could see the commit message and the diff of
> a specific REVision with:
>
>     C-u C-x v l <REV> RET
>     followed by hitting `D` on the first element to see the diff

That sounds like a nice command indeed, but I still just want a
convenient way to display a single commit when somebody says "fixed in
<id>" in an email.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: git show

[Stefan Monnier]

> That sounds like a nice command indeed, but I still just want a
> convenient way to display a single commit when somebody says "fixed in
> <id>" in an email.  :-)

Au diable l'avarice: let's have both!


        Stefan

Re: git show

[Juri Linkov]

> The only vc thing I find myself leaving Emacs for to do is "git show
> <id>" (when people refer to a specific id in a bug report, for
> instance).  I've looked through the vc-dir command set, and I can't find
> anything like that.
>
> Is that command missing from vc-dir?

Not missing, it's implemented already by

  C-u M-x vc-log-search RET git log -1 <id> RET

Re: git show

[Juri Linkov]

> And don't forget this, which was never really fixed:
>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
>
> Ie. history is not tracked across moves/renames.
>
> Would it be OK to reopen this bug?  Alternatively create a new one?
> (whatever is best...?)

I don't know why this bug is still not closed - a new option
vc-git-print-log-follow was added long ago.

dired-vc-rename (was: git show)

[Juri Linkov]

> Ie. history is not tracked across moves/renames.

BTW, I wonder how in Dired everyone moves/renames
files in a directory under version control?

When using simply R in Dired to move vc files,
this messes everything up: vc-dired thinks that
the file with an old name is removed,
and a new file is created unregistered.

I'm using such patch, and it works well.
Should this be installed?

diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index b1521ecf01..13a2d8cd6b 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1635,11 +1635,24 @@ dired-copy-file-recursive
 	       dired-create-files-failures)
 	 (dired-log "Can't set date on %s:\n%s\n" from err))))))
 
+(defcustom dired-vc-rename-file nil
+  "Whether Dired should register file renaming in underlying vc.
+If nil, use default `rename-file'.
+If non-nil and the renamed files are under version control,
+rename them using `vc-rename-file'."
+  :type '(choice (const :tag "Use rename-file" nil)
+		 (const :tag "Use vc-rename-file" t))
+  :group 'dired
+  :version "27.1")
+
 ;;;###autoload
 (defun dired-rename-file (file newname ok-if-already-exists)
   (dired-handle-overwrite newname)
   (dired-maybe-create-dirs (file-name-directory newname))
-  (rename-file file newname ok-if-already-exists) ; error is caught in -create-files
+  (if (and dired-vc-rename-file (vc-backend file))
+      (vc-rename-file file newname)
+    ;; error is caught in -create-files
+    (rename-file file newname ok-if-already-exists))
   ;; Silently rename the visited file of any buffer visiting this file.
   (and (get-file-buffer file)
        (with-current-buffer (get-file-buffer file)

Re: git show

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sat, 02 Nov 2019 20:42:18 +0200
> Cc: emacs-devel@gnu.org
> 
> > The only vc thing I find myself leaving Emacs for to do is "git show
> > <id>" (when people refer to a specific id in a bug report, for
> > instance).  I've looked through the vc-dir command set, and I can't find
> > anything like that.
> >
> > Is that command missing from vc-dir?
> 
> Not missing, it's implemented already by
> 
>   C-u M-x vc-log-search RET git log -1 <id> RET

Definitely missing from the manual, though ;-)

Re: git show

[Stephen Berman]

On Sat, 02 Nov 2019 20:42:18 +0200 Juri Linkov <juri@linkov.net> wrote:

>> The only vc thing I find myself leaving Emacs for to do is "git show
>> <id>" (when people refer to a specific id in a bug report, for
>> instance).  I've looked through the vc-dir command set, and I can't find
>> anything like that.
>>
>> Is that command missing from vc-dir?
>
> Not missing, it's implemented already by
>
>   C-u M-x vc-log-search RET git log -1 <id> RET

I didn't know about this, but it's not as convenient as being able to
show the commit message (or the whole commit) of the id at point (I
wrote such a command for myself for my local Emacs branches, but I'm not
familiar enough with the internals of VC to integrate it with VC).

Steve Berman

Re: git show

[Juri Linkov]

>>> The only vc thing I find myself leaving Emacs for to do is "git show
>>> <id>" (when people refer to a specific id in a bug report, for
>>> instance).  I've looked through the vc-dir command set, and I can't find
>>> anything like that.
>>>
>>> Is that command missing from vc-dir?
>>
>> Not missing, it's implemented already by
>>
>>   C-u M-x vc-log-search RET git log -1 <id> RET
>
> I didn't know about this, but it's not as convenient as being able to
> show the commit message (or the whole commit) of the id at point (I
> wrote such a command for myself for my local Emacs branches, but I'm not
> familiar enough with the internals of VC to integrate it with VC).

Not convenient, indeed.  So maybe a dedicated command is still needed
after all, unless it's not possible to reuse C-x v l with a prefix key.

Re: git show

[Juri Linkov]

>>> Not missing, it's implemented already by
>>>
>>>   C-u M-x vc-log-search RET git log -1 <id> RET
>>
>> I didn't know about this, but it's not as convenient as being able to
>> show the commit message (or the whole commit) of the id at point (I
>> wrote such a command for myself for my local Emacs branches, but I'm not
>> familiar enough with the internals of VC to integrate it with VC).
>
> Not convenient, indeed.  So maybe a dedicated command is still needed
> after all, unless it's not possible to reuse C-x v l with a prefix key.

Oops, logic error: “unless not possible” ≡ “if possible”.
That means to implement both.

Re: git show

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I don't know why this bug is still not closed - a new option
> vc-git-print-log-follow was added long ago.

I've now closed the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: dired-vc-rename

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> BTW, I wonder how in Dired everyone moves/renames
> files in a directory under version control?
>
> When using simply R in Dired to move vc files,
> this messes everything up: vc-dired thinks that
> the file with an old name is removed,
> and a new file is created unregistered.
>
> I'm using such patch, and it works well.
> Should this be installed?

I think that change looks quite useful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: git show

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That sounds like a nice command indeed, but I still just want a
>> convenient way to display a single commit when somebody says "fixed in
>> <id>" in an email.  :-)
>
> Au diable l'avarice: let's have both!

:-)

It seems like the general feeling is that this would be useful to have
(even if there are some commands that are adjacent to it already, but
not as convenient).

So I'll just open a bug report to remind myself to implement it (or if
somebody else wants to, please go ahead).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: git show

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:
> Juri Linkov <juri@linkov.net> writes:
>> I don't know why this bug is still not closed - a new option
>> vc-git-print-log-follow was added long ago.

> I've now closed the bug report.

Dmitry had an objection:
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756#73

Re: git show

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:
>>>>> Lars Ingebrigtsen <larsi@gnus.org>:
>> Juri Linkov <juri@linkov.net> writes:
>>> I don't know why this bug is still not closed - a new option
>>> vc-git-print-log-follow was added long ago.

>> I've now closed the bug report.

> Dmitry had an objection:
>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756#73

Just tried it and I can confirm: with vc-git-print-log-follow I can see
the entire log history, but 'd' on a hash to see the diff between the
current version and the previous doesn't work.

And that limits the usefulness somewhat.

Re: git show

[Steinar Bang]

>>>>> Juri Linkov <juri@linkov.net>:

> I don't know why this bug is still not closed - a new option
> vc-git-print-log-follow was added long ago.

Out of curiosity: why wasn't the default set to t?
(I can't think of any git use case where one doesn't want history
follow...?) 

Re: git show

[Óscar Fuentes]

Steinar Bang <sb@dod.no> writes:

>>>>>> Juri Linkov <juri@linkov.net>:
>
>> I don't know why this bug is still not closed - a new option
>> vc-git-print-log-follow was added long ago.
>
> Out of curiosity: why wasn't the default set to t?
> (I can't think of any git use case where one doesn't want history
> follow...?) 

IIRC because performance concerns.