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

From:
Mark Jamsek <mark@jamsek.com>
Subject:
Re: tog: diff local worktree changes
To:
Game of Trees <gameoftrees@openbsd.org>
Date:
Tue, 30 Aug 2022 23:36:44 +1000

Download raw body.

Thread
On 22-08-30 12:03PM, Stefan Sperling wrote:
> On Fri, Aug 26, 2022 at 01:42:46AM +1000, Mark Jamsek wrote:
> > The below diff enables diffing local changes in the work tree. I've
> > just copied the `got diff` interface. I think this is good because it
> > makes the UI consistent, which makes sense imo. Now we can view changes
> > in the work tree with:
> > 
> >   tog diff [path ...]
> 
> I am feeling a bit ambivalent about this.
> 
> (Below, I am not trying to suggest that you or anyone else should do
> extra work. I am just thinking about what this feature implies for
> Got's high-level design as a toolkit.)
> 
> On the one hand, I understand the convenience of an interactive diff
> viewer.
> 
> On the other hand, I wonder if this is going to change people's expectations
> of the tool, slowly morphing tog from a read-only repository-browser into a
> small mini-IDE? Because once we are including the work tree in the scope of
> tog, people may well expect more work-tree-related commands/views, such as
> 'tog status', 'tog commit', 'tog branch', 'tog add', 'tog remove',
> 'tog revert', ... until it becomes an ncurses-equivalent to the got CLI.
> 
> Is this a direction we really want to take? Heading into this direction would
> duplicate a lot of effort reimplementing UI which already exists as a CLI.
> Such effort could instead be spent on other areas where Got needs to improve.
> Granted, the end result of fleshing out tog in this way could be really nice
> if it is done well and consistently.
> 
> Is this the direction where adding this feature would take us eventually?
> Or is this this really only about diffing changes in the work tree, and then
> we are done?
> 

I understand your concerns, and to make my intention clear I don't want
to go this route of morphing tog into a mini-IDE. Even assuming the work
was a given, I wouldn't want to see tog go that route.

That said, I'm not sure that the addition of `tog diff` to diff worktree
changes would shift user expectations so much that a tog equivalent of
all Got CLI commands would be wanted.

My motivation for this change was primarily for the workflow of
reviewing other developers' diffs as well as my own, so a read-only
browser use case. But when I went to implement it, I noticed the TODO
comment added in 26ed57b23d183a3e:

	usage_diff(); /* TODO show local worktree changes */

So I assumed you wanted it too :)

tbh, I'd really like to see it added and _think_ it would be a popular
usage of `tog diff` because it adds a very real advantage over its `got
diff` counterpart, while I don't see the same advantage of making
commands like status or revert available to tog.  That said, I don't
know how to assuage your concerns regarding its impact of user
expectations, except to say that I think it's closer to tog's current
read-only browser model than the worktree management model of commands
such as add, remove, commit, etc., so don't expect it to push
development down that path.  At the very least, I don't want it too.

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