On 2024-03-20 17:03:23 +0100, Ludovic Courtès wrote:
> Hi,
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
> > Tomas Volf <~@wolfsden.cz> skribis:
> >
> >>> +(define* (record-configuration repository
> >>> +                               #:key commit signer keyring-reference)
> >>> +  "Record COMMIT, SIGNER, and KEYRING-REFERENCE in the 'config' file of
> >>> +REPOSITORY."
> >>> +  (define directory
> >>> +    (repository-directory repository))
> >>> +
> >>> +  (define config-file
> >>> +    (in-vicinity directory "config"))
> >>
> >> I do not think this will work with worktrees.  It will create the config file in
> >> the worktree's git directory, but that file will be ignored by git.
> >>
> >>     scheme@(guile-user)> (repository-discover "/home/xx/src/guix-wt/patch-1")
> >>     $7 = "/home/xx/src/guix/.git/worktrees/orig/"
> >>     scheme@(guile-user)> (repository-open $7)
> >>     $8 = #<git-repository 128cbe0>
> >>     scheme@(guile-user)> (repository-directory $8)
> >>     $9 = "/home/xx/src/guix/.git/worktrees/orig/"
> >>     scheme@(guile-user)> (in-vicinity $9 "config")
> >>     $10 = "/home/xx/src/guix/.git/worktrees/orig/config"
> >>
> >> The $10 should be "/home/xx/src/guix/.git/config" instead.
> >
> > Damn it.  So hmm, I can see two options:
> >
> >   1. Add more bindings to (git config) in Guile-Git so we can populate
> >      that file “the right way”.  But then we’ll have to require that
> >      newer version of Guile-Git.
> >
> >   2. Bail out when the ‘.git/config’ isn’t found, as in the case of
> >      worktrees; we can change that to use the proper (git config)
> >      eventually.
> >
> > Maybe we should go straight to #1 though.  Thoughts?
>
> Done:
>
>   https://gitlab.com/guile-git/guile-git/-/commit/b3be1dd752682b2b6c9a7c11ccdbfc0f0b5cf4e7
>   https://gitlab.com/guile-git/guile-git/-/commit/d38c09230467ca5cca7faabb0c3a43c61a1e2c05

Oh, that looks really nice.

>
> I can cut a new Guile-Git release soonish and we’d use these new
> bindings.
>
> The only open issue left is branches: how to configure different
> introductions for different branches.  I’m all ears!

Right, so I have few ideas, not sure if they are any good though.  And I myself
am not really sure which one I like the most, so...

0. Not care about it.  Since the explicit values override the stored ones, my
scripting will still work.

1. Record the success only when on the master branch.  That assumes that *most*
branches will share authentication parameters with the master.  That holds for
my repository (only orig-master branch differs), not sure if generally.

2. Store authentication per branch (guix.authentication.BRANCH. prefix) and
periodically clean up stale configuration (if BRANCH no longer exist, delete all
config for it).

3. Add guix.authenticate.do-not-record config defaulting to false.  That would
allow people like me to just turn if off.

4. Store the authentication on *each* success, so last-wins approach.

5. Expand the 2. to allow pattern (regex? or at least list of branches), so I
(as a user) could configure (using git config) which branch should use different
authentication from the globally recorded "default" from master branch (see 1.).

The problem here is that any possible "smart" solution leaves something to be
desired.  Either it is not automated enough (new branches are unconfigured), or
it is too magical (new branches inherit the config from... something).  5. is
probably the most flexible and covering edge cases, but will not be exactly
one-line change.

Hm, now when I read it after myself, maybe it is just not a problem worth
solving.  All of these are likely to complicate the code quite a bit.  Not sure.

Dunno, was this of any help? :)

Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.