From: Mark Jamsek Subject: Re: got {diff,log,update} -c KEYWORD (cf. svn revision keywords) To: Omar Polo Cc: Stefan Sperling , gameoftrees@openbsd.org Date: Fri, 14 Jul 2023 01:04:39 +1000 Omar Polo wrote: > On 2023/07/13 21:23:12 +1000, Mark Jamsek 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? Yes, purely because of HEAD and because it didn't use reserved chars. Now we're using :keyword[:(+|-)[N]], I think it's unnecessary and lowercase is much nicer :) > 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.) Yes, I agree 100% > > 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.) I'd like to avoid extra flags if we can do it simply, robustly, and get the desired functionality. But if we need another flag to do it, that would be fine too. -- Mark Jamsek GPG: F2FF 13DE 6A06 C471 CA80 E6E2 2930 DC66 86EE CF68