[PATCH] Introduce SHA1_FILE_DIRECTORIES

[PATCH] Introduce SHA1_FILE_DIRECTORIES

[Junio C Hamano]

A new environment variable, SHA1_FILE_DIRECTORIES, is
introduced.  This affects the routines that read existing
objects from the object database, but not creation of new
objects.

The environment variable, when exists, is a colon separated list of
directories.  If an object is not found in the usual location
SHA1_FILE_DIRECTORY (or .git/objects), this list is consulted and if
object is found there it is returned.

This is an implementation of the idea floated on the GIT list a couple
of days ago to archive really old history on a separate directory, even
on a read-only DVD ROM media.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

cache.h     |    5 +-
sha1_file.c |  113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 112 insertions(+), 6 deletions(-)

--- a/cache.h
+++ b/cache.h
@@ -101,8 +101,7 @@ unsigned int active_nr, active_alloc;
 
 #define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
 #define DEFAULT_DB_ENVIRONMENT ".git/objects"
-
-#define get_object_directory() (getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
+#define ALTERNATE_DB_ENVIRONMENT "SHA1_FILE_DIRECTORIES"
 
 #define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
 #define DEFAULT_INDEX_ENVIRONMENT ".git/index"
@@ -130,7 +129,7 @@ extern int index_fd(unsigned char *sha1,
 #define DATA_CHANGED    0x0020
 #define TYPE_CHANGED    0x0040
 
-/* Return a statically allocated filename matching the sha1 signature */
+/* Return a statically allocated filename matching the sha1 signature. */
 extern char *sha1_file_name(const unsigned char *sha1);
 
 /* Read and unpack a sha1 file into memory, write memory to a sha1 file */
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -100,10 +100,19 @@ char * sha1_to_hex(const unsigned char *
 	return buffer;
 }
 
+static const char *get_object_directory(void)
+{
+	return getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
+}
+
 /*
  * NOTE! This returns a statically allocated buffer, so you have to be
  * careful about using it. Do a "strdup()" if you need to save the
  * filename.
+ *
+ * Also note that this returns the location for creating.  Reading
+ * SHA1 file can happen from any alternate directory listed in the
+ * SHA1_FILE_DIRECTORIES environment variable.
  */
 char *sha1_file_name(const unsigned char *sha1)
 {
@@ -130,6 +139,99 @@ char *sha1_file_name(const unsigned char
 	return base;
 }
 
+static char *find_sha1_file(const unsigned char *sha1)
+{
+	struct stat st;
+	char *name = sha1_file_name(sha1);
+	static struct {
+		int pfxlen;
+		char *buf;
+	} *alternates = NULL;
+	static int num_alt = -1;
+	int i;
+
+	if (num_alt < 0) {
+		int cnt;
+		int totlen;
+		const char *cp, *last;
+		const char *alt = getenv(ALTERNATE_DB_ENVIRONMENT);
+		void *buf;
+		char *op;
+
+		if (!alt || !alt[0]) {
+			num_alt = 0;
+			return name;
+		}
+
+		for (last = cp = alt, totlen = cnt = 0; *cp; cp++) {
+			/* We could strip the empty path which would result
+			 * in /xx/xxxxx from the filesystem root level,
+			 * but who cares.  We are only constructing list of
+			 * paths to attempt to read not write.
+			 */
+			if (*cp == ':') {
+				/* 40 bytes plus two / and terminating NUL */
+				totlen += cp - last + 43;
+				cnt++;
+				last = cp + 1;
+			}
+		}
+		if (cp != last) {
+			totlen += cp - last + 43;
+			cnt++;
+		}
+
+		if (!cnt) {
+			num_alt = 0;
+			return name;
+		}
+		num_alt = cnt;
+
+		buf = xmalloc(sizeof(*alternates) * (cnt + 1) + totlen);
+		alternates = buf;
+		alternates[num_alt].pfxlen = 0;
+		alternates[num_alt].buf = NULL;
+		op = (char*) (&alternates[cnt+1]);
+		for (last = cp = alt, i = 0; i < num_alt; cp++) {
+			if (*cp == ':' || *cp == 0) {
+				alternates[i].buf = op;
+				alternates[i].pfxlen = cp - last;
+				memcpy(op, last, cp - last);
+				op[cp - last] = 0;
+				op += (cp - last + 1);
+				last = cp + 1;
+				i++;
+			}
+		}
+		if (cp != last) {
+			alternates[i].buf = op;
+			alternates[i].pfxlen = last - cp;
+			memcpy(op, last, last - cp);
+			op[last-cp] = 0;
+		}
+	}
+	if (!stat(name, &st))
+		return name;
+	for (i = 0; i < num_alt; i++) {
+		char *alt = alternates[i].buf;
+		int len = alternates[i].pfxlen;
+		char *name = alt + len;
+		alt[len] = '/';
+		alt[len+3] = '/';
+		name = alt + len + 1;
+		for (i = 0; i < 20; i++) {
+			static char hex[] = "0123456789abcdef";
+			unsigned int val = sha1[i];
+			char *pos = name + i*2 + (i > 0);
+			*pos++ = hex[val >> 4];
+			*pos = hex[val & 0xf];
+		}
+		if (!stat(alt, &st))
+			return alt;
+	}
+	return NULL;
+}
+
 int check_sha1_signature(unsigned char *sha1, void *map, unsigned long size, const char *type)
 {
 	char header[100];
@@ -145,10 +247,14 @@ int check_sha1_signature(unsigned char *
 
 void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
 {
-	char *filename = sha1_file_name(sha1);
 	struct stat st;
 	void *map;
 	int fd;
+	char *filename = find_sha1_file(sha1);
+	if (!filename) {
+		error("cannot map sha1 file %s", sha1_to_hex(sha1));
+		return NULL;
+	}
 
 	fd = open(filename, O_RDONLY | sha1_file_open_flag);
 	if (fd < 0) {
@@ -442,8 +548,10 @@ int write_sha1_from_fd(const unsigned ch
 
 int has_sha1_file(const unsigned char *sha1)
 {
-	char *filename = sha1_file_name(sha1);
 	struct stat st;
+	char *filename = find_sha1_file(sha1);
+	if (!filename)
+		return 0;
 
 	if (!stat(filename, &st))
 		return 1;
----------------------------------------------------------------

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[Sean]

On Fri, May 6, 2005 7:35 pm, Junio C Hamano said:

Hi Junio,

> This is an implementation of the idea floated on the GIT list a couple
> of days ago to archive really old history on a separate directory, even
> on a read-only DVD ROM media.

David Lang should get the credit for the idea.

>  int has_sha1_file(const unsigned char *sha1)
>  {
> -	char *filename = sha1_file_name(sha1);
>  	struct stat st;
> +	char *filename = find_sha1_file(sha1);
> +	if (!filename)
> +		return 0;
>
>  	if (!stat(filename, &st))
>  		return 1;

has_sha1_file can be reduced to:


int has_sha1_file(const unsigned char *sha1)
{
       return (!!find_sha1_file(sha1));
}


Sean

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[Junio C Hamano]

>>>>> "S" == Sean  <seanlkml@sympatico.ca> writes:

S> has_sha1_file can be reduced to:

S> int has_sha1_file(const unsigned char *sha1)
S> {
S>        return (!!find_sha1_file(sha1));
S> }

Not really.  If you do not have alternates it does not even
bother to stat so you get the path that supposed to contain the
data and you need to do the checking yourself.

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[Sean]

On Fri, May 6, 2005 8:24 pm, Junio C Hamano said:
>>>>>> "S" == Sean  <seanlkml@sympatico.ca> writes:
>
> S> has_sha1_file can be reduced to:
>
> S> int has_sha1_file(const unsigned char *sha1)
> S> {
> S>        return (!!find_sha1_file(sha1));
> S> }
>
> Not really.  If you do not have alternates it does not even
> bother to stat so you get the path that supposed to contain the
> data and you need to do the checking yourself.
>
>

Perhaps I'm just missing something in your code, but this fragment makes
it look to me that stat is always called in find_sha1_file even when there
are no alternates:

+        char *name = sha1_file_name(sha1);
[...]
+        if (!stat(name, &st))
+                return name;
+        for (i = 0; i < num_alt; i++) {


Sean

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[Junio C Hamano]

>>>>> "S" == Sean  <seanlkml@sympatico.ca> writes:

S> Perhaps I'm just missing something in your code,...

Yes you are.  You have spotted a very inconvenient inconsistency
in the interface to the code.

Only on the very first time when it tries to constructs the
alternate directory list, and if there is no alternate list, it
just returns the name without stat(), which forces the callers
to do stat() themselves all the time.  I think I should make it
always stat, since the reading side needs do it anyway.

Thankfully I think Linus had rejected this part in the series.
I'll fix it up.

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[Junio C Hamano]

>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
>>>>> "S" == Sean  <seanlkml@sympatico.ca> writes:

S> Perhaps I'm just missing something in your code,...
JCH> Thankfully I think Linus had rejected this part in the series.
JCH> I'll fix it up.

Here is the fixed one.  The previous one was ugly and
inconvenient to use (thanks for noticing, Sean).

I'll keep it in the git-jc repository until Linus returns.

------------

Author: Junio C Hamano <junkio@cox.net>
Date:   Sat May 7 00:38:04 2005 -0700
    
Introduce SHA1_FILE_DIRECTORIES to support multiple object databases.

SHA1_FILE_DIRECTORIES environment variable is a colon separated paths
used when looking for SHA1 files not found in the usual place for
reading.  Creating a new SHA1 file does not use this alternate object
database location mechanism.  This is useful to archive older, rarely
used objects into separate directories.

Signed-off-by: Junio C Hamano <junkio@cox.net>

--- a/cache.h
+++ b/cache.h
@@ -101,6 +101,7 @@ unsigned int active_nr, active_alloc, ac
 
 #define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
 #define DEFAULT_DB_ENVIRONMENT ".git/objects"
+#define ALTERNATE_DB_ENVIRONMENT "SHA1_FILE_DIRECTORIES"
 
 #define get_object_directory() (getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
 
--- a/fsck-cache.c
+++ b/fsck-cache.c
@@ -306,7 +306,7 @@ int main(int argc, char **argv)
 			usage("fsck-cache [--tags] [[--unreachable] [--cache] <head-sha1>*]");
 	}
 
-	sha1_dir = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
+	sha1_dir = get_object_directory();
 	for (i = 0; i < 256; i++) {
 		static char dir[4096];
 		sprintf(dir, "%s/%02x", sha1_dir, i);
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -100,18 +100,34 @@ char * sha1_to_hex(const unsigned char *
 	return buffer;
 }
 
+static void fill_sha1_path(char *pathbuf, const unsigned char *sha1)
+{
+	int i;
+	for (i = 0; i < 20; i++) {
+		static char hex[] = "0123456789abcdef";
+		unsigned int val = sha1[i];
+		char *pos = pathbuf + i*2 + (i > 0);
+		*pos++ = hex[val >> 4];
+		*pos = hex[val & 0xf];
+	}
+}
+
 /*
  * NOTE! This returns a statically allocated buffer, so you have to be
  * careful about using it. Do a "strdup()" if you need to save the
  * filename.
+ *
+ * Also note that this returns the location for creating.  Reading
+ * SHA1 file can happen from any alternate directory listed in the
+ * SHA1_FILE_DIRECTORIES environment variable if it is not found in
+ * the primary object database.
  */
 char *sha1_file_name(const unsigned char *sha1)
 {
-	int i;
 	static char *name, *base;
 
 	if (!base) {
-		char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
+		char *sha1_file_directory = get_object_directory();
 		int len = strlen(sha1_file_directory);
 		base = xmalloc(len + 60);
 		memcpy(base, sha1_file_directory, len);
@@ -120,16 +136,74 @@ char *sha1_file_name(const unsigned char
 		base[len+3] = '/';
 		name = base + len + 1;
 	}
-	for (i = 0; i < 20; i++) {
-		static char hex[] = "0123456789abcdef";
-		unsigned int val = sha1[i];
-		char *pos = name + i*2 + (i > 0);
-		*pos++ = hex[val >> 4];
-		*pos = hex[val & 0xf];
-	}
+	fill_sha1_path(name, sha1);
 	return base;
 }
 
+static struct alternate_object_database
+{
+	char *base;
+	char *name;
+} *alt_odb;
+
+static void prepare_alt_odb(void)
+{
+	int pass, totlen, i;
+	void *buf;
+	const char *cp, *last;
+	char *op = 0;
+	const char *alt = getenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
+
+	for (totlen = pass = 0; pass < 2; pass++) {
+		last = alt;
+		i = 0;
+		do {
+			cp = strchr(last, ':') ? : last + strlen(last);
+			if (last != cp) {
+				/* 43 = 40-byte + 2 '/' + terminating NUL */
+				int pfxlen = cp - last;
+				int entlen = pfxlen + 43;
+				if (pass == 0)
+					totlen += entlen;
+				else {
+					alt_odb[i].base = op;
+					alt_odb[i].name = op + pfxlen + 1;
+					memcpy(op, last, pfxlen);
+					op[pfxlen] = op[pfxlen + 3] = '/';
+					op[entlen-1] = 0;
+					op += entlen;
+				}
+				i++;
+			}
+			while (*cp && *cp == ':')
+				cp++;
+			last = cp;
+		} while (*cp);
+		if (pass)
+			break;
+		alt_odb = buf = xmalloc(sizeof(*alt_odb) * (i + 1) + totlen);
+		alt_odb[i].base = alt_odb[i].name = 0;
+		op = (char*)(&alt_odb[i+1]);
+	}
+}
+
+static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
+{
+	int i;
+	char *name = sha1_file_name(sha1);
+
+	if (!stat(name, st))
+		return name;
+	if (!alt_odb)
+		prepare_alt_odb();
+	for (i = 0; (name = alt_odb[i].name) != NULL; i++) {
+		fill_sha1_path(name, sha1);
+		if (!stat(alt_odb[i].base, st))
+			return alt_odb[i].base;
+	}
+	return NULL;
+}
+
 int check_sha1_signature(unsigned char *sha1, void *map, unsigned long size, const char *type)
 {
 	char header[100];
@@ -145,10 +219,15 @@ int check_sha1_signature(unsigned char *
 
 void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
 {
-	char *filename = sha1_file_name(sha1);
 	struct stat st;
 	void *map;
 	int fd;
+	char *filename = find_sha1_file(sha1, &st);
+
+	if (!filename) {
+		error("cannot map sha1 file %s", sha1_to_hex(sha1));
+		return NULL;
+	}
 
 	fd = open(filename, O_RDONLY | sha1_file_open_flag);
 	if (fd < 0) {
@@ -167,10 +246,6 @@ void *map_sha1_file(const unsigned char 
 		/* If it failed once, it will probably fail again. Stop using O_NOATIME */
 		sha1_file_open_flag = 0;
 	}
-	if (fstat(fd, &st) < 0) {
-		close(fd);
-		return NULL;
-	}
 	map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
 	close(fd);
 	if (-1 == (int)(long)map)
@@ -315,6 +390,7 @@ int write_sha1_file(char *buf, unsigned 
 	}
 
 	snprintf(tmpfile, sizeof(tmpfile), "%s/obj_XXXXXX", get_object_directory());
+
 	fd = mkstemp(tmpfile);
 	if (fd < 0) {
 		fprintf(stderr, "unable to create temporary sha1 filename %s: %s", tmpfile, strerror(errno));
@@ -442,12 +518,8 @@ int write_sha1_from_fd(const unsigned ch
 
 int has_sha1_file(const unsigned char *sha1)
 {
-	char *filename = sha1_file_name(sha1);
 	struct stat st;
-
-	if (!stat(filename, &st))
-		return 1;
-	return 0;
+	return !!find_sha1_file(sha1, &st);
 }
 
 int index_fd(unsigned char *sha1, int fd, struct stat *st)

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[H. Peter Anvin]

Naming the environment variables SHA1_FILE_<anything> is almost 
certainly wrong; a much more logical name would be GIT_<something>. 
It'd also be much less likely to cause conflicts.

	-hpa

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[Junio C Hamano]

>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:

HPA> Naming the environment variables SHA1_FILE_<anything> is almost
HPA> certainly wrong; a much more logical name would be
HPA> GIT_<something>. It'd also be much less likely to cause conflicts.

Exactly my feeling from the beginning.

But you have to realize that you are suggesting to change the
SHA1_FILE_DIRECTORY that was there from almost the beginning as
well.  I know the code change required for the rename is
minimum, but there are users involved.  My feeling is that we
should contain the damage by changing the definition of
DB_ENVIRONMENT in cache.h sooner rather than later, but I do not
think this is the week to do it.

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[Sean]

On Mon, May 9, 2005 12:38 pm, Junio C Hamano said:
>>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:
>
> HPA> Naming the environment variables SHA1_FILE_<anything> is almost
> HPA> certainly wrong; a much more logical name would be
> HPA> GIT_<something>. It'd also be much less likely to cause conflicts.
>
> Exactly my feeling from the beginning.
>
> But you have to realize that you are suggesting to change the
> SHA1_FILE_DIRECTORY that was there from almost the beginning as
> well.  I know the code change required for the rename is
> minimum, but there are users involved.  My feeling is that we
> should contain the damage by changing the definition of
> DB_ENVIRONMENT in cache.h sooner rather than later, but I do not
> think this is the week to do it.
>
>

What about creating a transition plan that uses the GIT_ name if it exists
and the SHA1_ name if it doesn't.  And mark the SHA1_ name as depreciated.
 That should be okay to do this week, no?

Sean

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[H. Peter Anvin]

Sean wrote:
> 
> What about creating a transition plan that uses the GIT_ name if it exists
> and the SHA1_ name if it doesn't.  And mark the SHA1_ name as depreciated.
>  That should be okay to do this week, no?
> 

Should work.

	-hpa

Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES

[Junio C Hamano]

>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:

HPA> Sean wrote:
>> What about creating a transition plan that uses the GIT_ name if it
>> exists
>> and the SHA1_ name if it doesn't.  And mark the SHA1_ name as depreciated.
>> That should be okay to do this week, no?
>> 

HPA> Should work.

Thanks, both Sean and H. Peter.  Would cook something up.

[RFC] Renaming environment variables.

[Junio C Hamano]

H. Peter Anvin mentioned that using SHA1_whatever as an
environment variable name is not nice and we should instead use
names starting with "GIT_" prefix to avoid conflicts.

Here is a patch, requesting for comments.

 - Renames the following environment variables:

    New name                Old Name

    GIT_AUTHOR_DATE         AUTHOR_DATE
    GIT_AUTHOR_EMAIL        AUTHOR_EMAIL
    GIT_AUTHOR_NAME         AUTHOR_NAME
    GIT_COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_EMAIL
    GIT_COMMIT_AUTHOR_NAME  COMMIT_AUTHOR_NAME
    GIT_ALTERNATE_OBJECTS   SHA1_FILE_DIRECTORIES
    GIT_OBJECTS             SHA1_FILE_DIRECTORY

 - Changes all users of the environment variable to fetch
   environment variable with the new name.

 - Introduces a compatibility macro, gitenv(), which does an
   getenv() and if it fails calls gitenv_bc(), which in turn
   picks up the value from old name while giving a warning about
   using an old name.

I've also updated the documentation and scripts shipped with
Linus GIT distribution.

The transition plan is as follows:

 - We will keep the backward compatibility list used by gitenv()
   for now, so the current scripts and user environments
   continue to work as before.  The users will get warnings when
   they have old name but not new name in their environment to
   the stderr.

 - The Porcelain layers should start using new names.  However,
   just in case it ends up calling old Plumbing layer
   implementation, they should also export old names, taking
   values from the corresponding new names, during the
   transition period.

 - After a couple of weeks or so, we would drop the
   compatibility support and drop gitenv().  Revert the callers
   to directly call getenv() but keep using the new names.

   The last part is probably optional and the transition
   duration needs to be set to a reasonable value.

Not-quite-signed-off-yet-by: Junio C Hamano <junkio@cox.net>
------------

Documentation/core-git.txt |   17 +++++-----
Makefile                   |    3 +
README                     |    2 -
cache.h                    |   15 +++++++--
commit-tree.c              |   10 +++---
diff.c                     |   10 +++---
git-prune-script           |    8 +++--
gitenv.c                   |   70 +++++++++++++++++++++++++++++++++++++++++++++
init-db.c                  |    7 ++--
rsh.c                      |    4 +-
sha1_file.c                |    8 ++---
11 files changed, 120 insertions(+), 34 deletions(-)

# - HEAD: Fix git-update-cache --cacheinfo error message.
# + 7: Rename Environment Variables
--- a/Documentation/core-git.txt
+++ b/Documentation/core-git.txt
@@ -210,15 +210,16 @@ Environment Variables
 ---------------------
 Various git commands use the following environment variables:
 
-- 'AUTHOR_NAME'
-- 'AUTHOR_EMAIL'
-- 'AUTHOR_DATE'
-- 'COMMIT_AUTHOR_NAME'
-- 'COMMIT_AUTHOR_EMAIL'
+- 'GIT_AUTHOR_NAME'
+- 'GIT_AUTHOR_EMAIL'
+- 'GIT_AUTHOR_DATE'
+- 'GIT_COMMIT_AUTHOR_NAME'
+- 'GIT_COMMIT_AUTHOR_EMAIL'
 - 'GIT_DIFF_OPTS'
 - 'GIT_EXTERNAL_DIFF'
 - 'GIT_INDEX_FILE'
-- 'SHA1_FILE_DIRECTORY'
+- 'GIT_OBJECTS'
+- 'GIT_ALTERNATE_OBJECTS'
 
 
 NAME
@@ -876,7 +877,7 @@ sha1 mismatch <object>::
 Environment Variables
 ---------------------
 
-SHA1_FILE_DIRECTORY::
+GIT_OBJECTS::
 	used to specify the object database root (usually .git/objects)
 
 GIT_INDEX_FILE::
@@ -918,7 +919,7 @@ DESCRIPTION
 This simply creates an empty git object database - basically a `.git`
 directory and `.git/object/??/` directories.
 
-If the object storage directory is specified via the 'SHA1_FILE_DIRECTORY'
+If the object storage directory is specified via the 'GIT_OBJECTS'
 environment variable then the sha1 directories are created underneath -
 otherwise the default `.git/objects` directory is used.
 
--- a/Makefile
+++ b/Makefile
@@ -46,6 +46,8 @@ LIB_OBJS += strbuf.o
 LIB_H += diff.h
 LIB_OBJS += diff.o
 
+LIB_OBJS += gitenv.o
+
 LIBS = $(LIB_FILE)
 LIBS += -lz
 
@@ -116,6 +118,7 @@ sha1_file.o: $(LIB_H)
 usage.o: $(LIB_H)
 diff.o: $(LIB_H)
 strbuf.o: $(LIB_H)
+gitenv.o: $(LIB_H)
 
 clean:
 	rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
--- a/README
+++ b/README
@@ -24,7 +24,7 @@ There are two object abstractions: the "
 
 
 
-	The Object Database (SHA1_FILE_DIRECTORY)
+	The Object Database (GIT_OBJECTS)
 
 
 The object database is literally just a content-addressable collection
--- a/cache.h
+++ b/cache.h
@@ -31,6 +31,13 @@
 #endif
 
 /*
+ * Environment variables transition.
+ * We accept older names for now but warn.
+ */
+extern char *gitenv_bc(const char *);
+#define gitenv(e) (getenv(e) ? : gitenv_bc(e))
+
+/*
  * Basic data structures for the directory cache
  *
  * NOTE NOTE NOTE! This is all in the native CPU byte format. It's
@@ -99,16 +106,16 @@ static inline unsigned int create_ce_mod
 struct cache_entry **active_cache;
 unsigned int active_nr, active_alloc, active_cache_changed;
 
-#define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
+#define DB_ENVIRONMENT "GIT_OBJECTS"
 #define DEFAULT_DB_ENVIRONMENT ".git/objects"
-#define ALTERNATE_DB_ENVIRONMENT "SHA1_FILE_DIRECTORIES"
+#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECTS"
 
-#define get_object_directory() (getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
+#define get_object_directory() (gitenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
 
 #define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
 #define DEFAULT_INDEX_ENVIRONMENT ".git/index"
 
-#define get_index_file() (getenv(INDEX_ENVIRONMENT) ? : DEFAULT_INDEX_ENVIRONMENT)
+#define get_index_file() (gitenv(INDEX_ENVIRONMENT) ? : DEFAULT_INDEX_ENVIRONMENT)
 
 #define alloc_nr(x) (((x)+16)*3/2)
 
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -146,11 +146,11 @@ int main(int argc, char **argv)
 	datestamp(realdate, sizeof(realdate));
 	strcpy(date, realdate);
 
-	commitgecos = getenv("COMMIT_AUTHOR_NAME") ? : realgecos;
-	commitemail = getenv("COMMIT_AUTHOR_EMAIL") ? : realemail;
-	gecos = getenv("AUTHOR_NAME") ? : realgecos;
-	email = getenv("AUTHOR_EMAIL") ? : realemail;
-	audate = getenv("AUTHOR_DATE");
+	commitgecos = gitenv("GIT_COMMIT_AUTHOR_NAME") ? : realgecos;
+	commitemail = gitenv("GIT_COMMIT_AUTHOR_EMAIL") ? : realemail;
+	gecos = gitenv("GIT_AUTHOR_NAME") ? : realgecos;
+	email = gitenv("GIT_AUTHOR_EMAIL") ? : realemail;
+	audate = gitenv("GIT_AUTHOR_DATE");
 	if (audate)
 		parse_date(audate, date, sizeof(date));
 
--- a/diff.c
+++ b/diff.c
@@ -8,11 +8,11 @@
 #include "cache.h"
 #include "diff.h"
 
-static char *diff_opts = "-pu";
+static const char *diff_opts = "-pu";
 
 static const char *external_diff(void)
 {
-	static char *external_diff_cmd = NULL;
+	static const char *external_diff_cmd = NULL;
 	static int done_preparing = 0;
 
 	if (done_preparing)
@@ -26,11 +26,11 @@ static const char *external_diff(void)
 	 *
 	 * GIT_DIFF_OPTS="-c";
 	 */
-	if (getenv("GIT_EXTERNAL_DIFF"))
-		external_diff_cmd = getenv("GIT_EXTERNAL_DIFF");
+	if (gitenv("GIT_EXTERNAL_DIFF"))
+		external_diff_cmd = gitenv("GIT_EXTERNAL_DIFF");
 
 	/* In case external diff fails... */
-	diff_opts = getenv("GIT_DIFF_OPTS") ? : diff_opts;
+	diff_opts = gitenv("GIT_DIFF_OPTS") ? : diff_opts;
 
 	done_preparing = 1;
 	return external_diff_cmd;
--- a/git-prune-script
+++ b/git-prune-script
@@ -28,9 +28,13 @@ sed -ne '/unreachable /{
     s/unreachable [^ ][^ ]* //
     s|\(..\)|\1/|p
 }' | {
-	case "$SHA1_FILE_DIRECTORY" in
+	for d in "$GIT_OBJECTS" "$SHA1_FILE_DIRECTORY" ''
+	do
+		test "$d" != "" && test -d "$d" && break
+	done
+	case "$d" in
 	'') cd .git/objects/ ;;
-	*) cd "$SHA1_FILE_DIRECTORY" ;;
+	*) cd "$d" ;;
 	esac || exit
 	xargs -r $dryrun rm -f
 }
Created: gitenv.c (mode:100644)
--- /dev/null
+++ b/gitenv.c
@@ -0,0 +1,70 @@
+#include "cache.h"
+
+/*
+ * This array must be sorted by its canonical name, because
+ * we do look-up by binary search.
+ */
+static struct backward_compatible_env {
+	const char *canonical;
+	const char *old;
+} bc_name[] = {
+	{ "GIT_ALTERNATE_OBJECTS", "SHA1_FILE_DIRECTORIES" },
+	{ "GIT_AUTHOR_DATE", "AUTHOR_DATE" },
+	{ "GIT_AUTHOR_EMAIL", "AUTHOR_EMAIL" },
+	{ "GIT_AUTHOR_NAME", "AUTHOR_NAME" }, 
+	{ "GIT_COMMIT_AUTHOR_EMAIL", "COMMIT_AUTHOR_EMAIL" },
+	{ "GIT_COMMIT_AUTHOR_NAME", "COMMIT_AUTHOR_NAME" },
+	{ "GIT_OBJECTS", "SHA1_FILE_DIRECTORY" },
+};
+
+static void warn_old_environment(void)
+{
+	int i;
+	static int warned = 0;
+	if (warned)
+		return;
+
+	warned = 1;
+	fprintf(stderr,
+		"warning: GIT environment variables have been renamed.\n"
+		"warning: Please adjust your scripts and environment.\n");
+	for (i = 0; i < sizeof(bc_name) / sizeof(bc_name[0]); i++) {
+		/* warning is needed only when old name is there and
+		 * new name is not.
+		 */
+		if (!getenv(bc_name[i].canonical) && getenv(bc_name[i].old))
+			fprintf(stderr, "warning: old %s => new %s\n",
+				bc_name[i].old, bc_name[i].canonical);
+	}
+}
+
+char *gitenv_bc(const char *e)
+{
+	int first, last;
+	char *val = getenv(e);
+	if (val)
+		/* inefficient.  caller should use gitenv() not gitenv_bc() */
+		return val;
+
+	first = 0;
+	last = sizeof(bc_name) / sizeof(bc_name[0]);
+	while (last > first) {
+		int next = (last + first) >> 1;
+		int cmp = strcmp(e, bc_name[next].canonical);
+		if (!cmp) {
+			val = getenv(bc_name[next].old);
+			/* If the user has only old name, warn.
+			 * otherwise stay silent.
+			 */
+			if (val)
+				warn_old_environment();
+			return val;
+		}
+		if (cmp < 0) {
+			last = next;
+			continue;
+		}
+		first = next+1;
+	}
+	return NULL;
+}
--- a/init-db.c
+++ b/init-db.c
@@ -5,7 +5,7 @@
  */
 #include "cache.h"
 
-void safe_create_dir(char *dir)
+void safe_create_dir(const char *dir)
 {
 	if (mkdir(dir, 0755) < 0) {
 		if (errno != EEXIST) {
@@ -23,12 +23,13 @@ void safe_create_dir(char *dir)
  */
 int main(int argc, char **argv)
 {
-	char *sha1_dir, *path;
+	const char *sha1_dir;
+	char *path;
 	int len, i;
 
 	safe_create_dir(".git");
 
-	sha1_dir = getenv(DB_ENVIRONMENT);
+	sha1_dir = gitenv(DB_ENVIRONMENT);
 	if (!sha1_dir) {
 		sha1_dir = DEFAULT_DB_ENVIRONMENT;
 		fprintf(stderr, "defaulting to local storage area\n");
--- a/rsh.c
+++ b/rsh.c
@@ -36,8 +36,8 @@ int setup_connection(int *fd_in, int *fd
 	*(path++) = '\0';
 	/* ssh <host> 'cd /<path>; stdio-pull <arg...> <commit-id>' */
 	snprintf(command, COMMAND_SIZE, 
-		 "cd /%s; SHA1_FILE_DIRECTORY=objects %s",
-		 path, remote_prog);
+		 "cd /%s; %s=objects %s",
+		 path, DB_ENVIRONMENT, remote_prog);
 	posn = command + strlen(command);
 	for (i = 0; i < rmt_argc; i++) {
 		*(posn++) = ' ';
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -120,7 +120,7 @@ static void fill_sha1_path(char *pathbuf
  *
  * Also note that this returns the location for creating.  Reading
  * SHA1 file can happen from any alternate directory listed in the
- * SHA1_FILE_DIRECTORIES environment variable if it is not found in
+ * DB_ENVIRONMENT environment variable if it is not found in
  * the primary object database.
  */
 char *sha1_file_name(const unsigned char *sha1)
@@ -128,7 +128,7 @@ char *sha1_file_name(const unsigned char
 	static char *name, *base;
 
 	if (!base) {
-		char *sha1_file_directory = get_object_directory();
+		const char *sha1_file_directory = get_object_directory();
 		int len = strlen(sha1_file_directory);
 		base = xmalloc(len + 60);
 		memcpy(base, sha1_file_directory, len);
@@ -151,7 +151,7 @@ static struct alternate_object_database 
  * alt_odb points at an array of struct alternate_object_database.
  * This array is terminated with an element that has both its base
  * and name set to NULL.  alt_odb[n] comes from n'th non-empty
- * element from colon separated $SHA1_FILE_DIRECTORIES environment
+ * element from colon separated ALTERNATE_DB_ENVIRONMENT environment
  * variable, and its base points at a statically allocated buffer
  * that contains "/the/directory/corresponding/to/.git/objects/...",
  * while its name points just after the slash at the end of
@@ -167,7 +167,7 @@ static void prepare_alt_odb(void)
 	int pass, totlen, i;
 	const char *cp, *last;
 	char *op = 0;
-	const char *alt = getenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
+	const char *alt = gitenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
 
 	/* The first pass counts how large an area to allocate to
 	 * hold the entire alt_odb structure, including array of

Re: [RFC] Renaming environment variables.

[Thomas Glanzmann]

Hello,

> Here is a patch, requesting for comments.

sounds good. But I would forget about downward compatibility. There is
no need to maintain it at this early stage.

And one thing which bothers me all the time but never spoke up about it:
There is no way to provide a GIT_COMMIT_DATE. This would be useful for
vendortracking a CVS repository for example.

And personally I think GIT_COMMIT_AUTHOR_EMAIL and
GIT_COMMIT_AUTHOR_NAME are to long what about
GIT_COMMITTER_{NAME,EMAIL}?  Whatever. You script them or put them in
your environment anyway so no big issue.

	Thomas

Re: [RFC] Renaming environment variables.

[Petr Baudis]

Dear diary, on Mon, May 09, 2005 at 10:15:20PM CEST, I got a letter
where Thomas Glanzmann <sithglan@stud.uni-erlangen.de> told me that...
> > Here is a patch, requesting for comments.
> 
> sounds good. But I would forget about downward compatibility. There is
> no need to maintain it at this early stage.

Sure there is. We are actually far from an early stage now, I'd say.

And what I don't want to see are commits with messed up author
information since people upgraded and did not notice.

> And one thing which bothers me all the time but never spoke up about it:
> There is no way to provide a GIT_COMMIT_DATE. This would be useful for
> vendortracking a CVS repository for example.

You could use GIT_AUTHOR_DATE. :-)

But yes, I actually agree. When you are doing vendortracking of CVS
repository, you have one canonical source of the commit, and when you do
the CVS import twice independently, I think you _want_ the same commit,
since it _is_ the same commit after all (if the history is same too,
obviously).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [RFC] Renaming environment variables.

[Sean]

On Mon, May 9, 2005 4:05 pm, Junio C Hamano said:
> H. Peter Anvin mentioned that using SHA1_whatever as an
> environment variable name is not nice and we should instead use
> names starting with "GIT_" prefix to avoid conflicts.
>
> Here is a patch, requesting for comments.

Junio,

Look quite good; you made short work of that!

However I don't understand your gitenv_bc, wouldn't the following suffice?

char *gitenv_bc(const char *e)
{
        int i;
        char *val = getenv(e);
        if (val)
                return val;

        for (i=0; i < sizeof(bc_name) / sizeof(bc_name[0]); ++i) {
                if (!strcmp(e, bc_name[i].canonical)) {
                        if (val = getenv(bc_name[i].old))
                                warn_old_environment();
                        return val;
                }
        }
        return NULL;
}


Cheers,
Sean

Re: [RFC] Renaming environment variables.

[Daniel Barkalow]

On Mon, 9 May 2005, Junio C Hamano wrote:

> H. Peter Anvin mentioned that using SHA1_whatever as an
> environment variable name is not nice and we should instead use
> names starting with "GIT_" prefix to avoid conflicts.
> 
> Here is a patch, requesting for comments.
> 
>  - Renames the following environment variables:
> 
>     New name                Old Name
> 
>     GIT_AUTHOR_DATE         AUTHOR_DATE
>     GIT_AUTHOR_EMAIL        AUTHOR_EMAIL
>     GIT_AUTHOR_NAME         AUTHOR_NAME
>     GIT_COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_EMAIL
>     GIT_COMMIT_AUTHOR_NAME  COMMIT_AUTHOR_NAME
>     GIT_ALTERNATE_OBJECTS   SHA1_FILE_DIRECTORIES
>     GIT_OBJECTS             SHA1_FILE_DIRECTORY

While we're at it, it would be useful to have one for what is normally
".git", rather than just ".git/objects". That way the same variable would
be useful for finding other things in the .git directory, and I haven't
heard of any use of SHA1_FILE_DIRECTORY that didn't end in /objects
anyway, and would enable the brokenness in init-db (it creates ".git", and
then tries to create "<obj-dir>/00-ff").

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] Renaming environment variables.

[Junio C Hamano]

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

DB> While we're at it, it would be useful to have one for what is normally
DB> ".git",...

If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
your only gripe is about git-init-db creating ".git" in the
current working directory regardless of SHA1_FILE_DIRECTORY, I
would agree that what git-init-db does is broken.  Not that I
have a suggested "right behaviour" for it, though.

However if you also mean by ".git" the directory refs/heads and
friends hang underneath, then I have to disagree.  That does not
belong to core GIT, which always expects to run from the top
level directory that has such directory directly under it, and
at the same time corresponds to the tree structure the dircache
describes.  There is no need for the environment variable you
suggest, since it always is the ".git" subdirectory of such a
directory.

I once advocated GIT_WORKING_TREE to mean the current project
top, which is the parent directory of ".git".  The proposal was
shot down (see archives [*1*]).  While I still think that
configuration (or your ".git" location proposal, which is
essentially the equivalent) may sometimes useful, I'd rather not
conflate this environment variable renames with that issue.
They are pretty much independent issues.

[References]
*1* http://marc.theaimsgroup.com/?l=git&m=111412959320946&w=2

Re: [RFC] Renaming environment variables.

[Petr Baudis]

Dear diary, on Tue, May 10, 2005 at 02:09:19AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
> your only gripe is about git-init-db creating ".git" in the
> current working directory regardless of SHA1_FILE_DIRECTORY, I
> would agree that what git-init-db does is broken.  Not that I
> have a suggested "right behaviour" for it, though.
> 
> However if you also mean by ".git" the directory refs/heads and
> friends hang underneath, then I have to disagree.  That does not
> belong to core GIT, which always expects to run from the top
> level directory that has such directory directly under it, and
> at the same time corresponds to the tree structure the dircache
> describes.  There is no need for the environment variable you
> suggest, since it always is the ".git" subdirectory of such a
> directory.

I think it would be nice to have something like GIT_BASEDIR, which would
default to .git, and the objects directory would then default to
$GIT_BASEDIR/objects and the index file would default to
$GIT_BASEDIR/index.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [RFC] Renaming environment variables.

[Junio C Hamano]

>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:

PB> I think it would be nice to have something like GIT_BASEDIR,
PB> which would default to .git, and the objects directory would
PB> then default to $GIT_BASEDIR/objects and the index file
PB> would default to $GIT_BASEDIR/index.

Yes and no.  While I agree that having more things customizable
may be nicer than not having them, I do not see what GIT_BASEDIR
buys us.  That is, I cannot come up with a good use scenario
that would be helped by having that environment variable.

Except that you do not have to specify GIT_OBJECTS and
GIT_INDEX_FILE separately, that is.  Is it what you are aiming
for?

Re: [RFC] Renaming environment variables.

[Petr Baudis]

Dear diary, on Tue, May 10, 2005 at 02:22:30AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Except that you do not have to specify GIT_OBJECTS and
> GIT_INDEX_FILE separately, that is.  Is it what you are aiming
> for?

Yes. Having less things to specify is better. What if another directory
will be added to the git repository? Everything which wants to work with
something else than .git will be broken just because of this.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [RFC] Renaming environment variables.

[Daniel Barkalow]

On Mon, 9 May 2005, Junio C Hamano wrote:

> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> DB> While we're at it, it would be useful to have one for what is normally
> DB> ".git",...
> 
> If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
> your only gripe is about git-init-db creating ".git" in the
> current working directory regardless of SHA1_FILE_DIRECTORY, I
> would agree that what git-init-db does is broken.  Not that I
> have a suggested "right behaviour" for it, though.

It could just create all missing parents of the object directory, which
would be better, at least.

> However if you also mean by ".git" the directory refs/heads and
> friends hang underneath, then I have to disagree.  That does not
> belong to core GIT, which always expects to run from the top
> level directory that has such directory directly under it, and
> at the same time corresponds to the tree structure the dircache
> describes.  There is no need for the environment variable you
> suggest, since it always is the ".git" subdirectory of such a
> directory.

So far, I have never heard of SHA1_FILE_DIRECTORY being used to target
something in .git other than objects. The only use of SHA1_FILE_DIRECTORY
I've heard about is my own in rsh.c, which sets it to [PATH]/objects,
because it has to write object files, most often, to
.../project.git/objects/. You can't really cd to /scm/git<delete> and have
.git/objects refer to the right thing.

My position is still that what refs/*/* gets used for is up to the user,
but the existance and format of the directory is a core thing. In
particular, I want to have atomic methods of modifying these files. (I.e.,
you give commit-cache a */* to write the result to, and it will make sure
that nobody writes to it or reads it expecting to write to it while you're
committing).

But even if this is up to the wrapping scripts, it would be useful to have
the same environment variable used by those scripts for whatever they want
to have in there.

> I once advocated GIT_WORKING_TREE to mean the current project
> top, which is the parent directory of ".git".  The proposal was
> shot down (see archives [*1*]).  While I still think that
> configuration (or your ".git" location proposal, which is
> essentially the equivalent) may sometimes useful, I'd rather not
> conflate this environment variable renames with that issue.
> They are pretty much independent issues.

The reason to tackle them at once is so that there doesn't have to be
multiple changeovers.

> [References]
> *1* http://marc.theaimsgroup.com/?l=git&m=111412959320946&w=2

I believe that Linus's primary gripe was about changing the expected
location of the working tree, not about changing the expected location of
the git storage. So the .git location proposal is quite different.

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] Renaming environment variables.

[Petr Baudis]

Dear diary, on Tue, May 10, 2005 at 02:38:53AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Mon, 9 May 2005, Junio C Hamano wrote:
> 
> > >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
> > 
> > DB> While we're at it, it would be useful to have one for what is normally
> > DB> ".git",...
> > 
> > If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
> > your only gripe is about git-init-db creating ".git" in the
> > current working directory regardless of SHA1_FILE_DIRECTORY, I
> > would agree that what git-init-db does is broken.  Not that I
> > have a suggested "right behaviour" for it, though.
> 
> It could just create all missing parents of the object directory, which
> would be better, at least.

What about the index file? Or should git-read-tree take care of that?

> But even if this is up to the wrapping scripts, it would be useful to have
> the same environment variable used by those scripts for whatever they want
> to have in there.

Seconded. That is another good reason for having that.

> > I once advocated GIT_WORKING_TREE to mean the current project
> > top, which is the parent directory of ".git".  The proposal was
> > shot down (see archives [*1*]).  While I still think that
> > configuration (or your ".git" location proposal, which is
> > essentially the equivalent) may sometimes useful, I'd rather not
> > conflate this environment variable renames with that issue.
> > They are pretty much independent issues.
> 
> The reason to tackle them at once is so that there doesn't have to be
> multiple changeovers.

There should be no changeovers, just additions - the object directory
and index file location environment variables should stay too.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [RFC] Renaming environment variables.

[Daniel Barkalow]

On Tue, 10 May 2005, Petr Baudis wrote:

> Dear diary, on Tue, May 10, 2005 at 02:38:53AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > On Mon, 9 May 2005, Junio C Hamano wrote:
> > 
> > > >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
> > > 
> > > DB> While we're at it, it would be useful to have one for what is normally
> > > DB> ".git",...
> > > 
> > > If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
> > > your only gripe is about git-init-db creating ".git" in the
> > > current working directory regardless of SHA1_FILE_DIRECTORY, I
> > > would agree that what git-init-db does is broken.  Not that I
> > > have a suggested "right behaviour" for it, though.
> > 
> > It could just create all missing parents of the object directory, which
> > would be better, at least.
> 
> What about the index file? Or should git-read-tree take care of that?

Probably whatever writes the index file should take care of making sure it
can be written (if possible).

> > > I once advocated GIT_WORKING_TREE to mean the current project
> > > top, which is the parent directory of ".git".  The proposal was
> > > shot down (see archives [*1*]).  While I still think that
> > > configuration (or your ".git" location proposal, which is
> > > essentially the equivalent) may sometimes useful, I'd rather not
> > > conflate this environment variable renames with that issue.
> > > They are pretty much independent issues.
> > 
> > The reason to tackle them at once is so that there doesn't have to be
> > multiple changeovers.
> 
> There should be no changeovers, just additions - the object directory
> and index file location environment variables should stay too.

Definitely true of the index file, since people actually write different
ones. I'm not sure if there's a real use for specifying something
different for the objects directory than BASE + objects, though.

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] Renaming environment variables.

[Junio C Hamano]

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

DB> On Mon, 9 May 2005, Junio C Hamano wrote:
>> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>> 
DB> While we're at it, it would be useful to have one for what is normally
DB> ".git",...
>> 
>> If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
>> your only gripe is about git-init-db creating ".git" in the
>> current working directory regardless of SHA1_FILE_DIRECTORY, I
>> would agree that what git-init-db does is broken.  Not that I
>> have a suggested "right behaviour" for it, though.

DB> It could just create all missing parents of the object directory, which
DB> would be better, at least.

I am ambivalent about this.  Here is an excerpt from my WIP.  I
am trying to keep the original semantics of "we create the
leading paths only if we default to .git/objects":

$ GIT_DIFF_OPTS=-u8 jit-diff 1: init-db.c
# - HEAD: Rename environment variables.
# + (working tree)
--- a/init-db.c
+++ b/init-db.c
@@ -22,21 +22,22 @@
  * be the judge.  The default case is to have one DB per managed directory.
  */
 int main(int argc, char **argv)
 {
 	const char *sha1_dir;
 	char *path;
 	int len, i;
 
-	safe_create_dir(".git");
-
-	sha1_dir = gitenv(DB_ENVIRONMENT);
-	if (!sha1_dir) {
-		sha1_dir = DEFAULT_DB_ENVIRONMENT;
+	sha1_dir = get_object_directory();
+	if (!gitenv(DB_ENVIRONMENT) && !gitenv(GIT_DIR_ENVIRONMENT)) {
+		/* We create leading paths only when we fall back
+		 * to local ".git/objects".
+		 */
+		safe_create_dir(DEFAULT_GIT_DIR_ENVIRONMENT);
 		fprintf(stderr, "defaulting to local storage area\n");
 	}
 	len = strlen(sha1_dir);
 	path = xmalloc(len + 40);
 	memcpy(path, sha1_dir, len);
 
 	safe_create_dir(sha1_dir);
 	for (i = 0; i < 256; i++) {

Here DEFAULT_GIT_DIR_ENVIRONMENT is defined as ".git", and the
directory is created only if we do not have GIT_OBJECT_DIRECTORY
nor GIT_DIR environment variables, which should match the intent
of the original by Linus.  Otherwise we at least require the
parent directory of GIT_OBJECT_DIRECTORY to exist.  I think that
is a reasonable default (well that is not something I can take
credit), in that if the user is clued enough to use something
different from the default he should at least know enough to
create the leading paths beforehand (or the script could do that
for him).

Other than this part, I think the code is ready to go.

Introducing GIT_DIR environment variable.

[Junio C Hamano]

Ok, following the mailing list discussion, I've done GIT_DIR and
pushed it out to the usual git-jc repository, at:

    http://members.cox.net/junkio/git-jc.git/

Author: Junio C Hamano <junkio@cox.net>
Date:   Mon May 9 22:57:58 2005 -0700
    
    Introduce GIT_DIR environment variable.
    
    During the mailing list discussion on renaming GIT_ environment
    variables, people felt that having one environment that lets the
    user (or Porcelain) specify both SHA1_FILE_DIRECTORY (now
    GIT_OBJECT_DIRECTORY) and GIT_INDEX_FILE for the default layout
    would be handy.  This change introduces GIT_DIR environment
    variable, from which the defaults for GIT_INDEX_FILE and
    GIT_OBJECT_DIRECTORY are derived.  When GIT_DIR is not defined,
    it defaults to ".git".  GIT_INDEX_FILE defaults to
    "$GIT_DIR/index" and GIT_OBJECT_DIRECTORY defaults to
    "$GIT_DIR/objects".
    
    Special thanks for ideas and discussions go to Petr Baudis and
    Daniel Barkalow.  Bugs are mine ;-)
    
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
--- a/cache.h
+++ b/cache.h
@@ -106,16 +106,15 @@ static inline unsigned int create_ce_mod
 struct cache_entry **active_cache;
 unsigned int active_nr, active_alloc, active_cache_changed;
 
+#define GIT_DIR_ENVIRONMENT "GIT_DIR"
+#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
 #define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
-#define DEFAULT_DB_ENVIRONMENT ".git/objects"
-#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
-
-#define get_object_directory() (gitenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
-
 #define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
-#define DEFAULT_INDEX_ENVIRONMENT ".git/index"
 
-#define get_index_file() (gitenv(INDEX_ENVIRONMENT) ? : DEFAULT_INDEX_ENVIRONMENT)
+extern char *get_object_directory(void);
+extern char *get_index_file(void);
+
+#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
 
 #define alloc_nr(x) (((x)+16)*3/2)
 
--- a/git-prune-script
+++ b/git-prune-script
@@ -11,6 +11,9 @@ do
     shift;
 done
 
+: ${GIT_DIR=.git}
+: ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"}
+
 # Defaulting to include .git/refs/*/* may be debatable from the
 # purist POV but power users can always give explicit parameters
 # to the script anyway.
@@ -19,7 +22,8 @@ case "$#" in
 0)
     x_40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
     x_40="$x_40$x_40$x_40$x_40$x_40$x_40$x_40$x_40"
-    set x $(sed -ne "/^$x_40\$/p" .git/HEAD .git/refs/*/* 2>/dev/null)
+    set x $(sed -ne "/^$x_40\$/p" \
+	"$GIT_DIR"/HEAD "$GIT_DIR"/refs/*/* /dev/null 2>/dev/null)
     shift ;;
 esac
 
@@ -28,13 +32,7 @@ sed -ne '/unreachable /{
     s/unreachable [^ ][^ ]* //
     s|\(..\)|\1/|p
 }' | {
-	for d in "$GIT_OBJECT_DIRECTORY" "$SHA1_FILE_DIRECTORY" ''
-	do
-		test "$d" != "" && test -d "$d" && break
-	done
-	case "$d" in
-	'') cd .git/objects/ ;;
-	*) cd "$d" ;;
-	esac || exit
+	cd "$GIT_OBJECT_DIRECTORY" || exit
 	xargs -r $dryrun rm -f
 }
+
--- a/git-pull-script
+++ b/git-pull-script
@@ -3,6 +3,9 @@
 merge_repo=$1
 merge_name=${2:-HEAD}
 
+: ${GIT_DIR=.git}
+: ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"}
+
 download_one () {
 	# remote_path="$1" local_file="$2"
 	case "$1" in
@@ -25,16 +28,19 @@ download_objects () {
 		git-local-pull -l -a "$2" "$1/"
 		;;
 	*)
-		rsync -avz --ignore-existing "$1/objects/." \
-			${SHA_FILE_DIRECTORY:-.git/objects}/.
+		rsync -avz --ignore-existing \
+			"$1/objects/." "$GIT_OBJECT_DIRECTORY"/.
 		;;
 	esac
 }
 
 echo "Getting remote $merge_name"
-download_one "$merge_repo/$merge_name" .git/MERGE_HEAD
+download_one "$merge_repo/$merge_name" "$GIT_DIR"/MERGE_HEAD
 
 echo "Getting object database"
-download_objects "$merge_repo" "$(cat .git/MERGE_HEAD)"
+download_objects "$merge_repo" "$(cat "$GIT_DIR"/MERGE_HEAD)"
 
-git-resolve-script "$(cat .git/HEAD)" "$(cat .git/MERGE_HEAD)" "$merge_repo"
+git-resolve-script \
+	"$(cat "$GIT_DIR"/HEAD)" \
+	"$(cat "$GIT_DIR"/MERGE_HEAD)" \
+	"$merge_repo"
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -1,14 +1,19 @@
 #!/bin/sh
 #
+# Copyright (c) 2005 Linus Torvalds
+#
 # Resolve two trees.
 #
 head="$1"
 merge="$2"
 merge_repo="$3"
 
-rm -f .git/MERGE_HEAD .git/ORIG_HEAD
-echo $head > .git/ORIG_HEAD
-echo $merge > .git/MERGE_HEAD
+: ${GIT_DIR=.git}
+: ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"}
+
+rm -f "$GIT_DIR"/MERGE_HEAD "$GIT_DIR"/ORIG_HEAD
+echo $head > "$GIT_DIR"/ORIG_HEAD
+echo $merge > "$GIT_DIR"/MERGE_HEAD
 
 #
 # The remote name is just used for the message,
@@ -35,7 +40,7 @@ if [ "$common" == "$head" ]; then
 	echo "Kill me within 3 seconds.."
 	sleep 3
 	git-read-tree -m $merge && git-checkout-cache -f -a && git-update-cache --refresh
-	echo $merge > .git/HEAD
+	echo $merge > "$GIT_DIR"/HEAD
 	git-diff-tree -p ORIG_HEAD HEAD | diffstat -p1
 	exit 0
 fi
@@ -51,6 +56,6 @@ if [ $? -ne 0 ]; then
 fi
 result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree -p $head -p $merge)
 echo "Committed merge $result_commit"
-echo $result_commit > .git/HEAD
+echo $result_commit > "$GIT_DIR"/HEAD
 git-checkout-cache -f -a && git-update-cache --refresh
 git-diff-tree -p ORIG_HEAD HEAD | diffstat -p1
--- a/git-tag-script
+++ b/git-tag-script
@@ -1,5 +1,9 @@
 #!/bin/sh
-object=${2:-$(cat .git/HEAD)}
+# Copyright (c) 2005 Linus Torvalds
+
+: ${GIT_DIR=.git}
+
+object=${2:-$(cat "$GIT_DIR"/HEAD)}
 type=$(git-cat-file -t $object) || exit 1
 ( echo -e "object $object\ntype $type\ntag $1\n"; cat ) > .tmp-tag
 rm -f .tmp-tag.asc
--- a/init-db.c
+++ b/init-db.c
@@ -27,11 +27,12 @@ int main(int argc, char **argv)
 	char *path;
 	int len, i;
 
-	safe_create_dir(".git");
-
-	sha1_dir = gitenv(DB_ENVIRONMENT);
-	if (!sha1_dir) {
-		sha1_dir = DEFAULT_DB_ENVIRONMENT;
+	sha1_dir = get_object_directory();
+	if (!gitenv(DB_ENVIRONMENT) && !gitenv(GIT_DIR_ENVIRONMENT)) {
+		/* We create leading paths only when we fall back
+		 * to local .git/objects, at least for now.
+		 */
+		safe_create_dir(DEFAULT_GIT_DIR_ENVIRONMENT);
 		fprintf(stderr, "defaulting to local storage area\n");
 	}
 	len = strlen(sha1_dir);
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -59,6 +59,38 @@ int get_sha1_file(const char *path, unsi
 	return get_sha1_hex(buffer, result);
 }
 
+static char *git_dir, *git_object_dir, *git_index_file;
+static void setup_git_env(void)
+{
+	git_dir = gitenv(GIT_DIR_ENVIRONMENT);
+	if (!git_dir)
+		git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
+	git_object_dir = gitenv(DB_ENVIRONMENT);
+	if (!git_object_dir) {
+		git_object_dir = xmalloc(strlen(git_dir) + 9);
+		sprintf(git_object_dir, "%s/objects", git_dir);
+	}
+	git_index_file = gitenv(INDEX_ENVIRONMENT);
+	if (!git_index_file) {
+		git_index_file = xmalloc(strlen(git_dir) + 7);
+		sprintf(git_index_file, "%s/index", git_dir);
+	}
+}
+
+char *get_object_directory(void)
+{
+	if (!git_object_dir)
+		setup_git_env();
+	return git_object_dir;
+}
+
+char *get_index_file(void)
+{
+	if (!git_index_file)
+		setup_git_env();
+	return git_index_file;
+}
+
 int get_sha1(const char *str, unsigned char *sha1)
 {
 	static char pathname[PATH_MAX];
@@ -70,15 +102,16 @@ int get_sha1(const char *str, unsigned c
 		"refs/snap",
 		NULL
 	};
-	const char *gitdir;
 	const char **p;
 
 	if (!get_sha1_hex(str, sha1))
 		return 0;
 
-	gitdir = ".git";
+	if (!git_dir)
+		setup_git_env();
 	for (p = prefix; *p; p++) {
-		snprintf(pathname, sizeof(pathname), "%s/%s/%s", gitdir, *p, str);
+		snprintf(pathname, sizeof(pathname), "%s/%s/%s",
+			 git_dir, *p, str);
 		if (!get_sha1_file(pathname, sha1))
 			return 0;
 	}

Re: Introducing GIT_DIR environment variable.

[Alex Riesen]

On 5/10/05, Junio C Hamano <junkio@cox.net> wrote:
> Ok, following the mailing list discussion, I've done GIT_DIR and
> pushed it out to the usual git-jc repository, at:
> 
>     http://members.cox.net/junkio/git-jc.git/
> 
> Author: Junio C Hamano <junkio@cox.net>
> Date:   Mon May 9 22:57:58 2005 -0700
> 
>     Introduce GIT_DIR environment variable.
> 

Just in case I missed it: was it already considered to use
the extended attributes (EAs) for saving pointer to GIT cache?
So I don't have to exclude anything from "grep -rn <pattern> ."

Re: [RFC] Renaming environment variables.

[Junio C Hamano]

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:

DB> While we're at it, it would be useful to have one for what is normally
DB> ".git", rather than just ".git/objects".

PB> I think it would be nice to have something like GIT_BASEDIR, which would
PB> default to .git, and the objects directory would then default to
PB> $GIT_BASEDIR/objects and the index file would default to
PB> $GIT_BASEDIR/index.

Although what I pushed out at git-jc repository does not have
this, it does not mean I forgot this issue you two have raised,
nor would want to veto it or anything like that.  Just that,
unlike the one that I already committed, the proposed change
would touch rather many lines and I have not managed to
determine the extent of the damage yet.

I am willing to make (or take) a separate patch to do this one,
since I agree with Petr's "currently we happen to have just two
but it would still be better to be able to set just one than
having to change both of them in sync." argument.

I am currently waiting for community consensus, including the
final name of the variable.  I think the current consensus is
that this is a good idea, the semantics for it is to name what
corresponds to the current "$(pwd)/.git" directory, use it to
build the default for GIT_INDEX_FILE and SHA1_FILE_DIRECTORY,
and this directory does _not_ have anything to do with my
previous "the directory that corresponds to the root of the tree
structure GIT_INDEX_FILE describes".  I agree to all of the
above.

Re: [RFC] Renaming environment variables.

[Daniel Barkalow]

On Mon, 9 May 2005, Junio C Hamano wrote:

> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
> 
> DB> While we're at it, it would be useful to have one for what is normally
> DB> ".git", rather than just ".git/objects".
> 
> PB> I think it would be nice to have something like GIT_BASEDIR, which would
> PB> default to .git, and the objects directory would then default to
> PB> $GIT_BASEDIR/objects and the index file would default to
> PB> $GIT_BASEDIR/index.
> 
> Although what I pushed out at git-jc repository does not have
> this, it does not mean I forgot this issue you two have raised,
> nor would want to veto it or anything like that.  Just that,
> unlike the one that I already committed, the proposed change
> would touch rather many lines and I have not managed to
> determine the extent of the damage yet.

It *should* only affect the places where the variables that depend on it
get computed; didn't you already centralize the code to figure this out?

> I am currently waiting for community consensus, including the
> final name of the variable.  I think the current consensus is
> that this is a good idea, the semantics for it is to name what
> corresponds to the current "$(pwd)/.git" directory, use it to
> build the default for GIT_INDEX_FILE and SHA1_FILE_DIRECTORY,
> and this directory does _not_ have anything to do with my
> previous "the directory that corresponds to the root of the tree
> structure GIT_INDEX_FILE describes".  I agree to all of the
> above.

I agree to all of that, too. I'd suggest GIT_DIR for the variable, simply
because I can't think of anything else that name could mean.

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] Renaming environment variables.

[Petr Baudis]

Dear diary, on Mon, May 09, 2005 at 10:05:00PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
>  - Renames the following environment variables:
> 
>     New name                Old Name
> 
>     GIT_AUTHOR_DATE         AUTHOR_DATE
>     GIT_AUTHOR_EMAIL        AUTHOR_EMAIL
>     GIT_AUTHOR_NAME         AUTHOR_NAME
>     GIT_COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_EMAIL
>     GIT_COMMIT_AUTHOR_NAME  COMMIT_AUTHOR_NAME
>     GIT_ALTERNATE_OBJECTS   SHA1_FILE_DIRECTORIES
>     GIT_OBJECTS             SHA1_FILE_DIRECTORY

Could I please have s/COMMIT_AUTHOR/COMMITTER/ and
s/OBJECTS/(OBJDIR|OBJECT_DIR)/?

> The transition plan is as follows:
> 
>  - We will keep the backward compatibility list used by gitenv()
>    for now, so the current scripts and user environments
>    continue to work as before.  The users will get warnings when
>    they have old name but not new name in their environment to
>    the stderr.
> 
>  - The Porcelain layers should start using new names.  However,
>    just in case it ends up calling old Plumbing layer
>    implementation, they should also export old names, taking
>    values from the corresponding new names, during the
>    transition period.

(Cogito needs its own git-merge-cache so that the merge goes properly
anyway, and it already (or still) carries its Git around, so I think
it's not applicable to it. Yes, I want and plan to start publishing the
Git changes, I'm already making some steps for that and I hope I have
something to show by tomorrow.)

>  - After a couple of weeks or so, we would drop the
>    compatibility support and drop gitenv().  Revert the callers
>    to directly call getenv() but keep using the new names.
> 
>    The last part is probably optional and the transition
>    duration needs to be set to a reasonable value.

Yes, I think couple of weeks is too long. :-) I'd say one or two
releases is enough.

> --- /dev/null
> +++ b/gitenv.c

Pretty please, add copyright notices at the top of files.

> +char *gitenv_bc(const char *e)
> +{
> +	int first, last;
> +	char *val = getenv(e);
> +	if (val)
> +		/* inefficient.  caller should use gitenv() not gitenv_bc() */
> +		return val;

Can this ever happen? If doing it at all, I'd expect gitenv_bc() to
rather freak out and die(), the caller is broken.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [RFC] Renaming environment variables.

[Junio C Hamano]

>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:

PB> Could I please have s/COMMIT_AUTHOR/COMMITTER/ and
PB> s/OBJECTS/(OBJDIR|OBJECT_DIR)/?

The former sounds much better.  The latter how about
GIT_OBJECT_DIRECTORY?  Not much longer than the original
SHA1_FILE_DIRECTORY anyway.

PB> (Cogito needs its own git-merge-cache so that the merge goes properly
PB> anyway, and it already (or still) carries its Git around, so I think
PB> it's not applicable to it. Yes, I want and plan to start publishing the
PB> Git changes, I'm already making some steps for that and I hope I have
PB> something to show by tomorrow.)

Sounds good.  BTW, what happened to the plan of merging with my
tip you sent a message earlier about?

PB> Yes, I think couple of weeks is too long. :-) I'd say one or two
PB> releases is enough.

I'd leave that to community and Linus to decide when he returns.

PB> Pretty please, add copyright notices at the top of files.

Thanks for pointing it out.

>> +char *gitenv_bc(const char *e)
>> +{
>> +	int first, last;
>> +	char *val = getenv(e);
>> +	if (val)
>> +		/* inefficient.  caller should use gitenv() not gitenv_bc() */
>> +		return val;

PB> Can this ever happen? If doing it at all, I'd expect gitenv_bc() to
PB> rather freak out and die(), the caller is broken.

Point taken.

I've pushed out an updated version that addresses all of the
above issues to git-jc repository [*1*].  Please take a look.

[References]
*1* http://members.cox.net/junkio/