From: Mark Jamsek Subject: Re: show base commit markers in tog log view To: Mark Jamsek Cc: Stefan Sperling , gameoftrees@openbsd.org Date: Sat, 22 Jul 2023 20:12:04 +1000 Mark Jamsek wrote: > Stefan Sperling wrote: > > On Fri, Jul 21, 2023 at 10:54:58PM +1000, Mark Jamsek wrote: > > > This is a simple change along the same lines of showing reference labels > > > next to tog log messages insofar as it improves situational awareness, > > > which can be handy at times. > > > > > > For example, in the case where you want to fold or drop some commits. > > > After 'got up -c:head:-N', I often like to confirm I've updated to the > > > correct commit before invoking histedit. With this, you can open tog and > > > at a glance confirm that your base commit is indeed the correct one for > > > the desired histedit operation. Similarly, when your base commit is > > > something other than the tip, it's nice to know where the base commit is > > > in relation to the rest when browsing the log view. This can interop > > > well with the new :base keyword feature. > > > > > > The change will be immediately obvious upon running tog with the patch > > > inside a work tree, but to summarise: we show the "[base commit]" label > > > in the log view headline if the currently selected commit is the work > > > tree's base commit; and, irrespective of which commit is selected, we > > > prepend the base commit's summary log message with the '@' symbol. There > > > is no change to the log view when tog is invoked outside a work tree. > > > > I agree that this is useful. > > > > Some things I would suggest to change: > > > > Could we use * instead of @, for consistency with got branch -l? > > And like got branch -l, could tog show ~ if the work tree is out of > > date with respect to the branch tip? > > > > A problem that applies to both this patch and got branch -l: > > A mixed-commit work tree will be displayed as up-to-date since the current > > logic only considers the work tree's global base commit. > > Could we iterate over the file index and check whether any file is based > > on a different commit, and if so show the out-of-date symbol ~? > > > > It is a matter of taste but the [base commit] marker seems redundant to me > > and makes the display seem too crowded. I would omit this marker for now. > > Yes, sure! The reason I wasn't concerned with distinguishing between > out of date and up-to-date trees is it's easy to see in the log view in > the general case because it won't be the topmost commit; but that's a > good idea about mixed commits--there's no other way to see this without > different symbols. > > The below diffs implement your suggestions: the first adds a new lib > routine to get the tree state, and shows the * or ~ marker in tog (the > headline label has also been removed); the second gives the same > treatment to 'got branch -l' including test coverage. > > I've also added a couple got_worktree_close() calls to cmd_ref() and > cmd_tree() that we were missing; if we hit an error early in these > functions we were leaking the worktree. I'm not sure if the tweak to 'got branch -l' output necessitates a change to the docs too? Just in case, here's a minor addition to mention the mixed commit case. diff /home/mark/src/got commit - 88c87e08a822bf5882cebc085a5bc80ebb5ffbc1 path + /home/mark/src/got blob - 307cde1004e6a1fa347b52fc61a1f2576241e8a8 file + got/got.1 --- got/got.1 +++ got/got.1 @@ -1566,8 +1566,8 @@ with one of the following annotations: If invoked in a work tree, the work tree's current branch is shown with one of the following annotations: .Bl -column YXZ description -.It * Ta work tree's base commit matches the branch tip -.It \(a~ Ta work tree's base commit is out-of-date +.It * Ta work tree's base commit and file index matches the branch tip +.It \(a~ Ta work tree comprises mixed commits or its base commit is out-of-date .El .It Fl n Do not switch and update the work tree after creating a new branch. -- Mark Jamsek GPG: F2FF 13DE 6A06 C471 CA80 E6E2 2930 DC66 86EE CF68