[PATCH 1/2] Build GIT_VERSION from VERSION, PATCHLEVEL, and SUBLEVEL variables.

[PATCH 1/2] Build GIT_VERSION from VERSION, PATCHLEVEL, and SUBLEVEL variables.

[Martin Atukunda]

This will allow scripts to be able to determine which git release they
target (or require).

Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>

---

 Makefile |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

applies-to: 1e3fcf60526c196a46433e6947c9104ca236f230
968e5b59fba66a1b146c643e5161978c787d4273
diff --git a/Makefile b/Makefile
index ebff990..74c6b9e 100644
--- a/Makefile
+++ b/Makefile
@@ -50,7 +50,11 @@
 # Define USE_STDEV below if you want git to care about the underlying device
 # change being considered an inode change from the update-cache perspective.
 
-GIT_VERSION = 0.99.9.GIT
+VERSION = 0
+PATCHLEVEL = 99
+SUBLEVEL = 9
+EXTRAVERSION = GIT
+GIT_VERSION=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL).$(EXTRAVERSION)
 
 # CFLAGS and LDFLAGS are for the users to override from the command line.
 
---
0.99.9.GIT

[PATCH] Add .git/version

[Martin Atukunda]

This patch series attempts to add .git/version support to init-db.c. THis
is an overview of the patches.

First patch makes the Makefile build GIT_VERSION from the variables VERSION,
PATCHLEVEL, and SUBLEVEL ala the kernel. These variables will be used later
in init-db.c

Second patch adds support to init-db.c for writing the .git/version file.

- Martin -

[PATCH 2/2] Make init-db record the version in $GIT_DIR/version when creating repo.

[Martin Atukunda]

Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>

---

 Makefile  |    3 +++
 init-db.c |   15 +++++++++++++++
 2 files changed, 18 insertions(+), 0 deletions(-)

applies-to: ec55de586902d26b3f55c3d0aeabf94be1b82586
ec733719bfee2ade91416bd429eeefe6c4acb5a8
diff --git a/Makefile b/Makefile
index 74c6b9e..c167120 100644
--- a/Makefile
+++ b/Makefile
@@ -400,6 +400,9 @@ git-rev-list$X: LIBS += $(OPENSSL_LIBSSL
 
 init-db.o: init-db.c
 	$(CC) -c $(ALL_CFLAGS) \
+		-DVERSION='"$(VERSION)"' \
+		-DPATCHLEVEL='"$(PATCHLEVEL)"' \
+		-DSUBLEVEL='"$(SUBLEVEL)"' \
 		-DDEFAULT_GIT_TEMPLATE_DIR=$(call shellquote,"$(template_dir)") $*.c
 
 $(LIB_OBJS): $(LIB_H)
diff --git a/init-db.c b/init-db.c
index bd88291..6230e8e 100644
--- a/init-db.c
+++ b/init-db.c
@@ -19,6 +19,17 @@ static void safe_create_dir(const char *
 	}
 }
 
+static void record_repo_version(const char *path)
+{
+	FILE *verfile = fopen(path, "w");
+	if (!verfile)
+		die ("Can not write to %s?", path);
+	
+	fprintf(verfile, "%d.%d.%d\n", VERSION, PATCHLEVEL, SUBLEVEL);
+	
+	fclose(verfile);
+}
+
 static int copy_file(const char *dst, const char *src, int mode)
 {
 	int fdi, fdo, status;
@@ -212,6 +223,10 @@ static void create_default_files(const c
 				fprintf(stderr, "Ignoring file modes\n");
 		}
 	}
+
+	/* record the version of the git repo */
+	strcpy(path + len, "version");
+	record_repo_version(path);
 }
 
 static const char init_db_usage[] =
---
0.99.9.GIT

Re: [PATCH] Add .git/version

[Johannes Schindelin]

Hi,

On Thu, 17 Nov 2005, Martin Atukunda wrote:

> This patch series attempts to add .git/version support to init-db.c.

Wouldn't it make more sense to add the variable VERSION to git-var? After 
all, git is designed to be backwards compatible; newer versions are 
supposed to work with ancient repositories.

I think you are more interested in knowing which version the tools are at.

Ciao,
Dscho

Re: [PATCH] Add .git/version

[Martin Atukunda]

On Thu, Nov 17, 2005 at 02:39:21PM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 17 Nov 2005, Martin Atukunda wrote:
> 
> > This patch series attempts to add .git/version support to init-db.c.
> 
> Wouldn't it make more sense to add the variable VERSION to git-var? After 
> all, git is designed to be backwards compatible; newer versions are 
> supposed to work with ancient repositories.
> 
> I think you are more interested in knowing which version the tools are at.

Actually this patch series is more a response to the thread
"Re: [PATCH] Disable USE_SYMLINK_HEAD by default" in  particular see
this message 200511160205.43443.Josef.Weidendorfer@gmx.de by Josef
Weidendorfer.

We've had at least one change that was backwards incompatible, though
this was in the ancient days of git development. This patch allows git to record what
version of the git tools created the repo we are dealing with. Just in
case future changes require this.

- Martin -

-- 
Due to a shortage of devoted followers, the production of great leaders has been discontinued.

Re: [PATCH] Add .git/version

[Johannes Schindelin]

Hi,

On Thu, 17 Nov 2005, Martin Atukunda wrote:

> On Thu, Nov 17, 2005 at 02:39:21PM +0100, Johannes Schindelin wrote:
> > 
> > I think you are more interested in knowing which version the tools are at.
> 
> Actually this patch series is more a response to the thread
> "Re: [PATCH] Disable USE_SYMLINK_HEAD by default" in  particular see
> this message 200511160205.43443.Josef.Weidendorfer@gmx.de by Josef
> Weidendorfer.

When we disable USE_SYMLINK_HEAD by default, tools are expected to work 
with USE_SYMLINK_HEAD enabled, too, so .git/version is not needed for 
that.

But yes, it might be handy to know at some time. But I think it would make 
sense to add .git/version *then*, because you can distinguish repositories 
before/after the change by testing for .git/version.

Ciao,
Dscho

Re: [PATCH] Add .git/version

[Josef Weidendorfer]

On Thursday 17 November 2005 14:25, Martin Atukunda wrote:
> This patch series attempts to add .git/version support to init-db.c. THis
> is an overview of the patches.

As .git/version is part of the repository, it should contain the version
of the repository format used. Do you really want to link the version
of the repository format with the version of git which created the
repository? It think it is better to detach a repository version from
version of git.

Why? Ideally, the git commands first should check if they can handle the
repository format. If they can not handle the version, they should bail
out with an error [*]
Now suppose we want to release Git 2 without change the repository
format at all. Thus, even if Git 1 tool *would* work with repositories
created by Git 2, they will fail in the version check!

If this is meant to be used in scripts (as your commit comment mentions):
a script should never touch any files in the repository directly, but go
via commands supplied with git. So these scripts should actually check
against the version of installed git. Thus, such a version string should go
into git-var or better simply use the existing "git --version"?

Josef

[*] Junio: This should be done before Git 1.0 - it is needed to be able
to change the repository format in the future without taking the risk
that old git commands possibly corrupt a repo in the new format. This
has nothing to do with backwards compatibility. Without a version, we
are forced to be forwards compatible ;-)
Needed in init-db.c is a "echo 1 >.git/version"; and the mentioned check
in the tools against this version.

Re: [PATCH] Add .git/version

[Josef Weidendorfer]

On Thursday 17 November 2005 16:38, Johannes Schindelin wrote:
> But yes, it might be handy to know at some time. But I think it would make 
> sense to add .git/version *then*, because you can distinguish repositories 
> before/after the change by testing for .git/version.

No, as old git tools then still could corrupt a repository with a new format,
as they currently do not check any kind of format version; it would work if
the git 1 tools would bail out if a .git/version is found ;-)

Josef

Re: [PATCH] Add .git/version

[Andreas Ericsson]

Josef Weidendorfer wrote:
> On Thursday 17 November 2005 14:25, Martin Atukunda wrote:
> 
> As .git/version is part of the repository, it should contain the version
> of the repository format used. Do you really want to link the version
> of the repository format with the version of git which created the
> repository? It think it is better to detach a repository version from
> version of git.
> 
> Why? Ideally, the git commands first should check if they can handle the
> repository format. If they can not handle the version, they should bail
> out with an error [*]
> Now suppose we want to release Git 2 without change the repository
> format at all. Thus, even if Git 1 tool *would* work with repositories
> created by Git 2, they will fail in the version check!
> 

Not that I have an opinion on these changes, but Netscape 7 still 
handles HTTP 1.1. Just because we up the major-number for git doesn't 
mean we have to do the same for the repository format version.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH] Add .git/version

[Josef Weidendorfer]

On Thursday 17 November 2005 17:33, Andreas Ericsson wrote:
> > Why? Ideally, the git commands first should check if they can handle the
> > repository format. If they can not handle the version, they should bail
> > out with an error [*]
> > Now suppose we want to release Git 2 without change the repository
> > format at all. Thus, even if Git 1 tool *would* work with repositories
> > created by Git 2, they will fail in the version check!
> > 
> 
> Not that I have an opinion on these changes, but Netscape 7 still 
> handles HTTP 1.1. Just because we up the major-number for git doesn't 
> mean we have to do the same for the repository format version.

Of course we do not want that.
My comment was about this, as the proposed patch installed a
.git/version file with the git version in it, which would lead to
this strange result.

Josef

Re: [PATCH] Add .git/version

[Martin Atukunda]

On Thu, Nov 17, 2005 at 05:41:23PM +0100, Josef Weidendorfer wrote:
> On Thursday 17 November 2005 17:33, Andreas Ericsson wrote:
> > > Why? Ideally, the git commands first should check if they can handle the
> > > repository format. If they can not handle the version, they should bail
> > > out with an error [*]
> > > Now suppose we want to release Git 2 without change the repository
> > > format at all. Thus, even if Git 1 tool *would* work with repositories
> > > created by Git 2, they will fail in the version check!
> > > 
> > 
> > Not that I have an opinion on these changes, but Netscape 7 still 
> > handles HTTP 1.1. Just because we up the major-number for git doesn't 
> > mean we have to do the same for the repository format version.
> 
> Of course we do not want that.
> My comment was about this, as the proposed patch installed a
> .git/version file with the git version in it, which would lead to
> this strange result.
> 
I agree, I'll resubmit a patch to create a .git/version file that simply
says 1.

which specific git commands would most likely want to know about the
version of the repo format? I could look at them to see what needs to be
changed so that they don't corrupt a repo, or as Johannes said, the use
of this file would become handy only when an incompatible change is
made. In which case, init-db.c just creates it for now, as a simple safe
guard.

- Martin -

-- 
Due to a shortage of devoted followers, the production of great leaders has been discontinued.

[PATCH] Add .git/version (Take 2)

[Martin Atukunda]

Currently the version number can be considered version 1, so this patch
just sets it to that. This patch supercedes my earlier attempt that
erroneously used the git version number as the repo format version.

Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>

---

 init-db.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

applies-to: d1bb16b919a119cca6ee001f755f83251a2c2964
31e78e387d708da5e09f40436d5fdc9e9ec5e16c
diff --git a/init-db.c b/init-db.c
index bd88291..e403dac 100644
--- a/init-db.c
+++ b/init-db.c
@@ -9,6 +9,8 @@
 #define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates/"
 #endif
 
+#define REPO_VERSION 1
+
 static void safe_create_dir(const char *dir)
 {
 	if (mkdir(dir, 0777) < 0) {
@@ -19,6 +21,17 @@ static void safe_create_dir(const char *
 	}
 }
 
+static void record_repo_version(const char *path)
+{
+	FILE *verfile = fopen(path, "w");
+	if (!verfile)
+		die ("Can not write to %s?", path);
+	
+	fprintf(verfile, "%d\n", REPO_VERSION);
+	
+	fclose(verfile);
+}
+
 static int copy_file(const char *dst, const char *src, int mode)
 {
 	int fdi, fdo, status;
@@ -212,6 +225,10 @@ static void create_default_files(const c
 				fprintf(stderr, "Ignoring file modes\n");
 		}
 	}
+
+	/* record the version of the git repo */
+	strcpy(path + len, "version");
+	record_repo_version(path);
 }
 
 static const char init_db_usage[] =
---
0.99.9.GIT

-- 
Due to a shortage of devoted followers, the production of great leaders has been discontinued.

Re: [PATCH] Add .git/version

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> [*] Junio: This should be done before Git 1.0 - it is needed to be able
> to change the repository format in the future without taking the risk
> that old git commands possibly corrupt a repo in the new format. This
> has nothing to do with backwards compatibility. Without a version, we
> are forced to be forwards compatible ;-)
> Needed in init-db.c is a "echo 1 >.git/version"; and the mentioned check
> in the tools against this version.

I agree with the general direction.

 - Futureproofing is good.

 - We want repository-format-version but that may be too
   long. Just saying version is a bit confusing.  Abbreviating
   it to repository-version makes it sound as if somebody took a
   snapshot (i.e. tar-tree $commit).  Whatever name we choose,
   let's pick a one not so confusing.

 - Not having .git/version (or whatever name) signals the tools
   our repository is in the original format.  This will keep the
   existing repositories happy.  What this means is that the
   tools need to check for the absense of .git/version in this
   round.  When we change the repository format, we will have
   .git/version file that records it.

 - You can run git-init-db on an existing repository.  This is
   sometimes handy if you added a new hook in the template suite
   and want to copy it over (it never overwrites but happily
   copies what you do not have).  This mechanism needs to be
   told about the version file -- specifically, it should check
   version in the template area and refuse to do use that
   template if it does not match the repository.  Similarly,
   when creating a repository from scratch, it should not copy
   the version file from templates.

Re: [PATCH] Add .git/version

[Linus Torvalds]

On Thu, 17 Nov 2005, Junio C Hamano wrote:
> 
>  - We want repository-format-version but that may be too
>    long. Just saying version is a bit confusing.  Abbreviating
>    it to repository-version makes it sound as if somebody took a
>    snapshot (i.e. tar-tree $commit).  Whatever name we choose,
>    let's pick a one not so confusing.

My one argument against this is that I don't see why we have to have a 
separate file for this.

Why not just add a "core.version" flag to the config file? If no version 
exists, assume it's version 1. And then, if we ever start using some other 
version, make git-init-db always create the config file (the way we 
already do for "core.filemode")

Sure, people can edit the version flag by hand, but hey, that's true even 
if it's in a separate .git/version file.

		Linus

Re: [PATCH] Add .git/version

[Johannes Schindelin]

Hi,

On Thu, 17 Nov 2005, Linus Torvalds wrote:

> On Thu, 17 Nov 2005, Junio C Hamano wrote:
> > 
> >  - We want repository-format-version but that may be too
> >    long. Just saying version is a bit confusing.  Abbreviating
> >    it to repository-version makes it sound as if somebody took a
> >    snapshot (i.e. tar-tree $commit).  Whatever name we choose,
> >    let's pick a one not so confusing.
> 
> My one argument against this is that I don't see why we have to have a 
> separate file for this.
> 
> Why not just add a "core.version" flag to the config file? If no version 
> exists, assume it's version 1. And then, if we ever start using some other 
> version, make git-init-db always create the config file (the way we 
> already do for "core.filemode")

Note that git-sh-setup and setup_git_directory() should check for it and 
complain if it finds a value > 1. Else there is not much which prevents 
old tools (like current) to access future versions.

The actual number may come later. The check can't.

Ciao,
Dscho

Re: [PATCH] Add .git/version

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> My one argument against this is that I don't see why we have to have a 
> separate file for this.

True.

> Why not just add a "core.version" flag to the config file?

True, perhaps core.repository-format-version?