From: Stefan Sperling Subject: Re: tog unable to view history of renamed file To: Mark Jamsek Cc: Ted Bullock , gameoftrees@openbsd.org Date: Thu, 30 Mar 2023 09:59:29 +0200 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.