3 ms·

But the key disadvantage is that now getting started with the repository requires more effort: you must have sqlite3 installed locally, and you must apply certa

But the key disadvantage is that now getting started with the repository requires more effort: you must have sqlite3 installed locally, and you must apply certain config values manually (and “remember to run this helper script” or “the first time you try running it it’ll⸺” are still manual). (This is for security reasons—you don’t want commands like clone and diff to be able to execute arbitrary code without your knowledge. Hence the attributes/config split.) Otherwise, you’ll find that your .sqlite file is SQL instead of a SQLite database, and if you try running stuff while it’s in that condition you’ll get “file is not a database” errors from SQLite.

redleader55 3y ago
You are right, there is a bootstrap cost and potential security implications. In general, also, .gitattributes is pretty evil, but: 1. don't store binary files in Git 2. don't run programs that keep a git file open for too long, otherwise clowntown. For example, you run git pull while GnuCash keeps the file open and then you loose all your updates when you save (also a problem with the code below, but fixable). The correct solution to this is running the "smudge" and "clean" operations as a backup and restore operation, outside the repo, when starting and closing GnuCash, in this case: ``` #!/bin/bash cat $1.sql > $1.sqlite3 gnucash $1.sqlite3 echo ".dump" | sqlite3 $1.sqlite3 > $1.sql # optionally: # git add $1.sql # git commit -m "Update $(date) $1.sql" ```
- chrisweekly 3y ago
  ".gitattributes is pretty evil" Could you please expand on this? I've been working with git for many years, and IME .gitattributes files are useful, sometimes essential, as the standard way to manage repo-level settings -- especially helpful for larger projects with heterogenous contributors. What am I missing?
  - redleader55 3y ago
    In general, I believe in not giving people enough rope to hang themselves, but hiding the rope under a lock (Porcelain commands) that you open by entering complicated commands which weird syntax (Plumbing commands). .gitattributes are "evil", because they "lie" about what's in the repo. You could use .gitattributes for simple things like line endings on different platforms (Windows vs Unix), but you could also use it for more complex flows where the file you have locally and the file you store in the repo are completely different - filter feature. This would be "magic"/hidden/implicit, rather than explicit for the user who won't understand why github.com shows something and their local filesystem shows something else.

redleader55 3y ago

You are right, there is a bootstrap cost and potential security implications. In general, also, .gitattributes is pretty evil, but: 1. don't store binary files in Git 2. don't run programs that keep a git file open for too long, otherwise clowntown. For example, you run git pull while GnuCash keeps the file open and then you loose all your updates when you save (also a problem with the code below, but fixable). The correct solution to this is running the "smudge" and "clean" operations as a backup and restore operation, outside the repo, when starting and closing GnuCash, in this case: ``` #!/bin/bash cat $1.sql > $1.sqlite3 gnucash $1.sqlite3 echo ".dump" | sqlite3 $1.sqlite3 > $1.sql # optionally: # git add $1.sql # git commit -m "Update $(date) $1.sql" ```

chrisweekly 3y ago
".gitattributes is pretty evil" Could you please expand on this? I've been working with git for many years, and IME .gitattributes files are useful, sometimes essential, as the standard way to manage repo-level settings -- especially helpful for larger projects with heterogenous contributors. What am I missing?
- redleader55 3y ago
  In general, I believe in not giving people enough rope to hang themselves, but hiding the rope under a lock (Porcelain commands) that you open by entering complicated commands which weird syntax (Plumbing commands). .gitattributes are "evil", because they "lie" about what's in the repo. You could use .gitattributes for simple things like line endings on different platforms (Windows vs Unix), but you could also use it for more complex flows where the file you have locally and the file you store in the repo are completely different - filter feature. This would be "magic"/hidden/implicit, rather than explicit for the user who won't understand why github.com shows something and their local filesystem shows something else.