git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)

From
KMKyle Moffett <mrmacman_g4@mac.com>
Date
Dec 10, 2006, 18:35 UTC
Message-ID
<19476830-E30A-42B7-AD9B-4C417D830C8E@mac.com>
In-Reply-To
<200612101926.33307.jnareb@gmail.com>
On Dec 10, 2006, at 13:26:32, Jakub Narebski wrote:
Show 8 quoted lines
> The idea is to not store /etc in git directly, but use import/ 
> export scripts, which for example saves permissions and ownership  
> in some file also tracked by git on import, and restores correct  
> permissions on export. That is what I remember from this  
> discussion. This of course means that you would have to write your  
> own porcelain...
>
> What about mentioned in other email IsiSetup?

The real problem I have with that is you literally have to duplicate all sorts of functionality. I want to run "foo-status" in /etc and get something useful, but if /etc is not a git directory in and of itself then you have to duplicate most of "git-status" anyways. And the same applies to all the other commands. From what I can see of IsiSetup the tools for checking out, merging, modifying, cloning, etc are all much more limited and immature than the ones available through GIT/cogito, and I would be loathe to discard all that extra functionality and duplicate a few thousand lines of code in the name of "concept purity".

GIT already has _some_ idea about file permissions, it just discards most of the data before writing to disk. Of course, adding POSIX ACLs and user-extended-attributes requires a new data format, but those are very similar to filesystem permissions; they differ only in amount of data stored, not in purpose.

Import/export scripts literally require wrapping every single GIT command with a script that changes directory a few times, reads from a different checked-out tree, and permutes some extended-attribute data slightly before storing it in the underlying GIT tree. Even without adding any new functionality whatsoever that doubles the amount of code just for finding your repository and checking command- line arguments, and that's a crazy trade-off to make in any situation.

Cheers, Kyle Moffett

Previous: Jakub NarebskiNext: Andreas Ericsson
Message 7 of 34 in “Using GIT to store /etc (Or: How to make GIT store all file permission bits)”
  1. Kyle MoffettDec 10, 2006
  2. Jeff GarzikDec 10, 2006
  3. Jakub NarebskiDec 10, 2006
  4. Kyle MoffettDec 10, 2006
  5. Jakub NarebskiDec 10, 2006
  6. Jakub NarebskiDec 10, 2006
  7. Kyle MoffettDec 10, 2006
  8. Andreas EricssonDec 11, 2006
  9. Jeff GarzikDec 11, 2006
  10. Josef WeidendorferDec 11, 2006
  11. Johannes SchindelinDec 11, 2006
  12. Josef WeidendorferDec 11, 2006
  13. Santi BéjarDec 10, 2006
  14. Kyle MoffettDec 10, 2006
  15. Jakub NarebskiDec 10, 2006
  16. David LangJan 10, 2007
  17. Shawn O. PearceJan 10, 2007
  18. David LangJan 10, 2007
  19. Shawn O. PearceJan 12, 2007
  20. Nikolai WeibullDec 11, 2006
  21. Daniel BarkalowDec 12, 2006
  22. Kyle MoffettDec 12, 2006
  23. Andy ParkinsDec 12, 2006
  24. Using git as a general backup mechanism (was Re: Using GIT to store /etc)Steven Grimm, Dec 12, 2006
  25. Johannes SchindelinDec 12, 2006
  26. Steven GrimmDec 12, 2006
  27. Johannes SchindelinDec 13, 2006
  28. Martin LanghoffDec 12, 2006
  29. Martin LanghoffDec 12, 2006
  30. Junio C HamanoDec 12, 2006
  31. Steven GrimmDec 14, 2006
  32. Junio C HamanoDec 15, 2006
  33. Daniel BarkalowDec 13, 2006
  34. Chris RiddochDec 14, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.