31

So I use Git mostly for development purposes, but I just realized that I could use it for storing versions of the settings files I have on my Ubuntu installation.

My proposed setup is:

  • git init a repo at /

  • Add a .gitignore at / that ignores any files except specific settings I want to track.

    For example, the .gitignore could contain (source):

    ## Ignore everything...
    *
    
    ## Except...
    !/etc/default/tlp
    !/etc/crontab
    
  • Whenever I change these low-level settings, I can track them.

Is there anything that could go wrong with this setup? Does the kernel always need / to only have certain folders? Will it mess up the functioning of any applications?

8
  • Perhaps you should consider your ~ home directory settings files rather than / files May 20, 2017 at 1:26
  • 1
    The old grex SunOS public server had all of its rc files and who knows what else in some old source control (not sure if it was SCCS or RCS, but definitely older than CVS). I don't see a problem with this.
    – Joshua
    May 20, 2017 at 3:22
  • @Mike Durrant: stuff like /etc/crontab on my personal laptop is definitely mine, but I see what you mean. May 20, 2017 at 3:28
  • 7
    Use etckeeper and make backups. May 20, 2017 at 11:20
  • Just be careful to not accidentally to stage/commit i.e. /dev/sda or similar :D May 20, 2017 at 19:25

5 Answers 5

40

The answer to both of your questions is no, you can create any directory you want in the /. the only thing that could happen is some permission issues with some spacial paths I guess.

However it's better to store the .git directory somewhere else, something look like:

git --git-dir=/home/user/backup-root --work-tree=/

Read here.

3
  • 5
    Very interesting, I didn't actually know you could do this in git! Thanks for the suggestion. May 19, 2017 at 19:33
  • That's the same feature which lets you track only setting files under /home/user btw. Adding an shell alias additionally makes this very convenient. May 21, 2017 at 12:25
  • this command doesn't work for me (ubuntu 22.04), when i run it git just list its commands and flags, just like in "git help"
    – N. Joppi
    Aug 20, 2022 at 21:08
19

Actually, you probably want to version control configuration files in /etc/ (you don't care about the entries of the root directory /, notably directories like proc or usr or bin in /) so you may want to install the etckeeper package

And you could also version control some selected subdirectories (like /usr/share/applications/ that you mentioned).

However, don't mess with the Ubuntu package management system. Perhaps you mostly should backup the current list of installed packages.

1
  • 1
    I actually do care about files in /usr/share/applications as I occasionally mess around with them. May 20, 2017 at 6:10
6

Having a git repo in / works fine, except that it does make it hard to notice when you have a lower level git repo with problems as it will answer for all of them.

Note: It is less work and probably more useful to use 'debsums'

sudo apt-get install debsums

Which will allow you to quickly detect (most) changes in binaries or in configuration files.

As an example from the installed packages here are the ones that differ from the upstream packages.

$ sudo debsums -c
/boot/vmlinuz-4.10.0-19-generic

And you can get a list of changed configuration files with:

$ sudo debsums -ec
debsums: missing file /etc/default/chromium-browser (from chromium-browser package)
 /etc/libvirt/libvirt.conf
 <snip>

Note how the chromium-browser is improperly packaged and and has a file listed in the the package file list that doesn't exist.

/var/lib/dpkg/info/chromium-browser.list

This uses the dpkg data and avoids a large /.git directory and workflow.

9
  • Could you explain "except that it does make it hard to notice when you have a lower level git repo with problems as it will answer for all of them." a bit more? I'm not understanding how it could cause a problem if the .gitignore only tracks a few files. May 19, 2017 at 19:55
  • 2
    I believe @abhidivekar OP is saying when you create another git repo in say /home/$USER then the .git in / will answer for any git command given for the repo in /home$USER rather than for that [.gir file ] in /home/$USER... May 19, 2017 at 20:17
  • Ah I see. I think I should just keep it in a separate folder then. Or / May 19, 2017 at 20:19
  • 1
    @George To access the .git directory higher in the tree, you just cd to it, or a subdirectory of it which does not have a .git folder (a normal directory that is)
    – cat
    May 20, 2017 at 19:21
  • 2
    @abhidivekar Correct, it is not a problem if the benefits outweigh the problems but it is unexpected behavior. Not a blocker, just a caveat.
    – gdahlm
    May 20, 2017 at 21:06
5

So I've been exploring the other answers and I've found a procedure which works for me:

  • Make a .gitignore at /. This was much more complicated than I thought it would be, because of the way Git handles whitelisting files in subfolders. I used this and this link to help me.

    ## Source: https://stackoverflow.com/a/29932318/4900327
    ## Comments are on new lines because trailing whitespace matters in Git (stackoverflow.com/a/8865858/4900327)
    
    # Blacklist all files, folders and subfolders in the same directory as the .gitignore file.
    /*
    # Do not blacklist the .gitignore file.
    !.gitignore
    
    # Now whitelist certain files.
    # For files in subfolders, some hoops must be jumped through (stackoverflow.com/a/16318111/4900327):
    
    ## Whitelisting files in /etc/ folder:
    # Whitelist the /etc/ folder (the git repo folder is whitelisted always)
    !/etc/
    # Blacklist all files in /etc/ folder.
    /etc/*
    # Whitelist specific file(s) in /etc/ folder.
    !/etc/crontab
    
    
    ## Whitelisting files in /etc/default/ folder:
    # /etc/ is already whitelisted, and its contents blacklisted.
    # Whitelist /etc/default/ folder.
    !/etc/default/
    # Blacklist all files in /etc/default/ folder.
    /etc/default/*
    # Whitelist specific file(s) in /etc/default/ folder.
    !/etc/default/tlp
    
    
    ## Whitelisting files in /home/USERNAME/ folder:
    # Whitelist /home/ folder.
    !/home/
    # Blacklist all files in /home/ folder.
    /home/*
    # Whitelist /home/USERNAME/ folder.
    !/home/USERNAME/
    # Blacklist all files in /home/USERNAME/ folder.
    /home/USERNAME/*
    # Whitelist specific file(s) in /home/USERNAME/ folder
    !/home/USERNAME/.bash_profile
    !/home/USERNAME/.bashrc
    
  • Go to / and run git init . So far, I have been unable to store the .git/ folder in another directory using the link mentioned by @Ravexina.

  • Run git add . and git status. You should get a listing of all the settings files Git is tracking.

    If you used the above `.gitignore`, it should track `/etc/crontab`, `/etc/default/tlp`, `/home/USERNAME/.bash_profile`, and `/home/USERNAME/.bashrc`.
    
  • Commit with git commit -m "Initial settings files".

  • You can track changes with git log -p -- path/to/fileor gitk path/to/file. More discussion on this here.

3

If you are going to store sensitive stuff (like /etc/shadow) in the git repo, you should make sure it's not readable by all users, since by default the objects will have the permission 444 and directories will have the permission 0755. You can change the permission of .git to 700 or put it in /root

Another problem is that git doesn't store file permissions like the file system, and it doesn't store extended attributes. For files, git only stores whether they are executable. So if you want to restore a deleted file, its owner and group will be root (if you do it as root), and its permission will be 644 or 755. It may be problematic for services' configuration files whose owner is not root.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .