From: Jakub Narebski <jnareb@gmail.com>
To: Gerhard Wiesinger <lists@wiesinger.com>
Cc: Andreas Ericsson <ae@op5.se>, git@vger.kernel.org
Subject: Re: Metadata and checkin file date
Date: Tue, 27 Apr 2010 14:25:15 -0700 (PDT) [thread overview]
Message-ID: <m3k4rsd1x2.fsf@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.00.1004272152190.11216@bbs.intern>
Gerhard Wiesinger <lists@wiesinger.com> writes:
> On Tue, 27 Apr 2010, Andreas Ericsson wrote:
>> On 04/27/2010 09:38 PM, Gerhard Wiesinger wrote:
>>> On Tue, 27 Apr 2010, Andreas Ericsson wrote:
>>>> On 04/27/2010 07:23 AM, Gerhard Wiesinger wrote:
>>>>> b.) rights (basic: chmod, chow, chgrp, extended: extended attributes
>>>>> like ACLs and selinux), necessary for versioning e.g. /etc
>>>>
>>>> Sounds like you want a backup-program. Some projects have been
>>>> aimed towards this goal already. [...]. AFAIR, most of them work
>>>> with two hook-scripts that update a regular file with the
>>>> meta-data of all tracked files. [...]
>>>>
>>>> Adding it to core git would mean re-designing git's basic data
>>>> model, which is obviously not something we're about to do on
>>>> a whim.
>>>
>>> No, I'm NOT looking for a backup program. Every admin has the problem of
>>> versioning config files (for example /etc). Versioning of config files
>>> makes sense because one can track the changes and e.g. correlate to
>>> problems. A backup program doesn't have features like history, committer
>>> and comments on file changes. Therefore git would be a perfect tool also
>>> for versioning configuration. (Software development doesn't end with the
>>> build but typically also has deployment&configuration issues).
See IsiSetup, etckeeper and other such tools.
[...]
>> In short: What you want can be (and has been) done, but it's written
>> as addons and not integral parts of git.
>
> A first quick look on them: They are only a workaround to the real
> problem. For example subversion therefore has generic properties which
> also can be user defined (e.g. svn propset/propget) and I think such a
> concept should also be integrated part of git.
>
> Only my 2 cents making git (one of the SCM where I think it is very
> powerful and has also potential in the future) even better than
> competition.
Actually using *properties* is one of MIS-designs of Subversion.
Storing generic sh*t in repository is not a good idea either.
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2010-04-27 21:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-27 5:23 Metadata and checkin file date Gerhard Wiesinger
2010-04-27 9:22 ` Andreas Ericsson
2010-04-27 19:38 ` Gerhard Wiesinger
2010-04-27 19:47 ` Andreas Ericsson
2010-04-27 20:00 ` Gerhard Wiesinger
2010-04-27 21:25 ` Jakub Narebski [this message]
2010-04-27 21:18 ` Jakub Narebski
2010-04-27 9:35 ` Jakub Narebski
2010-04-27 19:41 ` Gerhard Wiesinger
2010-04-27 20:55 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3k4rsd1x2.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=lists@wiesinger.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.