threads / patch / 2563
Subject: [PATCH 1/2] Build GIT_VERSION from VERSION, PATCHLEVEL, and SUBLEVEL variables.
[PATCH] Add .git/version
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 -
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 2/2] Make init-db record the version in $GIT_DIR/version when creating repo.
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
Makefile, init-db.c
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
Johannes SchindelinRe: [PATCH] Add .git/version
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
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.
Johannes SchindelinRe: [PATCH] Add .git/version
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
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
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.
Andreas EricssonRe: [PATCH] Add .git/version
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
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
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)
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.
Junio C HamanoRe: [PATCH] Add .git/version
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.
Linus TorvaldsRe: [PATCH] Add .git/version
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
Johannes SchindelinRe: [PATCH] Add .git/version
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
Junio C HamanoRe: [PATCH] Add .git/version
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?