Stefan Sperling <stsp@stsp.name> wrote:
> 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.

That's a good point! And I've made no such distinction in the docs
either.  The current behaviour, which is what I intended, is to be
"at most N" commits. I like to avoid hard errors where possible, and I
think this is a case where it makes sense. But, yes, it should be
documented.

> 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.

I couldn't agree more! While I'm in no way averse to breaking changes at
this stage, I would become gradually more restrained over time, but would
always hope to avoid being trapped with the promise of eternal backwards
compatibility too!


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