bug#61712: 30.0.50; Want way to generate VC log for arbitrary list of files

bug#61712: 30.0.50; Want way to generate VC log for arbitrary list of files

[Sean Whitton]

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

bug#61712: 30.0.50; Want way to generate VC log for arbitrary list of files

[Juri Linkov]

> 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.

bug#61712: 30.0.50; Want way to generate VC log for arbitrary list of files

[Sean Whitton]

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

bug#61712: 30.0.50; Want way to generate VC log for arbitrary list of files

[Eli Zaretskii]

> Resent-To: bug-gnu-emacs@gnu.org
> Cc: 61712-close@debbugs.gnu.org
> From: Sean Whitton <spwhitton@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.

bug#61712: 30.0.50; Want way to generate VC log for arbitrary list of files

[Juri Linkov]

> 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.

bug#61712: 30.0.50; Want way to generate VC log for arbitrary list of files

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Sean Whitton <spwhitton@spwhitton.name>,  61712@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.

bug#61712: 30.0.50; Want way to generate VC log for arbitrary list of files

[Filipp Gunbin]

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

>> From: Juri Linkov <juri@linkov.net>
>> Cc: Sean Whitton <spwhitton@spwhitton.name>,  61712@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.