My use case:

I want to store /etc directory content in git to:
- keep backup of server settings
- keep change history
- easily restore previous state in case of wrong changes
- edit the /etc settings locally on Windows, then push to Linux/Debian

I missed change history especially when modified Apache, mysql, cron
settings, doing fine tuning of them. Also when upgrading Debian, it may do
config changes, what I would like to follow or even restore.

Furthermore, I have 2 servers:
1) local Vmware virtual Debian server, where I commit developments & tests
2) production Debian server
So I in Git i would have two remote repos, between them I can merge some
changes, which have been approved to work on test server.
3) A Windows 7 work machine, where the real development, editing is done.
I have one repo here, which have two remotes, local/master and live/master.
Using Git Extensions for Windows git client & git command line. Also using
Git v2.4.0.

This is the complex situation.

If there would be no iscsi drive used on production server and no Windows
machine used as work machine, then the whole solution would be working

 2015.06.19. 22:10 ezt írta ("Konstantin Khomoutov" <>):

> On Fri, 19 Jun 2015 21:08:00 +0200
> Konrád Lőrinczi <> wrote:
> > Thanks very much for your answer!
> > It is really a deeply technical answer.
> > Maybe are you one of developers of GIT?
> Thanks!  No, I'm a mere enthusiast.
> [...]
> > As for bare repo it doesn't make possible to edit under Windows, then
> > checkout under Debian.
> >
> > As for the git sparse checkout it is a good idea, but I'm afraid,
> > that if I ignore iscsi/nodes path, then this will be OK for Windows,
> > but on Debian, in case of a data loss & need of restore, these files
> > will be not checked out and restored.
> I don't really understand.
> One only ever need to check files out if one intends to read them or
> modify them (typicall to record another commit).  Well, if you only
> need to read files you don't actually have to check them out -- it's
> just convenient.
> In other words, the work tree in a regular (non-bare) repository
> files whose contents are *copies* of objects actually stored in the Git
> repository.  To say it differently, the work tree is completely
> redundant with regard to the repository.  That's why bare repos
> (those used for collaboration) do not have any work tree attached to
> them (so nothing is ever checked out of them) and yet they perfectly
> store all the history pushed into them.
> > Both are partially good solutions, but not fully perfect.
> I'm afraid your problem is a red herring.
> You only need to check those file out if you intend to *edit* them and
> then create a new commit.  While I might fathom a reason for this,
> it still appears that the repo produced by etckeeper is to be backed
> up, not modified.  To do this, all you need is to just clone your
> etckeeper repo to a *bare* repository once and then periodically fetch
> new stuff there.
> > Should I send the use case to the git developer list?
> I dunno.  Let's figure out what's your actual use case first.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to