Is it a good idea to use git for configuration file version controlling?











up vote
13
down vote

favorite
9












I use Gentoo Linux and it has rather complex configuration. My question is it wise to use git for version controlling my config files?



I have some git repos in my home, my guess if I put /home/** to my .gitignore they will not cause problems.



Clarification update:



Is it a wise method to use git to version control my system level configuration files in the "/" root directory?










share|improve this question
























  • @AnthonyGeoghegan I wan to track my "/" root directory what can lead to interesting consequences in the future so the linked thread only partially answer my question. The other part: is it wise to use git for version controlling my config files still unanswered
    – atevm
    Feb 9 '16 at 13:44








  • 1




    @AnthonyGeoghegan thanks. I updated the question.
    – atevm
    Feb 9 '16 at 17:04















up vote
13
down vote

favorite
9












I use Gentoo Linux and it has rather complex configuration. My question is it wise to use git for version controlling my config files?



I have some git repos in my home, my guess if I put /home/** to my .gitignore they will not cause problems.



Clarification update:



Is it a wise method to use git to version control my system level configuration files in the "/" root directory?










share|improve this question
























  • @AnthonyGeoghegan I wan to track my "/" root directory what can lead to interesting consequences in the future so the linked thread only partially answer my question. The other part: is it wise to use git for version controlling my config files still unanswered
    – atevm
    Feb 9 '16 at 13:44








  • 1




    @AnthonyGeoghegan thanks. I updated the question.
    – atevm
    Feb 9 '16 at 17:04













up vote
13
down vote

favorite
9









up vote
13
down vote

favorite
9






9





I use Gentoo Linux and it has rather complex configuration. My question is it wise to use git for version controlling my config files?



I have some git repos in my home, my guess if I put /home/** to my .gitignore they will not cause problems.



Clarification update:



Is it a wise method to use git to version control my system level configuration files in the "/" root directory?










share|improve this question















I use Gentoo Linux and it has rather complex configuration. My question is it wise to use git for version controlling my config files?



I have some git repos in my home, my guess if I put /home/** to my .gitignore they will not cause problems.



Clarification update:



Is it a wise method to use git to version control my system level configuration files in the "/" root directory?







linux git gentoo






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 9 '16 at 17:03

























asked Feb 8 '16 at 18:02









atevm

18418




18418












  • @AnthonyGeoghegan I wan to track my "/" root directory what can lead to interesting consequences in the future so the linked thread only partially answer my question. The other part: is it wise to use git for version controlling my config files still unanswered
    – atevm
    Feb 9 '16 at 13:44








  • 1




    @AnthonyGeoghegan thanks. I updated the question.
    – atevm
    Feb 9 '16 at 17:04


















  • @AnthonyGeoghegan I wan to track my "/" root directory what can lead to interesting consequences in the future so the linked thread only partially answer my question. The other part: is it wise to use git for version controlling my config files still unanswered
    – atevm
    Feb 9 '16 at 13:44








  • 1




    @AnthonyGeoghegan thanks. I updated the question.
    – atevm
    Feb 9 '16 at 17:04
















@AnthonyGeoghegan I wan to track my "/" root directory what can lead to interesting consequences in the future so the linked thread only partially answer my question. The other part: is it wise to use git for version controlling my config files still unanswered
– atevm
Feb 9 '16 at 13:44






@AnthonyGeoghegan I wan to track my "/" root directory what can lead to interesting consequences in the future so the linked thread only partially answer my question. The other part: is it wise to use git for version controlling my config files still unanswered
– atevm
Feb 9 '16 at 13:44






1




1




@AnthonyGeoghegan thanks. I updated the question.
– atevm
Feb 9 '16 at 17:04




@AnthonyGeoghegan thanks. I updated the question.
– atevm
Feb 9 '16 at 17:04










3 Answers
3






active

oldest

votes

















up vote
14
down vote



accepted










The short answer to your question is Yes.





I wouldn’t hesitate to recommend Git (or any other version control software) to keep track of configuration files. Since doing so, I’ve been more productive (particularly for configuring new installations) and have greater confidence in my configuration files. With version control, I have a record of what changes were made and the commit message provides the reason why the change was made. If a change has unintended side effects, I can easily review the log/history to see what change caused the effects.



Personally, I’d be wary of tracking all files under the / root directory. The list of paths to ignore could become large and unwieldy. I prefer to keep each logical set of files in their own repository.



I manually use Git to keep track of my personal configuration / start-up files, e.g., Vim configuration, Bash functions, aliases, etc. – similar to the approach listed in How to track $HOME with git. I keep each set of files in their own repository and use symbolic links to the home directory.



For system configuration files, I use Git with Etckeeper to keep track of files in my /etc directory.



Drawbacks



One issue to be wary of is if the files being tracked include hard links. When Git is used to check out files or otherwise modify the working tree, it unlinks files and then recreates them. See Git, Dotfiles, and Hardlinks for a fuller explanation.



Etckeeper



Etckeeper can be used to keep a full history of changes made to /etc.
It tracks file metadata that revision control systems do not normally support,
but that is important for /etc, such as the permissions of /etc/shadow.



It hooks into package managers such as apt and yum and (in its default
configuration), runs pre- and post-installation so all changes to /etc are
tracked.



If a package is installed or removed, all uncommitted changes in /etc will be
committed before the package operation so that there are two commits:




  1. “saving uncommitted changes in /etc prior to yum run”

  2. “committing changes in /etc after yum run”


I’ve used it with Debian and Red Hat-based distributions and I know it
supports Arch package management. I can’t say how much automation it would
add to a Gentoo system but a package is available for
it.



It also supports pushing the configuration files to a remote repository
(which should, of course, be private).



Configuration



After installing the package you may need to configure it (/etc/etckeeper/etckeeper.conf), e.g., on Ubuntu systems the default version control system is changed from Git to Bazaar. You may also like to disable the daily auto-commits.



Daily autocommits



Changes can be automatically committed by a daily cron job. This can be annoying
as the repository can get cluttered with multiple automated commit messages.



I uncomment the appropriate line in /etc/etckeeper/etckeeper.conf:



sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf


Ignore certain files



Edit /etc/.gitignore to specify any files that shouldn’t be tracked.



First run



After configuring, run the following commands:



sudo etckeeper init
sudo etckeeper commit "Initial commit"


If your current directory is etc, you can run regular git commands, e.g.,



sudo git status
sudo git log





share|improve this answer



















  • 1




    Wow, it was very useful and detailed... thank you :)
    – atevm
    Feb 9 '16 at 15:37










  • Just to update a very well-written answer: etckeeper during daily commit will actually check first if /etc is "unclean", i.e., it has uncommitted files. If not, it won't commit. So if your commit log is full of daily commits, chances are there are files that changed daily that you haven't added to the .*ignore file :-)
    – pepoluan
    Aug 14 '16 at 16:51












  • Also, on Ubuntu it has this irksome tendency of immediately perform a bzr init--__-- ... I recommend always running etckeeper uninit -f after installation.
    – pepoluan
    Aug 14 '16 at 16:53












  • Note, that etckeeper is obviously no longer hosted on github. They use their own system on their homepage now. Probably some M$ aversion on side of the author. Personally I find that an unfortunate decision as now you can't easily report issues and can't see how popular the project is.
    – Michael Härtl
    Nov 15 at 11:13










  • Thanks @MichaelHärtl I've removed the outdated link to the GitHub repo.
    – Anthony Geoghegan
    Nov 16 at 10:21


















up vote
3
down vote













I use git to track specific areas of my home directory. Personally, I would not journey down the path of tracking the root directory, but I must say that I admire your ambition. :)



Perhaps this collection of experiences could provide you with a better idea of what you might be getting into:



effects of initializing git repository on linux root directory 3:)



Apologies for an "answer", instead of just throwing the link in a comment; however, not enough rep, but wished to chime in.



Edit



Wow! Very nice answer by @AnthonyGeoghegan. I am believing this is not as much of a struggle as I has originally envisioned it as.






share|improve this answer






























    up vote
    0
    down vote













    I also use git to store and maintain my dotfiles, but in a git bare repository. A detailed guide can be found here. I'm using two repositories, one for my users dotfiles named myconf and one for root's dotfiles named rootconf.



    Additionally you can use both configurations on many machines, different Linux Distributions or Virtual Machines: Just create a new branch for a distinct configuration. Then you avoid mixing up code in the same file (e.g. .bash_alias): No annoying if's to check the current machine any more; nore no links needed!






    share|improve this answer





















      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "3"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














       

      draft saved


      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1037211%2fis-it-a-good-idea-to-use-git-for-configuration-file-version-controlling%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      14
      down vote



      accepted










      The short answer to your question is Yes.





      I wouldn’t hesitate to recommend Git (or any other version control software) to keep track of configuration files. Since doing so, I’ve been more productive (particularly for configuring new installations) and have greater confidence in my configuration files. With version control, I have a record of what changes were made and the commit message provides the reason why the change was made. If a change has unintended side effects, I can easily review the log/history to see what change caused the effects.



      Personally, I’d be wary of tracking all files under the / root directory. The list of paths to ignore could become large and unwieldy. I prefer to keep each logical set of files in their own repository.



      I manually use Git to keep track of my personal configuration / start-up files, e.g., Vim configuration, Bash functions, aliases, etc. – similar to the approach listed in How to track $HOME with git. I keep each set of files in their own repository and use symbolic links to the home directory.



      For system configuration files, I use Git with Etckeeper to keep track of files in my /etc directory.



      Drawbacks



      One issue to be wary of is if the files being tracked include hard links. When Git is used to check out files or otherwise modify the working tree, it unlinks files and then recreates them. See Git, Dotfiles, and Hardlinks for a fuller explanation.



      Etckeeper



      Etckeeper can be used to keep a full history of changes made to /etc.
      It tracks file metadata that revision control systems do not normally support,
      but that is important for /etc, such as the permissions of /etc/shadow.



      It hooks into package managers such as apt and yum and (in its default
      configuration), runs pre- and post-installation so all changes to /etc are
      tracked.



      If a package is installed or removed, all uncommitted changes in /etc will be
      committed before the package operation so that there are two commits:




      1. “saving uncommitted changes in /etc prior to yum run”

      2. “committing changes in /etc after yum run”


      I’ve used it with Debian and Red Hat-based distributions and I know it
      supports Arch package management. I can’t say how much automation it would
      add to a Gentoo system but a package is available for
      it.



      It also supports pushing the configuration files to a remote repository
      (which should, of course, be private).



      Configuration



      After installing the package you may need to configure it (/etc/etckeeper/etckeeper.conf), e.g., on Ubuntu systems the default version control system is changed from Git to Bazaar. You may also like to disable the daily auto-commits.



      Daily autocommits



      Changes can be automatically committed by a daily cron job. This can be annoying
      as the repository can get cluttered with multiple automated commit messages.



      I uncomment the appropriate line in /etc/etckeeper/etckeeper.conf:



      sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf


      Ignore certain files



      Edit /etc/.gitignore to specify any files that shouldn’t be tracked.



      First run



      After configuring, run the following commands:



      sudo etckeeper init
      sudo etckeeper commit "Initial commit"


      If your current directory is etc, you can run regular git commands, e.g.,



      sudo git status
      sudo git log





      share|improve this answer



















      • 1




        Wow, it was very useful and detailed... thank you :)
        – atevm
        Feb 9 '16 at 15:37










      • Just to update a very well-written answer: etckeeper during daily commit will actually check first if /etc is "unclean", i.e., it has uncommitted files. If not, it won't commit. So if your commit log is full of daily commits, chances are there are files that changed daily that you haven't added to the .*ignore file :-)
        – pepoluan
        Aug 14 '16 at 16:51












      • Also, on Ubuntu it has this irksome tendency of immediately perform a bzr init--__-- ... I recommend always running etckeeper uninit -f after installation.
        – pepoluan
        Aug 14 '16 at 16:53












      • Note, that etckeeper is obviously no longer hosted on github. They use their own system on their homepage now. Probably some M$ aversion on side of the author. Personally I find that an unfortunate decision as now you can't easily report issues and can't see how popular the project is.
        – Michael Härtl
        Nov 15 at 11:13










      • Thanks @MichaelHärtl I've removed the outdated link to the GitHub repo.
        – Anthony Geoghegan
        Nov 16 at 10:21















      up vote
      14
      down vote



      accepted










      The short answer to your question is Yes.





      I wouldn’t hesitate to recommend Git (or any other version control software) to keep track of configuration files. Since doing so, I’ve been more productive (particularly for configuring new installations) and have greater confidence in my configuration files. With version control, I have a record of what changes were made and the commit message provides the reason why the change was made. If a change has unintended side effects, I can easily review the log/history to see what change caused the effects.



      Personally, I’d be wary of tracking all files under the / root directory. The list of paths to ignore could become large and unwieldy. I prefer to keep each logical set of files in their own repository.



      I manually use Git to keep track of my personal configuration / start-up files, e.g., Vim configuration, Bash functions, aliases, etc. – similar to the approach listed in How to track $HOME with git. I keep each set of files in their own repository and use symbolic links to the home directory.



      For system configuration files, I use Git with Etckeeper to keep track of files in my /etc directory.



      Drawbacks



      One issue to be wary of is if the files being tracked include hard links. When Git is used to check out files or otherwise modify the working tree, it unlinks files and then recreates them. See Git, Dotfiles, and Hardlinks for a fuller explanation.



      Etckeeper



      Etckeeper can be used to keep a full history of changes made to /etc.
      It tracks file metadata that revision control systems do not normally support,
      but that is important for /etc, such as the permissions of /etc/shadow.



      It hooks into package managers such as apt and yum and (in its default
      configuration), runs pre- and post-installation so all changes to /etc are
      tracked.



      If a package is installed or removed, all uncommitted changes in /etc will be
      committed before the package operation so that there are two commits:




      1. “saving uncommitted changes in /etc prior to yum run”

      2. “committing changes in /etc after yum run”


      I’ve used it with Debian and Red Hat-based distributions and I know it
      supports Arch package management. I can’t say how much automation it would
      add to a Gentoo system but a package is available for
      it.



      It also supports pushing the configuration files to a remote repository
      (which should, of course, be private).



      Configuration



      After installing the package you may need to configure it (/etc/etckeeper/etckeeper.conf), e.g., on Ubuntu systems the default version control system is changed from Git to Bazaar. You may also like to disable the daily auto-commits.



      Daily autocommits



      Changes can be automatically committed by a daily cron job. This can be annoying
      as the repository can get cluttered with multiple automated commit messages.



      I uncomment the appropriate line in /etc/etckeeper/etckeeper.conf:



      sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf


      Ignore certain files



      Edit /etc/.gitignore to specify any files that shouldn’t be tracked.



      First run



      After configuring, run the following commands:



      sudo etckeeper init
      sudo etckeeper commit "Initial commit"


      If your current directory is etc, you can run regular git commands, e.g.,



      sudo git status
      sudo git log





      share|improve this answer



















      • 1




        Wow, it was very useful and detailed... thank you :)
        – atevm
        Feb 9 '16 at 15:37










      • Just to update a very well-written answer: etckeeper during daily commit will actually check first if /etc is "unclean", i.e., it has uncommitted files. If not, it won't commit. So if your commit log is full of daily commits, chances are there are files that changed daily that you haven't added to the .*ignore file :-)
        – pepoluan
        Aug 14 '16 at 16:51












      • Also, on Ubuntu it has this irksome tendency of immediately perform a bzr init--__-- ... I recommend always running etckeeper uninit -f after installation.
        – pepoluan
        Aug 14 '16 at 16:53












      • Note, that etckeeper is obviously no longer hosted on github. They use their own system on their homepage now. Probably some M$ aversion on side of the author. Personally I find that an unfortunate decision as now you can't easily report issues and can't see how popular the project is.
        – Michael Härtl
        Nov 15 at 11:13










      • Thanks @MichaelHärtl I've removed the outdated link to the GitHub repo.
        – Anthony Geoghegan
        Nov 16 at 10:21













      up vote
      14
      down vote



      accepted







      up vote
      14
      down vote



      accepted






      The short answer to your question is Yes.





      I wouldn’t hesitate to recommend Git (or any other version control software) to keep track of configuration files. Since doing so, I’ve been more productive (particularly for configuring new installations) and have greater confidence in my configuration files. With version control, I have a record of what changes were made and the commit message provides the reason why the change was made. If a change has unintended side effects, I can easily review the log/history to see what change caused the effects.



      Personally, I’d be wary of tracking all files under the / root directory. The list of paths to ignore could become large and unwieldy. I prefer to keep each logical set of files in their own repository.



      I manually use Git to keep track of my personal configuration / start-up files, e.g., Vim configuration, Bash functions, aliases, etc. – similar to the approach listed in How to track $HOME with git. I keep each set of files in their own repository and use symbolic links to the home directory.



      For system configuration files, I use Git with Etckeeper to keep track of files in my /etc directory.



      Drawbacks



      One issue to be wary of is if the files being tracked include hard links. When Git is used to check out files or otherwise modify the working tree, it unlinks files and then recreates them. See Git, Dotfiles, and Hardlinks for a fuller explanation.



      Etckeeper



      Etckeeper can be used to keep a full history of changes made to /etc.
      It tracks file metadata that revision control systems do not normally support,
      but that is important for /etc, such as the permissions of /etc/shadow.



      It hooks into package managers such as apt and yum and (in its default
      configuration), runs pre- and post-installation so all changes to /etc are
      tracked.



      If a package is installed or removed, all uncommitted changes in /etc will be
      committed before the package operation so that there are two commits:




      1. “saving uncommitted changes in /etc prior to yum run”

      2. “committing changes in /etc after yum run”


      I’ve used it with Debian and Red Hat-based distributions and I know it
      supports Arch package management. I can’t say how much automation it would
      add to a Gentoo system but a package is available for
      it.



      It also supports pushing the configuration files to a remote repository
      (which should, of course, be private).



      Configuration



      After installing the package you may need to configure it (/etc/etckeeper/etckeeper.conf), e.g., on Ubuntu systems the default version control system is changed from Git to Bazaar. You may also like to disable the daily auto-commits.



      Daily autocommits



      Changes can be automatically committed by a daily cron job. This can be annoying
      as the repository can get cluttered with multiple automated commit messages.



      I uncomment the appropriate line in /etc/etckeeper/etckeeper.conf:



      sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf


      Ignore certain files



      Edit /etc/.gitignore to specify any files that shouldn’t be tracked.



      First run



      After configuring, run the following commands:



      sudo etckeeper init
      sudo etckeeper commit "Initial commit"


      If your current directory is etc, you can run regular git commands, e.g.,



      sudo git status
      sudo git log





      share|improve this answer














      The short answer to your question is Yes.





      I wouldn’t hesitate to recommend Git (or any other version control software) to keep track of configuration files. Since doing so, I’ve been more productive (particularly for configuring new installations) and have greater confidence in my configuration files. With version control, I have a record of what changes were made and the commit message provides the reason why the change was made. If a change has unintended side effects, I can easily review the log/history to see what change caused the effects.



      Personally, I’d be wary of tracking all files under the / root directory. The list of paths to ignore could become large and unwieldy. I prefer to keep each logical set of files in their own repository.



      I manually use Git to keep track of my personal configuration / start-up files, e.g., Vim configuration, Bash functions, aliases, etc. – similar to the approach listed in How to track $HOME with git. I keep each set of files in their own repository and use symbolic links to the home directory.



      For system configuration files, I use Git with Etckeeper to keep track of files in my /etc directory.



      Drawbacks



      One issue to be wary of is if the files being tracked include hard links. When Git is used to check out files or otherwise modify the working tree, it unlinks files and then recreates them. See Git, Dotfiles, and Hardlinks for a fuller explanation.



      Etckeeper



      Etckeeper can be used to keep a full history of changes made to /etc.
      It tracks file metadata that revision control systems do not normally support,
      but that is important for /etc, such as the permissions of /etc/shadow.



      It hooks into package managers such as apt and yum and (in its default
      configuration), runs pre- and post-installation so all changes to /etc are
      tracked.



      If a package is installed or removed, all uncommitted changes in /etc will be
      committed before the package operation so that there are two commits:




      1. “saving uncommitted changes in /etc prior to yum run”

      2. “committing changes in /etc after yum run”


      I’ve used it with Debian and Red Hat-based distributions and I know it
      supports Arch package management. I can’t say how much automation it would
      add to a Gentoo system but a package is available for
      it.



      It also supports pushing the configuration files to a remote repository
      (which should, of course, be private).



      Configuration



      After installing the package you may need to configure it (/etc/etckeeper/etckeeper.conf), e.g., on Ubuntu systems the default version control system is changed from Git to Bazaar. You may also like to disable the daily auto-commits.



      Daily autocommits



      Changes can be automatically committed by a daily cron job. This can be annoying
      as the repository can get cluttered with multiple automated commit messages.



      I uncomment the appropriate line in /etc/etckeeper/etckeeper.conf:



      sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf


      Ignore certain files



      Edit /etc/.gitignore to specify any files that shouldn’t be tracked.



      First run



      After configuring, run the following commands:



      sudo etckeeper init
      sudo etckeeper commit "Initial commit"


      If your current directory is etc, you can run regular git commands, e.g.,



      sudo git status
      sudo git log






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Nov 16 at 10:19

























      answered Feb 9 '16 at 14:59









      Anthony Geoghegan

      2,7281330




      2,7281330








      • 1




        Wow, it was very useful and detailed... thank you :)
        – atevm
        Feb 9 '16 at 15:37










      • Just to update a very well-written answer: etckeeper during daily commit will actually check first if /etc is "unclean", i.e., it has uncommitted files. If not, it won't commit. So if your commit log is full of daily commits, chances are there are files that changed daily that you haven't added to the .*ignore file :-)
        – pepoluan
        Aug 14 '16 at 16:51












      • Also, on Ubuntu it has this irksome tendency of immediately perform a bzr init--__-- ... I recommend always running etckeeper uninit -f after installation.
        – pepoluan
        Aug 14 '16 at 16:53












      • Note, that etckeeper is obviously no longer hosted on github. They use their own system on their homepage now. Probably some M$ aversion on side of the author. Personally I find that an unfortunate decision as now you can't easily report issues and can't see how popular the project is.
        – Michael Härtl
        Nov 15 at 11:13










      • Thanks @MichaelHärtl I've removed the outdated link to the GitHub repo.
        – Anthony Geoghegan
        Nov 16 at 10:21














      • 1




        Wow, it was very useful and detailed... thank you :)
        – atevm
        Feb 9 '16 at 15:37










      • Just to update a very well-written answer: etckeeper during daily commit will actually check first if /etc is "unclean", i.e., it has uncommitted files. If not, it won't commit. So if your commit log is full of daily commits, chances are there are files that changed daily that you haven't added to the .*ignore file :-)
        – pepoluan
        Aug 14 '16 at 16:51












      • Also, on Ubuntu it has this irksome tendency of immediately perform a bzr init--__-- ... I recommend always running etckeeper uninit -f after installation.
        – pepoluan
        Aug 14 '16 at 16:53












      • Note, that etckeeper is obviously no longer hosted on github. They use their own system on their homepage now. Probably some M$ aversion on side of the author. Personally I find that an unfortunate decision as now you can't easily report issues and can't see how popular the project is.
        – Michael Härtl
        Nov 15 at 11:13










      • Thanks @MichaelHärtl I've removed the outdated link to the GitHub repo.
        – Anthony Geoghegan
        Nov 16 at 10:21








      1




      1




      Wow, it was very useful and detailed... thank you :)
      – atevm
      Feb 9 '16 at 15:37




      Wow, it was very useful and detailed... thank you :)
      – atevm
      Feb 9 '16 at 15:37












      Just to update a very well-written answer: etckeeper during daily commit will actually check first if /etc is "unclean", i.e., it has uncommitted files. If not, it won't commit. So if your commit log is full of daily commits, chances are there are files that changed daily that you haven't added to the .*ignore file :-)
      – pepoluan
      Aug 14 '16 at 16:51






      Just to update a very well-written answer: etckeeper during daily commit will actually check first if /etc is "unclean", i.e., it has uncommitted files. If not, it won't commit. So if your commit log is full of daily commits, chances are there are files that changed daily that you haven't added to the .*ignore file :-)
      – pepoluan
      Aug 14 '16 at 16:51














      Also, on Ubuntu it has this irksome tendency of immediately perform a bzr init--__-- ... I recommend always running etckeeper uninit -f after installation.
      – pepoluan
      Aug 14 '16 at 16:53






      Also, on Ubuntu it has this irksome tendency of immediately perform a bzr init--__-- ... I recommend always running etckeeper uninit -f after installation.
      – pepoluan
      Aug 14 '16 at 16:53














      Note, that etckeeper is obviously no longer hosted on github. They use their own system on their homepage now. Probably some M$ aversion on side of the author. Personally I find that an unfortunate decision as now you can't easily report issues and can't see how popular the project is.
      – Michael Härtl
      Nov 15 at 11:13




      Note, that etckeeper is obviously no longer hosted on github. They use their own system on their homepage now. Probably some M$ aversion on side of the author. Personally I find that an unfortunate decision as now you can't easily report issues and can't see how popular the project is.
      – Michael Härtl
      Nov 15 at 11:13












      Thanks @MichaelHärtl I've removed the outdated link to the GitHub repo.
      – Anthony Geoghegan
      Nov 16 at 10:21




      Thanks @MichaelHärtl I've removed the outdated link to the GitHub repo.
      – Anthony Geoghegan
      Nov 16 at 10:21












      up vote
      3
      down vote













      I use git to track specific areas of my home directory. Personally, I would not journey down the path of tracking the root directory, but I must say that I admire your ambition. :)



      Perhaps this collection of experiences could provide you with a better idea of what you might be getting into:



      effects of initializing git repository on linux root directory 3:)



      Apologies for an "answer", instead of just throwing the link in a comment; however, not enough rep, but wished to chime in.



      Edit



      Wow! Very nice answer by @AnthonyGeoghegan. I am believing this is not as much of a struggle as I has originally envisioned it as.






      share|improve this answer



























        up vote
        3
        down vote













        I use git to track specific areas of my home directory. Personally, I would not journey down the path of tracking the root directory, but I must say that I admire your ambition. :)



        Perhaps this collection of experiences could provide you with a better idea of what you might be getting into:



        effects of initializing git repository on linux root directory 3:)



        Apologies for an "answer", instead of just throwing the link in a comment; however, not enough rep, but wished to chime in.



        Edit



        Wow! Very nice answer by @AnthonyGeoghegan. I am believing this is not as much of a struggle as I has originally envisioned it as.






        share|improve this answer

























          up vote
          3
          down vote










          up vote
          3
          down vote









          I use git to track specific areas of my home directory. Personally, I would not journey down the path of tracking the root directory, but I must say that I admire your ambition. :)



          Perhaps this collection of experiences could provide you with a better idea of what you might be getting into:



          effects of initializing git repository on linux root directory 3:)



          Apologies for an "answer", instead of just throwing the link in a comment; however, not enough rep, but wished to chime in.



          Edit



          Wow! Very nice answer by @AnthonyGeoghegan. I am believing this is not as much of a struggle as I has originally envisioned it as.






          share|improve this answer














          I use git to track specific areas of my home directory. Personally, I would not journey down the path of tracking the root directory, but I must say that I admire your ambition. :)



          Perhaps this collection of experiences could provide you with a better idea of what you might be getting into:



          effects of initializing git repository on linux root directory 3:)



          Apologies for an "answer", instead of just throwing the link in a comment; however, not enough rep, but wished to chime in.



          Edit



          Wow! Very nice answer by @AnthonyGeoghegan. I am believing this is not as much of a struggle as I has originally envisioned it as.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited May 23 '17 at 11:33









          Community

          1




          1










          answered Feb 9 '16 at 14:33









          Michael Stilson

          1315




          1315






















              up vote
              0
              down vote













              I also use git to store and maintain my dotfiles, but in a git bare repository. A detailed guide can be found here. I'm using two repositories, one for my users dotfiles named myconf and one for root's dotfiles named rootconf.



              Additionally you can use both configurations on many machines, different Linux Distributions or Virtual Machines: Just create a new branch for a distinct configuration. Then you avoid mixing up code in the same file (e.g. .bash_alias): No annoying if's to check the current machine any more; nore no links needed!






              share|improve this answer

























                up vote
                0
                down vote













                I also use git to store and maintain my dotfiles, but in a git bare repository. A detailed guide can be found here. I'm using two repositories, one for my users dotfiles named myconf and one for root's dotfiles named rootconf.



                Additionally you can use both configurations on many machines, different Linux Distributions or Virtual Machines: Just create a new branch for a distinct configuration. Then you avoid mixing up code in the same file (e.g. .bash_alias): No annoying if's to check the current machine any more; nore no links needed!






                share|improve this answer























                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  I also use git to store and maintain my dotfiles, but in a git bare repository. A detailed guide can be found here. I'm using two repositories, one for my users dotfiles named myconf and one for root's dotfiles named rootconf.



                  Additionally you can use both configurations on many machines, different Linux Distributions or Virtual Machines: Just create a new branch for a distinct configuration. Then you avoid mixing up code in the same file (e.g. .bash_alias): No annoying if's to check the current machine any more; nore no links needed!






                  share|improve this answer












                  I also use git to store and maintain my dotfiles, but in a git bare repository. A detailed guide can be found here. I'm using two repositories, one for my users dotfiles named myconf and one for root's dotfiles named rootconf.



                  Additionally you can use both configurations on many machines, different Linux Distributions or Virtual Machines: Just create a new branch for a distinct configuration. Then you avoid mixing up code in the same file (e.g. .bash_alias): No annoying if's to check the current machine any more; nore no links needed!







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Oct 31 at 18:21









                  Chris

                  1




                  1






























                       

                      draft saved


                      draft discarded



















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1037211%2fis-it-a-good-idea-to-use-git-for-configuration-file-version-controlling%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      AnyDesk - Fatal Program Failure

                      How to calibrate 16:9 built-in touch-screen to a 4:3 resolution?

                      QoS: MAC-Priority for clients behind a repeater