A vc wish: vc-timemachine

A vc wish: vc-timemachine

[John Yates]

Given the recent up-tick in vc development I would love dearly a vc
equivalent of:
https://github.com/emacsmirror/git-timemachine/blob/master/git-timemachine.el

Re: A vc wish: vc-timemachine

[Manuel Uberti]

On 15/10/22 22:07, John Yates wrote:
> Given the recent up-tick in vc development I would love dearly a vc
> equivalent of:
> https://github.com/emacsmirror/git-timemachine/blob/master/git-timemachine.el

What a coincidence! This morning I wrote to Peter Stiernström, the 
author of git-timemachine, asking if there is any interest in adding it 
to GNU ELPA or Non-GNU ELPA.

-- 
Manuel Uberti
https://manueluberti.eu

Re: A vc wish: vc-timemachine

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Sat, 15 Oct 2022 16:07:58 -0400
> 
> Given the recent up-tick in vc development I would love dearly a vc
> equivalent of:
> https://github.com/emacsmirror/git-timemachine/blob/master/git-timemachine.el

Doesn't vc-region-history (C-x v h) fit the bill?

[vc-region-history in HG] (was: A vc wish: vc-timemachine)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: John Yates <john@yates-sheets.org>
>> Date: Sat, 15 Oct 2022 16:07:58 -0400
>> 
>> Given the recent up-tick in vc development I would love dearly a vc
>> equivalent of:
>> https://github.com/emacsmirror/git-timemachine/blob/master/git-timemachine.el

> Doesn't vc-region-history (C-x v h) fit the bill?

I just realized that vc-region-history does not work in hg, in the sense
that it just shows the changes in the whole buffer, while it works for
git. I looked briefly at the code and could not find any special calls
to git there.

Any idea what could be the reason (not that there are very many HG users
on this list...)?


-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: [vc-region-history in HG]

[Daniel Martín]

Uwe Brauer <oub@mat.ucm.es> writes:

>
> I just realized that vc-region-history does not work in hg, in the sense
> that it just shows the changes in the whole buffer, while it works for
> git. I looked briefly at the code and could not find any special calls
> to git there.
>
> Any idea what could be the reason (not that there are very many HG users
> on this list...)?

In a git repository, the function delegates to the backend function
vc-git-region-history, which calls "git log -L" (requires git 1.8.4+).

If this cheatsheet is accurate,
https://hyperpolyglot.org/version-control, there is no direct Mercurial
alternative to git log -L ("commits which touched lines").

But perhaps we can implement the feature for Mercurial in some other
way.

Re: [vc-region-history in HG]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

>>> "DM" == Daniel Martín <mardani29@yahoo.es> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>> 
>> I just realized that vc-region-history does not work in hg, in the sense
>> that it just shows the changes in the whole buffer, while it works for
>> git. I looked briefly at the code and could not find any special calls
>> to git there.
>> 
>> Any idea what could be the reason (not that there are very many HG users
>> on this list...)?

> In a git repository, the function delegates to the backend function
> vc-git-region-history, which calls "git log -L" (requires git 1.8.4+).

> If this cheatsheet is accurate,
> https://hyperpolyglot.org/version-control, there is no direct Mercurial
> alternative to git log -L ("commits which touched lines").

Thanks!
Hm, I see, what is the difference then to annotate?

BTW I just found in vc-hg-region-history-mode



(define-derived-mode vc-hg-region-history-mode
    vc-hg-log-view-mode "Hg-Region-History"
  "Major mode to browse Hg's \"log -p\" output."

But this seems to be a different beast

> But perhaps we can implement the feature for Mercurial in some other
> way.

I try to contact some mercurial guru.


-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

[It works] (was: [vc-region-history in HG])

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]





> Thanks!
> Hm, I see, what is the difference then to annotate?

Ok, I tested it again, starting from scratch, I can confirm that it
works, but it displays also the diff as in


,----
| changeset:   1:bc59feefdcfb
| user:        Uwe Brauer <oub@mat.ucm.es>
| date:        Sun Oct 16 17:38:59 2022 +0200
| summary:     second commit subsection
| 
| diff --git a/new.org b/new.org
| --- a/new.org
| +++ b/new.org
| @@ -1,3 +1,8 @@
|  * Introduction
|  
|  A bit of more stuff
| +
| +** New subsection
| +
| +We add a new subsection
| +
| 
| changeset:   0:1302ad3dd1fd
| user:        Uwe Brauer <oub@mat.ucm.es>
| date:        Sun Oct 16 17:38:38 2022 +0200
| summary:     First commit section
| 
| diff --git a/new.org b/new.org
| new file mode 100755
| --- /dev/null
| +++ b/new.org
| @@ -0,0 +1,3 @@
| +* Introduction
| +
| +A bit of more stuff
`----


so the hg command line command would be

hg log --follow --patch -L new.org,1:9 

While sometimes a 

hg log --follow  -L new.org,1:9 

Might be more appropriate.

Any change to disable optionally the --patch option?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

[there is hg log -L] (was: [vc-region-history in HG])

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

>>> "DM" == Daniel Martín <mardani29@yahoo.es> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>> 
>> I just realized that vc-region-history does not work in hg, in the sense
>> that it just shows the changes in the whole buffer, while it works for
>> git. I looked briefly at the code and could not find any special calls
>> to git there.
>> 
>> Any idea what could be the reason (not that there are very many HG users
>> on this list...)?

> In a git repository, the function delegates to the backend function
> vc-git-region-history, which calls "git log -L" (requires git 1.8.4+).

> If this cheatsheet is accurate,
> https://hyperpolyglot.org/version-control, there is no direct Mercurial
> alternative to git log -L ("commits which touched lines").


I just learned, that at least for mercurial version => 5.2

 hg help log --verbose 

Tells me


-L --line-range FILE,RANGE [+] follow line range of specified file
                                (EXPERIMENTAL)

So it should work, shouldn't it?

Regards




-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: A vc wish: vc-timemachine

[John Yates]

On Sun, Oct 16, 2022 at 1:30 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Doesn't vc-region-history (C-x v h) fit the bill?

No.  vc-region-history's presents a concatenation of diffs.

git-timemachine is more akin to a non-existent
vc-revision-same-window.  It is a minor mode applied to a buffer
visiting a version controlled file.  It renders that buffer readonly
and then allows one to 'scroll' backward and forward over that file's
linear history, always showing a fully reconstructed revision, reusing
a single buffer.

My druthers would be for a vc-browse command that pops a new buffer
containing the most recently committed revision of the subject file.
It would support operations similar to git-timemachine:
* vc-browse-show-previous
* vc-browse-show-next

git-timemachine style refinements could include:
* vc-browse-show-commit
* vc-browse-show-annotation
* vc-browsw-goto-earlier-commit   (regex search)

Re: A vc wish: vc-timemachine

[Dmitry Gutov]

On 16.10.2022 14:49, John Yates wrote:
> My druthers would be for a vc-browse command that pops a new buffer
> containing the most recently committed revision of the subject file.
> It would support operations similar to git-timemachine:
> * vc-browse-show-previous
> * vc-browse-show-next
> 
> git-timemachine style refinements could include:
> * vc-browse-show-commit
> * vc-browse-show-annotation
> * vc-browsw-goto-earlier-commit   (regex search)

Is vc-annotate missing much of these features?

The navigation is there (n, p, d, l, a), the panel is togglable. I 
suppose we could tune the colors and/or the absence of font-lock.

Re: A vc wish: vc-timemachine

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

I grant you that these capabilities are present in a vc-annotate buffer.

That said, vc-annotate is a jarring presentation.  As I browse through
different revisions I want the major mode to remain that of the original
(non-annotated) file.  I want syntax-based highlighting, lsp support, etc.

On Sun, Oct 16, 2022 at 6:29 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 16.10.2022 14:49, John Yates wrote:
> > My druthers would be for a vc-browse command that pops a new buffer
> > containing the most recently committed revision of the subject file.
> > It would support operations similar to git-timemachine:
> > * vc-browse-show-previous
> > * vc-browse-show-next
> >
> > git-timemachine style refinements could include:
> > * vc-browse-show-commit
> > * vc-browse-show-annotation
> > * vc-browsw-goto-earlier-commit   (regex search)
>
> Is vc-annotate missing much of these features?
>
> The navigation is there (n, p, d, l, a), the panel is togglable. I
> suppose we could tune the colors and/or the absence of font-lock.
>


-- 
John Yates
505 Tremont St, #803
Boston, MA 02116

[-- Attachment #2: Type: text/html, Size: 1852 bytes --]

Re: A vc wish: vc-timemachine

[Juri Linkov]

> That said, vc-annotate is a jarring presentation.  As I browse through
> different revisions I want the major mode to remain that of the original
> (non-annotated) file.  I want syntax-based highlighting, lsp support, etc.

This looks rather like the Log-View buffer where revisions are navigated
with `n' and `p', and visited with `f' (log-view-find-revision).

Re: A vc wish: vc-timemachine

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

Agreed.  The basic bits of functionality are latent in vc.  Or, put another
way, timemachine is mostly a ui optimization.

That said, that optimization can be significant when looking for a
revision, if the subject code has been heavily edited.

On Mon, Oct 17, 2022 at 3:18 PM Juri Linkov <juri@linkov.net> wrote:

> > That said, vc-annotate is a jarring presentation.  As I browse through
> > different revisions I want the major mode to remain that of the original
> > (non-annotated) file.  I want syntax-based highlighting, lsp support,
> etc.
>
> This looks rather like the Log-View buffer where revisions are navigated
> with `n' and `p', and visited with `f' (log-view-find-revision).
>


-- 
John Yates
505 Tremont St, #803
Boston, MA 02116

[-- Attachment #2: Type: text/html, Size: 1472 bytes --]

Re: A vc wish: vc-timemachine

[John Yates]

On Mon, Oct 17, 2022 at 5:03 PM John Yates <john@yates-sheets.org> wrote:
>
> That said, that optimization can be significant when looking for a revision, if the subject code has been heavily edited.

To make that more concrete...

My backup scheme records an RCS revision everytime I save a file:
https://github.com/jsyjr/bostr   (A save is non-interaction and hence
records no meaningful commit comment.)

When something goes wrong I want to browse the various previous saved
states, searching for one that "looks right".  Here "looks right" is
based on what I remember the code looking like at some point in the
past.  The image in my memory is emphatically not a diff, nor a blame
display.  Typically it was some prog-mode buffer with font-locking.

Having to drive my search process from some alternate revision
enumeration and having to separately bring up a view of each revision
is just a painful amount of friction.

Re: scratching my own itch...

I am trying to prototype something based on Peter Stiernström's
git-timemachine.  Initially it will only support git, so, initially,
not a solution for my itch.  But it will help me get my feet wet with
vc and will provide a means for others to "kick the ui tires".

Re: A vc wish: vc-timemachine

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > git-timemachine is more akin to a non-existent
  > vc-revision-same-window.  It is a minor mode applied to a buffer
  > visiting a version controlled file.  It renders that buffer readonly
  > and then allows one to 'scroll' backward and forward over that file's
  > linear history, always showing a fully reconstructed revision, reusing
  > a single buffer.

That is a nice feature, but it should not be limited to git repos.
Can you use the existing repo-sw-independent VC primitives to do this
job?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A vc wish: vc-timemachine

[John Yates]

On Tue, Oct 18, 2022 at 7:59 AM Richard Stallman <rms@gnu.org> wrote:
>
> That is a nice feature, but it should not be limited to git repos.
> Can you use the existing repo-sw-independent VC primitives to do this
> job?

This is my first exposure to the vc architecture so there is learning
to be had.  My initial prototype will be based on the existing
git-centric git-timemachine code.

As I explained in a subsequent post, my personal itch is to have this
functionality available for RCS.  So, indeed, I will stick with the
project until it is properly integrated into the vc framework.

Re: A vc wish: vc-timemachine

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This is my first exposure to the vc architecture so there is learning
  > to be had.  My initial prototype will be based on the existing
  > git-centric git-timemachine code.

It's fine to do that as a first try, if it helps you reach the goal.
But please don't release or install it until you've redone it to
be VCS-independent.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)