"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: tog unable to view history of renamed file
To:
Mark Jamsek <mark@jamsek.com>
Cc:
Ted Bullock <tbullock@comlore.com>, gameoftrees@openbsd.org
Date:
Thu, 30 Mar 2023 09:59:29 +0200

Download raw body.

Thread
On Thu, Mar 30, 2023 at 02:59:06PM +1100, Mark Jamsek wrote:
> To see files from previous versions, pass the desired version to the -c
> option; for example:
> 
>   {got,tog} log -c 40a44b36bbc108a97e65517b98bc2bb65896ff07 evbuffer.c

It is of course possible to only type the first few letters of the
commit hash, such that it is not ambiguous. Between 4 and 6 letters
should suffice unless repository history is very deep. Full commit
hashes are only conveniently achievable via copy-paste.

Another way of getting at a deleted file's log history is to start
tog and navigate to a commit in where the file still existed.
Now press T to open the tree view for this commit. Then navigate to
the desired file in this tree view and press L to see its log.

> > Ideally I would like to see the commit history in tog transcend the
> > rename operation, but failing that I still would expect the tool to pull
> > the history of the file when rewound to when it still exists at the old
> > name.
> 
> I'm not sure if it would be more intuitive to start traversing history
> from the checked-out commit if invoked in a work tree. It may be
> somewhat surprising to see a bunch of missing commits. As it stands, to
> achieve this behaviour, simply grab the work tree's base commit from
> 'got info' and pass it to '{got,tog} log -c'.
> 
> Perhaps this behaviour could be made clearer in the docs, although
> I think it is already quite clear (a branch ref always points at the
> head of the branch):
> 
> -c commit
>      ...
>      If this option is not specified, default to the work tree's current
>      branch if invoked in a work tree, or to the repository's HEAD reference.

Subversion offers special revision keywords for such use cases.
There is -r BASE which resolves to the base commit of a particular
path in the working copy, whatever the base revision number happens
to be. There is also -r WORKING which resolves to the file as it
exists in the working copy (useful e.g. for diffing working file
content against some other commit, a feature we do not yet support).

We could add something similar to -r BASE, such as got log -c BASE.
Or offer a dedicated command line option for this use cases, such as
	got log -B [path]
	tog log -B [path]
This option would of course be mutually exclusive with the -c option.