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

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: got {diff,log,update} -c KEYWORD (cf. svn revision keywords)
To:
Mark Jamsek <mark@jamsek.com>
Cc:
Omar Polo <op@omarpolo.com>, gameoftrees@openbsd.org
Date:
Mon, 17 Jul 2023 11:11:05 +0200

Download raw body.

Thread
On Mon, Jul 17, 2023 at 06:05:18PM +1000, Mark Jamsek wrote:
> Omar Polo <op@omarpolo.com> wrote:
> > > [...]
> > > +	while (n <= kwm.n) {
> > > +		err = got_commit_graph_iter_next(&iter_id, graph, repo,
> > > +		    NULL, NULL);
> > > +		if (err) {
> > > +			if (err->code == GOT_ERR_ITER_COMPLETED)
> > > +				err = NULL;
> > 
> > Here (in a follow-up maybe) I'd set error to something non-NULL.  I
> > think it'd be better to return an error if we couldn't go as far back
> > as required.  (imagine the case with `main' being a reference to a
> > commit without parent and the user doing got log -c main:-1)
> 
> At the moment, this will just show the log for main. The reason I
> decided to return the last reachable (i.e., most recent or oldest)
> commit if the user specifies a modifier that is too large, is for
> convenience and to avoid a hard error.
> 
> For example, if you want the root commit, rather than count, just give
> a large N. But do you think a ":root" keyword will be a better approach?
> It could represent the root commit of the current branch if in a work
> tree, or the root commit of the repository's HEAD. Or we could even make
> it a modifier like "main:root" or "foo:root".
> 
> I'm not against returning a hard error here, just looking for more
> ideas and considering the pros and cons of them.

I believe this boils down to specifying semantics in the documentation.
Does N mean "at most N" or "exactly N" commits?
The choice is arbitrary. We just have to pick an approach and document it.

Don't worry too much about getting things 100% right from the beginning.
Remember that we are free to revise our past choices until we explicitly
promise some amount of backwards compatibility. And even then, my hope is
that we will always get away with changing things across one or two
OpenBSD release cycles.
Having experienced the implications of eternal backwards compatibility in
the SVN project I would rather like to avoid this here. It is stifling.