From: Junio C Hamano <junkio@cox.net>
Date: Thu, 17 Nov 2005 19:25:16 GMT
Subject: Re: [PATCH] Add .git/version
Message-ID: <7v7jb7uler.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200511171644.48438.Josef.Weidendorfer@gmx.de>

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.