Re: [PATCH] Disable USE_SYMLINK_HEAD by default

Pavel Roskin [off-list ref] writes:

In particular, StGIT still needs fixing.

quoted

The only thing I can think of that might be inconvenient is if
you try doing "cp -a" off of a filesystem that supports symlinks
to another filesystem that does not -- probably that would fail
copying the symlinked .git/HEAD.  But if that is the problem,
you could always git-clone, which should do the right thing, I
think.

I'm talking from my experience now.  If there is an option, there are
users that have it enabled and those who have it disabled (by
definition).  As is often happens, one of the configurations is more
popular with developers.  The other configuration almost inevitably
starts suffering from the "bit rot".

That's a real concern, I should agree.

Junio C Hamano [off-list ref] writes:

Pavel Roskin [off-list ref] writes:

quoted

In particular, StGIT still needs fixing.

quoted

...

I'm talking from my experience now.  If there is an option, there are
users that have it enabled and those who have it disabled (by
definition).  As is often happens, one of the configurations is more
popular with developers.  The other configuration almost inevitably
starts suffering from the "bit rot".

That's a real concern, I should agree.

I think I need to qualify this comment.  It is a real concern
because we need to know when it is safe to start using textual
symrefs everywhere, *if* we would want to do that switch.

I wonder how ready StGIT and Cogito are, but also I wonder how
ready other things are.  People built homebrew scripts around
git without calling them Porcelains, and git is designed to be
used that way.  We do not know how many things we are breaking
if we switch to do textual symrefs by default.

I just checked the latest gitweb, and it does not seem to be
ready.  I do not, however, necessarily think it is a high
priority problem.  It does not feel to me a realistic issue that
you cannot serve a public repository on a filesystem incapable
of symlinks via getweb.  This change is breaking things for
gitweb running on kernel.org machines without real benefit.

Thinking about it a bit more, the current setup to use symlinks
on systems that supports them, and textual symrefs on others, is
looking more and more sensible to me.  If supporting
symlink-challenged filesystems become a real issue for a "third
party tool", certainly that will be updated, because people
would want it.  Switching to do textual symrefs by default
everywhere is a way to *force* people to scramble and update
their scripts everywhere, but I am not so sure that is worth it;
I cannot justify why I'd be forcing them to do so, especially if
supporting VFAT is a low priority for some of the tools.

"Bit rot" may first seem a concern, but actually it is not.  I
suspect that serverish applications such as gitweb view
supporting symlink-challenged filesystems as a lower priority
task, while more client-oriented applications rate it higher.
The core support for textual symrefs cannot afford to rot as
long as some Porcelain needs it, and worrying about it would not
be a good justification to break everybody "just to see what
breaks".  On the other hand, if the support for textual symrefs
rot, it probably deserves to --- the only reason that would
happen would be because nobody uses them.

IOW, if we see real breakage in either git itself or Porcelains
that use git, send in fixes to appropriate parties.  I think
that's being constructive.  Otherwise, let's not break things
just for the sake of consistency.  I do not think that is
helping anything.

Hi,

I think Junio is right: we should not force everybody not to use symlinks, 
only because there happens to be VFAT-, SMB- or HTTP-shared repositories. 
As Junio says, if there are people experiencing problems because they lack 
symbolic links, they should fix it.

On the other hand, I think it would be useful to be able to configure the 
behaviour via .git/config.

Ciao,
Dscho

Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter
where Johannes Schindelin [off-list ref] said that...

I think Junio is right: we should not force everybody not to use symlinks, 
only because there happens to be VFAT-, SMB- or HTTP-shared repositories. 
As Junio says, if there are people experiencing problems because they lack 
symbolic links, they should fix it.

I'm ambivalent here. I would like to have just a single behaviour here,
since the symbolic ref otherwise really does not get much testing. But I
can also understand that we are breaking tools here.

Still, for the reason above, I think we should aim at the symbolic refs
being the canonical format in the next major release after 1.0, giving
users time to fix their tools. I can see no advantage in symlinks except
the backwards compatibility - speed argument was presented, but I don't
buy that until I see hard data supporting that.

On the other hand, I think it would be useful to be able to configure the 
behaviour via .git/config.

Yes, I would very much like to have this. I still want to go
symrefs-only for public repositories created for cg-admin-setuprepo, so
that fetching over HTTP works properly.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Hi,

On Tue, 15 Nov 2005, Petr Baudis wrote:

Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter
where Johannes Schindelin [off-list ref] said that...

quoted

I think Junio is right: we should not force everybody not to use 
symlinks, only because there happens to be VFAT-, SMB- or HTTP-shared 
repositories. As Junio says, if there are people experiencing problems 
because they lack symbolic links, they should fix it.

I'm ambivalent here. I would like to have just a single behaviour here, 
since the symbolic ref otherwise really does not get much testing. But I 
can also understand that we are breaking tools here.

Still, for the reason above, I think we should aim at the symbolic refs
being the canonical format in the next major release after 1.0, giving
users time to fix their tools. I can see no advantage in symlinks except
the backwards compatibility - speed argument was presented, but I don't
buy that until I see hard data supporting that.

<yousortofaskedforit>
Well, I can see no good reason for symrefs, except for backwards 
compatibility! Modern systems do support symlinks, you know?

Let´s face it. The main target for git is not Windows users. If we really 
want to support all idiocies of all possible ones, how about this one:

If I clone a repository to a USB stick on cygwin, and try to access it 
from my iBook, it does not work, because for *backward compatibility* 
reasons, files fitting the 8.3 format are stored in UPPER CASE.

So, I would like to have support for UPPER CASE files in .git, please? And 
since I cannot do my own testing, please could you force everybody´s git 
to write OBJECTS and MASTER in UPPER CASE?
</yousortofaskedforit>

Ciao,
Dscho

Well, I can see no good reason for symrefs, except for backwards
compatibility! Modern systems do support symlinks, you know?

What about less modern systems? I like to have tools that work on those, too.

Let´s face it. The main target for git is not Windows users.

Yes, but they are a worthy secondary target.

If we really want to support all idiocies of all possible ones,

I don't think we want that, but I don't think the symref vs. symlink
issue is an idiocy either.

how about this one:

If I clone a repository to a USB stick on cygwin, and try to access it
from my iBook, it does not work, because for *backward compatibility*
reasons, files fitting the 8.3 format are stored in UPPER CASE.

So, I would like to have support for UPPER CASE files in .git, please? And
since I cannot do my own testing, please could you force everybody´s git
to write OBJECTS and MASTER in UPPER CASE?

Long and mixed-case filenames are supported almost universally. Why
aren't you using FAT32 on your USB key? Even that decade-old
filesystem supports them.

On Tue, 2005-11-15 at 15:24 +0100, Johannes Schindelin wrote:

<yousortofaskedforit>
Well, I can see no good reason for symrefs, except for backwards 
compatibility! Modern systems do support symlinks, you know?

You misunderstood me here.  I meant backward compatibility with git
wrappers, not with old operating systems.

I meant, the only reason we don't want symrefs to be used by default is
because there are wrappers around git that only work with symlinks.  So,
if we change the default behavior in git now, those wrappers will break
on new repositories.

Let´s face it. The main target for git is not Windows users. If we really 
want to support all idiocies of all possible ones, how about this one:

If I clone a repository to a USB stick on cygwin, and try to access it 
from my iBook, it does not work, because for *backward compatibility* 
reasons, files fitting the 8.3 format are stored in UPPER CASE.

So, I would like to have support for UPPER CASE files in .git, please? And 
since I cannot do my own testing, please could you force everybody´s git 
to write OBJECTS and MASTER in UPPER CASE?

That was pretty funny :-)

Actually, what's different about symlinks is that they go beyond the
paradigm of one data stream per file.  There are two data streams
accessible through the symlink, one being the data in the file it points
to, and the other being the path to that file.

This doesn't map well to many data transfer protocols.  We don't want
git to work only over protocols that have explicit support for symlinks.

One example is http, sometimes the only protocol allowed to transcend
corporate firewalls.

Another, more controversial example is CVS.  Sourceforge doesn't support
git, but I could store my git database in Sourceforge CVS, and thus
share it with other contributors.  Not being able to put .git/HEAD there
would be an annoyance.

I believe Cygwin developers were actually more concerned about symlinks
damaged by SMB than about any issues with storing them locally.  After
all, Cygwin is quite good at emulating POSIX, including symlinks.

Returning to your example, 8.3 format is a problem with storage.  Those
are behind us.  It's problems with transfer that are going to limit us.

-- 
Regards,
Pavel Roskin

On Tue, 2005-11-15 at 13:18 +0100, Petr Baudis wrote:

Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter
where Johannes Schindelin [off-list ref] said that...

quoted

I think Junio is right: we should not force everybody not to use symlinks, 
only because there happens to be VFAT-, SMB- or HTTP-shared repositories. 
As Junio says, if there are people experiencing problems because they lack 
symbolic links, they should fix it.

I'm ambivalent here. I would like to have just a single behaviour here,
since the symbolic ref otherwise really does not get much testing. But I
can also understand that we are breaking tools here.

Still, for the reason above, I think we should aim at the symbolic refs
being the canonical format in the next major release after 1.0, giving
users time to fix their tools. I can see no advantage in symlinks except
the backwards compatibility - speed argument was presented, but I don't
buy that until I see hard data supporting that.

I planned to write about symrefs long ago, and probably I waited for too
long.  I still hope it will be the default for 1.0 release, but if not,
I hope the next release won't be too far away.

quoted

On the other hand, I think it would be useful to be able to configure the 
behaviour via .git/config.

Yes, I would very much like to have this. I still want to go
symrefs-only for public repositories created for cg-admin-setuprepo, so
that fetching over HTTP works properly.

Agreed.  By the way, the symref doesn't need to be called HEAD - it
could be "trunk" or "main" or "default-branch".

-- 
Regards,
Pavel Roskin

On Tuesday 15 November 2005 13:18, Petr Baudis wrote:

being the canonical format in the next major release after 1.0, giving

Talking about versions...
Do we have an easy way to detect the format version of a git repository?
If not, I suggest git-init-db to add something like
	echo "1" > .git/version
and let all the git-tools which read/write any files in .git themself
test against version 1. Or is this overkill?

Josef

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

Signed-Off-By: Martin Atukunda <redacted>

---

 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

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 -

Signed-Off-By: Martin Atukunda <redacted>

---

 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

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

On Thu, Nov 17, 2005 at 02:39:21PM +0100, Johannes Schindelin wrote:

Hi,

On Thu, 17 Nov 2005, Martin Atukunda wrote:

quoted

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.

Hi,

On Thu, 17 Nov 2005, Martin Atukunda wrote:

On Thu, Nov 17, 2005 at 02:39:21PM +0100, Johannes Schindelin wrote:

quoted

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

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.

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

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

On Thursday 17 November 2005 17:33, Andreas Ericsson wrote:

quoted

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

On Thu, Nov 17, 2005 at 05:41:23PM +0100, Josef Weidendorfer wrote:

On Thursday 17 November 2005 17:33, Andreas Ericsson wrote:

quoted

quoted

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.

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 <redacted>

---

 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.

Josef Weidendorfer [off-list ref] 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.

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

Hi,

On Thu, 17 Nov 2005, Linus Torvalds wrote:

On Thu, 17 Nov 2005, Junio C Hamano wrote:

quoted

 - 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

Linus Torvalds [off-list ref] 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?