Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> "The design decisions we made are all part of being opinionated" can >> all explain it away, but at least we should let the users know where >> the opinionated choices scalar makes want to lead them to, and this >> "src/" stuff needs a bit of clarification. Perhaps a documentation >> will be added in later steps? > > I had hoped that the initial blurb of the manual page was sufficient, but > you're right, the `register` subcommand is particular in that it allows to > force Scalar to consider the worktree to be identical to the Scalar > enlistment. I added this: Sorry, if it weren't clear that I was commenting on each step as I read along without peeking later steps. I think I saw it was written somewhere that this was to encourage use of read-only directory that keeps the sources with build artifacts and crufts created outside it (so forests of projects will not have the source directories, each of which has its own .git/, next to each other--- instead we would have shell directories, each with its own src/ and src/.git, next to each other). The additional documentation below is a good thing to have handy when readers learn how to use "register" (or more generally, what an "enlistment" is). As long as the motivation behind that design is given somewhere (not necessarily here) for readers to discover, I am OK with the design. > diff --git a/contrib/scalar/scalar.txt b/contrib/scalar/scalar.txt > index 1593da45eae..568987064b2 100644 > --- a/contrib/scalar/scalar.txt > +++ b/contrib/scalar/scalar.txt > @@ -40,6 +40,10 @@ register [<enlistment>]:: > and starts background maintenance. If `<enlistment>` is not provided, > then the enlistment associated with the current working directory is > registered. > ++ > +Note: when this subcommand is called in a worktree that is called `src/`, its > +parent directory is considered to be the Scalar enlistment. If the worktree is > +_not_ called `src/`, it itself will be considered to be the Scalar enlistment. Thanks.
