Re: /etc in git?

Ryan Anderson [off-list ref] writes:

Junio C Hamano wrote:

quoted

Adam Hunt [off-list ref] writes:

quoted

Do you have any more details by chance?  Does it work?  Does it work
well?  How does one do it?

I personally feel it is a horrible and stupid thing to do, if by
"version control /etc" you mean to have /.git which controls
/etc/hosts and stuff in place.  It would work (git does not
refuse to run as root).  But being a *source* control system, we
deliberately refuse to store the full permission bits, so if
your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
have to make sure they stay that way after checking things out.

This is, admittedly, a major problem.

An SCM is not a replacement of a backup.

quoted

You are much better off to keep /usr/src/rootstuff/.git (and
working tree files are /usr/src/rootstuff/etc/hosts and
friends), have a build procedure (read: Makefile) there, and
version control that source directory.  I usually have 'install'
and 'diff' target in that Makefile, so that I can do this:
... 

If you're doing this, especially if you're doing this on multiple
machines, creating a package is probably a worthwhile thing to
contemplate as well.

In my workplace environment, the equivalent of the above
/usr/src/rootstuff is accessible throughout the networked
machines (mostly NFS mounted); for things that needs per-host
customization, we do not have /usr/src/rootstuff/etc/hosts but
keep /usr/src/rootstuff/etc/hosts.in as the source, and Makefile
customizes that into a form suitable for installation for each
machine.  Especially useful is vfstab.in --- a single source
builds fstab for local mounting and nfs exports, while other
machines have mountpoints and project symlinks pointing into
location automounted from that machine with disk, generated
automatically.  This does not match typical "package" use.

Dear diary, on Thu, Jan 19, 2006 at 08:50:22AM CET, I got a letter
where Junio C Hamano [off-list ref] said that...

Ryan Anderson [off-list ref] writes:

quoted

Junio C Hamano wrote:

quoted

Adam Hunt [off-list ref] writes:

quoted

Do you have any more details by chance?  Does it work?  Does it work
well?  How does one do it?

I personally feel it is a horrible and stupid thing to do, if by
"version control /etc" you mean to have /.git which controls
/etc/hosts and stuff in place.  It would work (git does not
refuse to run as root).  But being a *source* control system, we
deliberately refuse to store the full permission bits, so if
your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
have to make sure they stay that way after checking things out.

This is, admittedly, a major problem.

An SCM is not a replacement of a backup.

It seems that this is mostly an artificial imposition and it's annoying.
Hey, I need to leave for an exam in 15 minutes and I have few urgent
items in my Cogito TODO (sorry, Pavel!), but I couldn't resist.

Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
attitude to testing and documentation... ;-)

diff --git a/cache.h b/cache.h
index 29c9e81..0311066 100644
--- a/cache.h
+++ b/cache.h

@@ -94,7 +94,9 @@ struct cache_entry {
 #define ce_size(ce) cache_entry_size(ce_namelen(ce))
 #define ce_stage(ce) ((CE_STAGEMASK & ntohs((ce)->ce_flags)) >> CE_STAGESHIFT)
 
-#define ce_permissions(mode) (((mode) & 0100) ? 0755 : 0644)
+extern int track_filemode;
+
+#define ce_permissions(mode) (track_filemode ? (mode) : (((mode) & 0100) ? 0755 : 0644))
 static inline unsigned int create_ce_mode(unsigned int mode)
 {
 	if (S_ISLNK(mode))

diff --git a/checkout-index.c b/checkout-index.c
index 53dd8cb..b073baa 100644
--- a/checkout-index.c
+++ b/checkout-index.c

@@ -115,6 +115,8 @@ int main(int argc, char **argv)
 	int newfd = -1;
 	int all = 0;
 
+	git_config(git_default_config);
+
 	prefix = setup_git_directory();
 	prefix_length = prefix ? strlen(prefix) : 0;
 

diff --git a/config.c b/config.c
index 8355224..a92ee0f 100644
--- a/config.c
+++ b/config.c

@@ -222,6 +222,11 @@ int git_default_config(const char *var, 
 		return 0;
 	}
 
+	if (!strcmp(var, "core.trackallfilemodes")) {
+		track_filemode = git_config_bool(var, value);
+		return 0;
+	}
+
 	if (!strcmp(var, "core.symrefsonly")) {
 		only_use_symrefs = git_config_bool(var, value);
 		return 0;

diff --git a/entry.c b/entry.c
index 410b758..493f2b9 100644
--- a/entry.c
+++ b/entry.c

@@ -87,6 +87,11 @@ static int write_entry(struct cache_entr
 			return error("git-checkout-index: unable to create file %s (%s)",
 				path, strerror(errno));
 		}
+		if (track_filemode) {
+			if (fchmod(fd, ntohl(ce->ce_mode)) < 0)
+				return error("git-checkout-index: unable to chmod file %s (%s)",
+					path, strerror(errno));
+		}
 		wrote = write(fd, new, size);
 		close(fd);
 		free(new);

diff --git a/environment.c b/environment.c
index 0596fc6..53248ec 100644
--- a/environment.c
+++ b/environment.c

@@ -12,6 +12,7 @@
 char git_default_email[MAX_GITNAME];
 char git_default_name[MAX_GITNAME];
 int trust_executable_bit = 1;
+int track_filemode = 0;
 int only_use_symrefs = 0;
 int repository_format_version = 0;
 char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";

diff --git a/fsck-objects.c b/fsck-objects.c
index 90e638e..719add2 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c

@@ -174,7 +174,8 @@ static int fsck_tree(struct tree *item)
 			if (!check_strict)
 				break;
 		default:
-			has_bad_modes = 1;
+			if (!track_filemode || (entry->mode & ~(S_IFREG|0777)))
+				has_bad_modes = 1;
 		}
 
 		if (last) {

diff --git a/read-cache.c b/read-cache.c
index c5474d4..624d2c3 100644
--- a/read-cache.c
+++ b/read-cache.c

@@ -98,7 +98,7 @@ static int ce_match_stat_basic(struct ca
 		 * "mode changes"
 		 */
 		if (trust_executable_bit &&
-		    (0100 & (ntohl(ce->ce_mode) ^ st->st_mode)))
+		    ((track_filemode ? 0777 : 0100) & (ntohl(ce->ce_mode) ^ st->st_mode)))
 			changed |= MODE_CHANGED;
 		break;
 	case S_IFLNK:

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Petr Baudis [off-list ref] writes:

Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
attitude to testing and documentation... ;-)

It is premature for us mere mortals to imitate Linus in that
aspect by at least ten years ;-).  Please don't.

About the content of the change, if we were to do this, we need
to also record owner and group. recording full permissions
without recording owner and group does not make much sense.

Dear diary, on Thu, Jan 19, 2006 at 07:25:03PM CET, I got a letter
where Junio C Hamano [off-list ref] said that...

Petr Baudis [off-list ref] writes:

quoted

Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
attitude to testing and documentation... ;-)

It is premature for us mere mortals to imitate Linus in that
aspect by at least ten years ;-).  Please don't.

Yes, it was really just kind of proof-of-concept patch.

About the content of the change, if we were to do this, we need
to also record owner and group. recording full permissions
without recording owner and group does not make much sense.

This would require much larger changes to the tree structure while we
can get this essentially for free and I believe it covers most of the
usage scenarios. In my /etc, all but two files are owned by root.root,
and in my ~, all the dot-files are owned by pasky.users, while the
permissions are a lot more varied.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Junio C Hamano wrote:

Ryan Anderson [off-list ref] writes:
 

quoted

Junio C Hamano wrote:
   

quoted

You are much better off to keep /usr/src/rootstuff/.git (and
working tree files are /usr/src/rootstuff/etc/hosts and
friends), have a build procedure (read: Makefile) there, and
version control that source directory.  I usually have 'install'
and 'diff' target in that Makefile, so that I can do this:
... 
     

If you're doing this, especially if you're doing this on multiple
machines, creating a package is probably a worthwhile thing to
contemplate as well.
   

In my workplace environment, the equivalent of the above
/usr/src/rootstuff is accessible throughout the networked
machines (mostly NFS mounted); for things that needs per-host
customization, we do not have /usr/src/rootstuff/etc/hosts but
keep /usr/src/rootstuff/etc/hosts.in as the source, and Makefile
customizes that into a form suitable for installation for each
machine.  Especially useful is vfstab.in --- a single source
builds fstab for local mounting and nfs exports, while other
machines have mountpoints and project symlinks pointing into
location automounted from that machine with disk, generated
automatically.  This does not match typical "package" use.
 

To provide an off-topic, but perhaps useful, counter-example, where I
work, I've made a package that does something similar.

I use a Makefile to generate a few template files, such as
/etc/resolv.conf, /etc/apt/preferences, /etc/sudoers, /etc/ntp.conf
It Pre-Depends on, ntp, sudo, (etc).

A postinstallation script does a little bit of tweaking of these files
based upon the answers to one or two questions asked during installation.

It's simply another way of looking at the problem.

-- 

Ryan Anderson
  sometimes Pug Majere

2006/1/19, Petr Baudis [off-list ref]:

I didn't test the patch, but the feature the patch tries to implement
is really something I'm missing from git (or any other scm I know of).
Ideally, this will be combined with exact owner tracking, but exact
permission and/or owner handling should be activated independently per
repository.

Peter Baumann

On 1/19/06, Junio C Hamano [off-list ref] wrote:

Petr Baudis [off-list ref] writes:

quoted

Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
attitude to testing and documentation... ;-)

It is premature for us mere mortals to imitate Linus in that
aspect by at least ten years ;-).  Please don't.

About the content of the change, if we were to do this, we need
to also record owner and group. recording full permissions
without recording owner and group does not make much sense.

Maybe implement tracking of a generic file attribute would be a better idea?
So that porcellans can implement permissions/ownership/EA themselves,
if they really want to...