On 22-06-16 06:30pm, Stefan Sperling wrote:
> On Fri, Jun 17, 2022 at 01:38:33AM +1000, Mark Jamsek wrote:
> > You've given me something to think about. At present, the best I can
> > come up with is that stash is a convenient, quick context-switch for
> > small tasks. 'got stash' and 'got stash pop' is pretty convenient. But,
> > you're right, there is a workaround; however, till I try it, I don't
> > know that it would be as quick and simple. Whether that convenience is
> > worth the code cost is another question.
> 
> If we were to implement a stash feature, it would be reasonable to
> build the implementation as syntactic sugar on top of the features
> we already have. I believe all the building blocks are already there.
> 
> The next trade-off would then be if this should be a wrapper script,
> (fewer lines of code, won't add any maintenance cost to the C code base),
> or a new command in got.c (more lines of code, adds maintenance cost).

I've thought about this a bit and I've decided you're right: got already
provides for this use case. In fact, it's better than stash because you
can have a persistent stash (which is something I was thinking about
adding to libf as I'm just working on its stash implementation now).

I realised I was bringing my own assumptions based on a workflow I'd
developed using Fossil, which was wrong. Instead, I should be adapting
and learning how best to use this tool, which is what I'll be doing.

So, no, I don't think any syntactic sugar is needed. The scripted
approach will more than suffice and users can tailor it to their
workflow.

> If the scripted approach turns out to be really simple in practice,
> perhaps we could even just add a section to the EXAMPLES section of
> the man page which explains how the concept of stashing changes can
> be made to work with the existing commands. This might be best in
> order to help people improve their skillset in using the tool most
> effectively. Adding too much abstractions and syntactic sugar could
> end up obfuscating the basics.

That's a great idea! And after thinking about this, I completely agree.
Thanks, Stefan.

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