On 2023/07/13 21:23:12 +1000, Mark Jamsek <mark@jamsek.com> wrote:
> Come to think of it, this is what we did in fossil, too, to avoid
> ambiguities, albeit with an extra keyword (e.g., tag:, root:, start:)

didn't know that fossil has something like this, but i like the idea
and will make use of it often.  Just a question though, especially
coming from a fossil background with tag: root: and start:, why did
you choose BASE in caps?  just for consistency with HEAD?

if we go the route of using a char disallowed in refs to make it
unambiguous, why don't use the (much easier to type) "base" and "head"
keywords?  it shouldn't conflict neither with the eventual temporal
expressions.

(just my two cents; still have to carefully read the diff.)

> before the colon. But I think the prefixed colon will suffice!
> Alternatively, in the first case:
> 
> got update -c BASE	# branch BASE if it exists, else worktree base
> got update -c :BASE	# use work tree base
> got update -c :BASE:-2	# same, and resolve ancestors
> got update -c main:-2	# use with regular refs needs only one colon
> 
> But perhaps it will be better to make :KEYWORD explicit all the time.

+1 for me, `got up -c BASE' is quick to write but it's prone to error
and user may not notice that once a ref "BASE" exists the meaning
suddenly changes.  `got up -c :BASE' is not much longer and doesn't
lend to ambiguities.

alternatively we could even use a different flag for these keywords
and other expressions.

	% got diff -e yesterday -c feature/xyz
	% got diff -e 2023-04-23 -e 'feature/xyz -3'

(using -e just because it's not used yet except for histedit, it's the
first random letter that came to mind.)