threads / discuss / 59901

Feature: Use $HOME instead of /home/username in ~/.gitconfig

Subject: Feature: Use $HOME instead of /home/username in ~/.gitconfig

## tl;dr

2 messages between Jun 23, 2023 and Jun 23, 2023.

replies: 1people: 2as markdown or json

Jovial Joe Jayarson· Jun 23, 2023, 08:22 UTC · lore
Hi,

Currently the `[maintenance]` section of `~/.gitconfig` has something like:

```ini
[maintenance]
    repo = /home/username/.znap/repos/asdf
```

I'm sharing my `.dotfiles` across systems, so I'd prefer `/home/username` be replaced with `$HOME` or even with `~/`.

```ini
[maintenance]
    repo = $HOME/.znap/repos/asdf
```

I'd be happy to make a patch, if somebody let me know where, in this huge repository: https://github.com/git/git

Thanks, Joe

Junio C Hamano· Jun 23, 2023, 17:21 UTC · re: Jovial Joe Jayarson · lore

Re: Feature: Use $HOME instead of /home/username in ~/.gitconfig

Jovial Joe Jayarson <jovial7joe@hotmail.com> writes:
Show 7 quoted lines
> I'm sharing my `.dotfiles` across systems, so I'd prefer
> `/home/username` be replaced with `$HOME` or even with `~/`.
>
> ```ini
> [maintenance]
>     repo = $HOME/.znap/repos/asdf
> ```

It probably is closer to our norm to use ~/ or ~username/ in our configuration files. $VAR syntax is unlikely to fly, as it will imply allowing arbitrary environment variables, whose security implications we would rather not have to worry about.

On the execution side, builtin/for-each-repo.c:run_command_on_repo() already knows to call interpolate_path() on the supplied pathname, which comes from the configuration variable (internally) specified, which is "maintenance.repo", so setting the variable to "~jjj/path" should already make it work, I would imagine (note: I am not a user of the feature).

The registration side is messier, though.

The path to your current repository is discovered, and then it gets canonicalized by going through strbuf_realpath(). This happens all inside builtin/gc.c:get_maintpath() and it is why the configuration variables store the absolute names. It also makes duplicate detection simpler to store the absolute names (otherwise, you'd need to compare each existing key after canonicalizing it with canonicalized new candidate repository, in order to avoid duplicates).

Turning "~jjj/hello.git" into "/home/jjj/hello.git" (or further into "/mnt/home3/jjj/hello.git", if "/home/jjj" is a symbolic link to "/mnt/home3/jjj") is easy, but there is no standard way to reverse it from "/mnt/home3/jjj/hello.git", which would be what get_maintpath() would be seeing.

If (and I do not know how) you manage to find a way for get_maintpath() to turn "/mnt/home3/jjj/hello.git" into "~jjj/hello.git", then there are a few changes needed:

 * builtin/gc.c:maintenance_register() has a loop to avoid
   duplicates; before entering the loop, pass "maintpath" to
   interpolate_path() and then strbuf_realpath() to canonicalize it
   (and call it $canon_maintpath).  In the loop, run the same
   canonicalization for each existing path (in item->string), and
   compare it with $canon_maintpath, to detect duplicates.  If the
   repository is not currently registered, use "maintpath" (not
   $canon_maintpath) to register.
 * builtin/gc.c:maintenance_unregister() has as loop to see if the
   "maintpath" exists, and then remove all associated values.  This
   will have to be modified heavily, to account for the directory
   aliases you are now introducing.  When get_maintpath() says that
   you are in "~jjj/hello.git" and unregistering the repository, you
   would need to catch all "maintenance.repo" configuration whose
   values are one of "~jjj/hello.git", "/home/jjj/hello.git", or
   "/mnt/home3/jjj/hello.git".

← back to recent threads