Solved gitignore ".sujournal" problem with full path pattern in the ~/.config/git/ignore

gitignore(5) works fine with filename-only pattern, i.e. it ignores .sujournal correctly.

$HOME/.config/git/ignore
Code:
.sujournal

But when I set the full path, it doesn't ignore it, i.e. Git status complains:

$HOME/.config/git/ignore
Code:
/usr/src/.sujournal

My Git setting (Normal User):
Code:
$ git config --global user.name "USER"
$ git config --global user.email USER@HOST
$ git config --global pull.rebase true
$ git config --global fetch.prune true
$ git config --global diff.colorMoved
$ git config --global core.excludesFile "$HOME/.config/git/ignore"

Good (ignores all)

$HOME/.config/git/ignore
Code:
.sujournal
/usr/doc/.snap/
/usr/ports/.snap/
/usr/src/.snap/

Bad (dismissed the .sujournal)

$HOME/.config/git/ignore
Code:
/usr/doc/.snap/
/usr/doc/.sujournal
/usr/ports/.snap/
/usr/ports/.sujournal
/usr/src/.snap/
/usr/src/.sujournal

uname -a
Code:
FreeBSD <HOST> 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: <DATE> <TIME> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
 
Gitignore entries are patterns, not paths. When they contain a slash, they are interpreted as a relative path to the repository root (or the directory in which a .gitignore file is placed).
See: https://git-scm.com/docs/gitignore

If you don't want to ignore any .snap/ and .sujournal globally, you could instead use this mechanism:
Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file.

If you want to globally ignore them, but only on the root level of the individual repos, use this:
Code:
/.sujournal
/.snap
 
  • Thanks
Reactions: a6h
Finally, I think I'm all set!
This is what I've done to exclude .sujournal file and .snap from all three source trees (doc, ports, src) -- only exclude from root of the repos:

* /usr/doc/.git/info/exclude AND
* /usr/ports/.git/info/exclude AND
* /usr/src/.git/info/exclude :

Code:
/.sujournal
/.snap/
 
That's the most specific you can do indeed. I probably wouldn't have bothered though: How likely is it to ever come across a git repo that has an actual .sujournal file? ;)

BTW, a nice thing about a ZFS dataset is that .zfs/ is really invisible unless explicitly accessed, so you don't have to bother with it using git (it will never notice its presence) ;)

(maybe an idea for improvement in UFS? Or could such a change break things?)
 
That's the most specific you can do indeed. I probably wouldn't have bothered though: How likely is it to ever come across a git repo that has an actual .sujournal file? ;)
You're right. That's too much. I'm a little neat freak though! which lead me to your next question, "why not ZFS".
ZFS is fine, but it's not for me. Let's just say, when it comes to setup electronics in my bunker, I have a psyche of geometric mean of "suckless.org" and "cat-v.org". Even Artix-base/runit is too much IMHO.
 
which lead me to your next question, "why not ZFS".
JFTR, I didn't ask that ;) Although there's IMHO very little reason not to use ZFS, UFS is a well-working filesystem, so why not.

I only noticed that this specific problem wouldn't occur with ZFS because its metadata stuff is "really hidden". And just maybe, UFS could offer something similar … just "brainstorming" ;)
 
  • Thanks
Reactions: a6h
Back
Top