From: Junio C Hamano <junkio@cox.net>
To: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Cc: git@vger.kernel.org, Martin Atukunda <matlads@dsmagic.com>
Subject: Re: [PATCH] Add .git/version
Date: Thu, 17 Nov 2005 11:25:16 -0800 [thread overview]
Message-ID: <7v7jb7uler.fsf@assigned-by-dhcp.cox.net> (raw)
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.
next prev parent reply other threads:[~2005-11-17 19:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-17 13:25 [PATCH] Add .git/version Martin Atukunda
2005-11-17 13:25 ` [PATCH 1/2] Build GIT_VERSION from VERSION, PATCHLEVEL, and SUBLEVEL variables Martin Atukunda
2005-11-17 13:25 ` [PATCH 2/2] Make init-db record the version in $GIT_DIR/version when creating repo Martin Atukunda
2005-11-17 13:39 ` [PATCH] Add .git/version Johannes Schindelin
2005-11-17 15:16 ` Martin Atukunda
2005-11-17 15:38 ` Johannes Schindelin
2005-11-17 16:04 ` Josef Weidendorfer
2005-11-17 15:44 ` Josef Weidendorfer
2005-11-17 16:33 ` Andreas Ericsson
2005-11-17 16:41 ` Josef Weidendorfer
2005-11-17 19:08 ` Martin Atukunda
2005-11-17 19:18 ` [PATCH] Add .git/version (Take 2) Martin Atukunda
2005-11-17 19:25 ` Junio C Hamano [this message]
2005-11-17 19:35 ` [PATCH] Add .git/version Linus Torvalds
2005-11-17 23:41 ` Johannes Schindelin
2005-11-18 0:49 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v7jb7uler.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=Josef.Weidendorfer@gmx.de \
--cc=git@vger.kernel.org \
--cc=matlads@dsmagic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).