Mark Jamsek <mark@jamsek.com> wrote:
> Stefan Sperling <stsp@stsp.name> 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 <https://bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68