GNU bug report logs - #61712
30.0.50; Want way to generate VC log for arbitrary list of files

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61712 in the body.
You can then email your comments to 61712 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Want way to generate VC log for arbitrary list of files
Date: Wed, 22 Feb 2023 10:25:46 -0700

Hello,

Yesterday I wanted to review changes to some documentation files in a
repository; roughly, `git log -- dgit.1 *.pod`.  I would have preferred
to have the result in a *vc-log* buffer, but I don't believe we have a
command to do this.  'C-x v !' can't do it.

If there were changes to each of the files, they would have appeared in
*vc-dir*, and I could have used the new vc-dir-mark-by-regexp, and then
vc-print-log would have done the right thing.

So, I wonder if we could have a way to insert up-to-date files into
*vc-dir*, so that they could be used to select an arbitrary VC fileset?

-- 
Sean Whitton

Message #8 received at 61712 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 61712 <at> debbugs.gnu.org
Subject: Re: bug#61712: 30.0.50; Want way to generate VC log for arbitrary
 list of files
Date: Wed, 22 Feb 2023 21:07:39 +0200

> Yesterday I wanted to review changes to some documentation files in a
> repository; roughly, `git log -- dgit.1 *.pod`.  I would have preferred
> to have the result in a *vc-log* buffer, but I don't believe we have a
> command to do this.  'C-x v !' can't do it.
>
> If there were changes to each of the files, they would have appeared in
> *vc-dir*, and I could have used the new vc-dir-mark-by-regexp, and then
> vc-print-log would have done the right thing.
>
> So, I wonder if we could have a way to insert up-to-date files into
> *vc-dir*, so that they could be used to select an arbitrary VC fileset?

It's easy to do this in the Dired buffer by marking the required files.
I'm doing this all the time since Dired supports all vc commands.

Message #13 received at 61712-close <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 61712-close <at> debbugs.gnu.org
Subject: Re: bug#61712: 30.0.50; Want way to generate VC log for arbitrary
 list of files
Date: Wed, 22 Feb 2023 15:19:39 -0700

Hello,

On Wed 22 Feb 2023 at 09:07PM +02, Juri Linkov wrote:

>> Yesterday I wanted to review changes to some documentation files in a
>> repository; roughly, `git log -- dgit.1 *.pod`.  I would have preferred
>> to have the result in a *vc-log* buffer, but I don't believe we have a
>> command to do this.  'C-x v !' can't do it.
>>
>> If there were changes to each of the files, they would have appeared in
>> *vc-dir*, and I could have used the new vc-dir-mark-by-regexp, and then
>> vc-print-log would have done the right thing.
>>
>> So, I wonder if we could have a way to insert up-to-date files into
>> *vc-dir*, so that they could be used to select an arbitrary VC fileset?
>
> It's easy to do this in the Dired buffer by marking the required files.
> I'm doing this all the time since Dired supports all vc commands.

Oh, I didn't know dired could do this.  My apologies.

-- 
Sean Whitton

Message #16 received at 61712 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Juri Linkov <juri <at> linkov.net>
Cc: 61712 <at> debbugs.gnu.org
Subject: Re: bug#61712: 30.0.50;
 Want way to generate VC log for arbitrary list of files
Date: Thu, 23 Feb 2023 15:00:42 +0200

> Resent-To: bug-gnu-emacs <at> gnu.org
> Cc: 61712-close <at> debbugs.gnu.org
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Wed, 22 Feb 2023 15:19:39 -0700
> 
> On Wed 22 Feb 2023 at 09:07PM +02, Juri Linkov wrote:
> 
> >> Yesterday I wanted to review changes to some documentation files in a
> >> repository; roughly, `git log -- dgit.1 *.pod`.  I would have preferred
> >> to have the result in a *vc-log* buffer, but I don't believe we have a
> >> command to do this.  'C-x v !' can't do it.
> >>
> >> If there were changes to each of the files, they would have appeared in
> >> *vc-dir*, and I could have used the new vc-dir-mark-by-regexp, and then
> >> vc-print-log would have done the right thing.
> >>
> >> So, I wonder if we could have a way to insert up-to-date files into
> >> *vc-dir*, so that they could be used to select an arbitrary VC fileset?
> >
> > It's easy to do this in the Dired buffer by marking the required files.
> > I'm doing this all the time since Dired supports all vc commands.
> 
> Oh, I didn't know dired could do this.  My apologies.

How could you know, when this important feature was almost completely
undocumented?  Apart of a single NEWS entry, which is also quite
misleading in what it does NOT say, there was no mention of this
anywhere in our manuals, until now.

We should be able to do better with documenting such significant user
features.

Btw, shouldn't we show the VC information in the mode line of a Dired
buffer that displays a directory under VCS?  Since all VC commands now
work in such a buffer, this is very similar to showing a file under
VCS, so the omission doesn't sound right to me.

Message #19 received at 61712 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61712 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#61712: 30.0.50; Want way to generate VC log for arbitrary
 list of files
Date: Thu, 23 Feb 2023 19:59:05 +0200

> How could you know, when this important feature was almost completely
> undocumented?  Apart of a single NEWS entry, which is also quite
> misleading in what it does NOT say, there was no mention of this
> anywhere in our manuals, until now.

Adding text for such a minor feature as using Dired for VC commands
to the top node "Version Control" makes it too long.
Even a major feature of using VC Directory Mode is described
much later in the manual.  So better would be to explain Dired support
somewhere near the node "VC Directory Mode".

> Btw, shouldn't we show the VC information in the mode line of a Dired
> buffer that displays a directory under VCS?  Since all VC commands now
> work in such a buffer, this is very similar to showing a file under
> VCS, so the omission doesn't sound right to me.

I never noticed this omission, but adding the same mode-line string
as in regular file buffers makes sense.

Message #22 received at 61712 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 61712 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#61712: 30.0.50; Want way to generate VC log for arbitrary
 list of files
Date: Thu, 23 Feb 2023 20:12:16 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Sean Whitton <spwhitton <at> spwhitton.name>,  61712 <at> debbugs.gnu.org
> Date: Thu, 23 Feb 2023 19:59:05 +0200
> 
> > How could you know, when this important feature was almost completely
> > undocumented?  Apart of a single NEWS entry, which is also quite
> > misleading in what it does NOT say, there was no mention of this
> > anywhere in our manuals, until now.
> 
> Adding text for such a minor feature as using Dired for VC commands
> to the top node "Version Control" makes it too long.

It isn't a minor feature, IMO.  It enables a lot of workflows that
previously were hard or impossible.  The first example is the question
which started this discussion.

> Even a major feature of using VC Directory Mode is described
> much later in the manual.  So better would be to explain Dired support
> somewhere near the node "VC Directory Mode".

I could argue that the possibility of using VC features from Dired is
maybe even more important than vc-dir.

Anyway, the VC chapter needs to be rewritten, I know it for a long
time now.  But I don't have time for that, not now anyway.  I just
spent half of my day chasing all the rabbit holes in VC and fixing the
doc strings that I found unclear or inaccurate, and their manual
descriptions that were either incomplete or outdated.  I cannot afford
spending more time on this, sorry.  Unless someone steps forward and
does the job, we'll have to live with what we have now, which IMNSHO
is not too bad.

> > Btw, shouldn't we show the VC information in the mode line of a Dired
> > buffer that displays a directory under VCS?  Since all VC commands now
> > work in such a buffer, this is very similar to showing a file under
> > VCS, so the omission doesn't sound right to me.
> 
> I never noticed this omission, but adding the same mode-line string
> as in regular file buffers makes sense.

Patches to that effect are welcome.  Without that, the text I wrote
about VC being enabled automatically in Dired buffers might sound
misleading to someone.

Thanks.

Message #25 received at 61712 <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: spwhitton <at> spwhitton.name, 61712 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#61712: 30.0.50; Want way to generate VC log for arbitrary
 list of files
Date: Thu, 23 Feb 2023 23:15:12 +0300

On 23/02/2023 20:12 +0200, Eli Zaretskii wrote:

>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: Sean Whitton <spwhitton <at> spwhitton.name>,  61712 <at> debbugs.gnu.org
>> Date: Thu, 23 Feb 2023 19:59:05 +0200
>> 
>> > How could you know, when this important feature was almost completely
>> > undocumented?  Apart of a single NEWS entry, which is also quite
>> > misleading in what it does NOT say, there was no mention of this
>> > anywhere in our manuals, until now.
>> 
>> Adding text for such a minor feature as using Dired for VC commands
>> to the top node "Version Control" makes it too long.
>
> It isn't a minor feature, IMO.  It enables a lot of workflows that
> previously were hard or impossible.  The first example is the question
> which started this discussion.

Oh yes, and it isn't (wasn't) easily discoverable.  Thanks for adding
that to manual.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.