On 23-03-30 09:59AM, Stefan Sperling wrote:
> 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.

Yes, of course, and this is well documented too.

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

That's probably how I would do it; it's great how all views link to each
other. This makes tog really nice for studying new codebases.

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

I'm a bit torn. On the one hand, I think got already provides for this
use case. It's as simple as `got info`, read the base commit, then
`{got,tog} log -c abc012`. If it's done frequently, I'd probably alias:

  tog log -c $(got info | grep base | cut -d' ' -f5)

Adding more options to do something that is already easily doable seems
like a path to too many options.

On the other hand, I like the 'log -c BASE' suggestion; it reminds me of
mercurial revsets, which are quite nice. And we also offer something
similar in Fossil with special terms  like: 'current' for the current
checkout; 'next' for the child of the current checkout; and 'prev' for
the parent of the current checkout. I use these often. So of the two
proposed solutions, I'd prefer going that route.

I'm quite busy for the next week or so but will have spare time to hack
on got from April 9. I was going to polish the tog test harness diff but
I can do this first if we want to pursue the BASE idea.

-- 
Mark Jamsek <fnc.bsdbox.org|got.bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68