From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
These patches enables .git to be a textfile containing the path to the git
directory proper. It passes all the tests so hopefully there are no
regressions, but there may be bugs and omissions lurking when this feature
is actually used; I've exercised it in my git, cgit and dayjob repos but git
is big and has many codepaths so I wouldn't be suprised if there still are
some git commands left which fails to obey the .git file.
PS: These patches could certainly be squashed into a single patch, but I've
left them as is to make each one easier to review.
PPS: If included, the .git file should probably be used by git-submodule to
clone submodule repositories into something like $GIT_DIR/submodules/<name>,
as that would make local submodule changes more resistant to dataloss due to
checkout/reset in the containing repository.
Shortlog:
Add platform-independent .git "symlink"
Fix setup of $GIT_DIR in git-sh-setup.sh
Teach resolve_gitlink_ref() about the .git file
git-submodule: prepare for the .git-file
Teach GIT-VERSION-GEN about the .git file
Diffstat:
Documentation/repository-layout.txt | 5 ++-
GIT-VERSION-GEN | 2 +-
cache.h | 1 +
environment.c | 38 ++++++++++++++++++
git-sh-setup.sh | 12 ++---
git-submodule.sh | 4 +-
refs.c | 17 +++++++-
setup.c | 9 ++++
t/t0002-gitfile.sh | 74 +++++++++++++++++++++++++++++++++++
9 files changed, 148 insertions(+), 14 deletions(-)
From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
When .git in a submodule is a file, resolve_gitlink_ref() needs to pick up
the real GIT_DIR of the submodule from that file.
Signed-off-by: Lars Hjemli <redacted>
---
refs.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
@@ -11,7 +11,7 @@ LF=' if test -f version then VN=$(cat version) || VN="$DEF_VER"-elif test -d .git &&+elif test -d .git -o -f .git && VN=$(git describe --abbrev=4 HEAD 2>/dev/null) && case "$VN" in *$LF*) (exit 1) ;;
From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
This patch allows .git to be a regular textfile containing the path of
the real git directory (formatted like "gitdir: <path>\n"), which is
useful on platforms lacking support for real symlinks.
Signed-off-by: Lars Hjemli <redacted>
---
Documentation/repository-layout.txt | 5 ++-
cache.h | 1 +
environment.c | 38 ++++++++++++++++++
setup.c | 9 ++++
t/t0002-gitfile.sh | 74 +++++++++++++++++++++++++++++++++++
5 files changed, 126 insertions(+), 1 deletions(-)
create mode 100755 t/t0002-gitfile.sh
@@ -3,7 +3,10 @@ git repository layout You may find these things in your git repository (`.git` directory for a repository associated with your working tree, or-`'project'.git` directory for a public 'bare' repository).+`'project'.git` directory for a public 'bare' repository. It is+also possible to have a working tree where `.git` is a plain+ascii file containing `gitdir: <path>\n`, i.e. the path to the+real git repository). objects:: Object store associated with this repository. Usually
From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
When git-submodule tries to detect 'active' submodules, it checks for the
existence of a directory named '.git'. This isn't good enough now that .git
can be a file pointing to the real $GIT_DIR so the tests are changed to
reflect this.
Signed-off-by: Lars Hjemli <redacted>
---
git-submodule.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
Since .git can be a file refering to the real GIT_DIR, git-sh-setup needs
to use 'git rev-parse --git-dir' to obtain the location of the git
repository.
Signed-off-by: Lars Hjemli <redacted>
---
git-sh-setup.sh | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
@@ -127,20 +127,18 @@ get_author_ident_from_commit () {# if we require to be in a git repository.iftest-z"$NONGIT_OK"then+GIT_DIR=$(gitrev-parse--git-dir)||{+exit=$?+echo>&2"Failed to find a valid git directory."+exit$exit+}if[-z"$SUBDIRECTORY_OK"]then-:${GIT_DIR=.git}test-z"$(gitrev-parse--show-cdup)"||{exit=$?echo>&2"You need to run this command from the toplevel of the working tree."exit$exit}-else-GIT_DIR=$(gitrev-parse--git-dir)||{-exit=$?-echo>&2"Failed to find a valid git directory."-exit$exit-}fitest-n"$GIT_DIR"&&GIT_DIR=$(cd"$GIT_DIR"&&pwd)||{echo>&2"Unable to determine absolute path of git directory"
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:14
Hi,
On Sun, 17 Feb 2008, Lars Hjemli wrote:
PPS: If included, the .git file should probably be used by git-submodule
to clone submodule repositories into something like
$GIT_DIR/submodules/<name>, as that would make local submodule changes
more resistant to dataloss due to checkout/reset in the containing
repository.
I don't buy that argument. For the moment, the submodules are
self-contained repositories. The superproject does not even have to have
a single object contained in a submodule. I'd try to keep that
separation.
As for data loss, again, as a submodule is self-contained, the same rules
apply to it as for any repository.
Ciao,
Dscho
From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
On Feb 17, 2008 11:20 PM, Johannes Schindelin
[off-list ref] wrote:
Hi,
On Sun, 17 Feb 2008, Lars Hjemli wrote:
quoted
PPS: If included, the .git file should probably be used by git-submodule
to clone submodule repositories into something like
$GIT_DIR/submodules/<name>, as that would make local submodule changes
more resistant to dataloss due to checkout/reset in the containing
repository.
I don't buy that argument. For the moment, the submodules are
self-contained repositories. The superproject does not even have to have
a single object contained in a submodule. I'd try to keep that
separation.
They would still be separated and self-contained repositories, but
with my suggestion the submodule repository would be moved out of the
working tree of the containing repository. Which I believe is a good
thing, especially when you switch from one branch in the containing
repository which had the submodule in './foo' to another branch where
the submodule is located in './lib/foo'.
--
larsh
From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
This patch allows .git to be a regular textfile containing the path of
the real git directory (formatted like "gitdir: <path>\n"), which is
useful on platforms lacking support for real symlinks.
Signed-off-by: Lars Hjemli <redacted>
---
Documentation/repository-layout.txt | 5 ++-
cache.h | 1 +
environment.c | 38 ++++++++++++++++++
setup.c | 9 ++++
t/t0002-gitfile.sh | 74 +++++++++++++++++++++++++++++++++++
5 files changed, 126 insertions(+), 1 deletions(-)
create mode 100755 t/t0002-gitfile.sh
@@ -3,7 +3,10 @@ git repository layout You may find these things in your git repository (`.git` directory for a repository associated with your working tree, or-`'project'.git` directory for a public 'bare' repository).+`'project'.git` directory for a public 'bare' repository. It is+also possible to have a working tree where `.git` is a plain+ascii file containing `gitdir: <path>\n`, i.e. the path to the+real git repository). objects:: Object store associated with this repository. Usually
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:14
Hi,
On Sun, 17 Feb 2008, Lars Hjemli wrote:
On Feb 17, 2008 11:20 PM, Johannes Schindelin
[off-list ref] wrote:
quoted
On Sun, 17 Feb 2008, Lars Hjemli wrote:
quoted
PPS: If included, the .git file should probably be used by
git-submodule to clone submodule repositories into something like
$GIT_DIR/submodules/<name>, as that would make local submodule
changes more resistant to dataloss due to checkout/reset in the
containing repository.
I don't buy that argument. For the moment, the submodules are
self-contained repositories. The superproject does not even have to
have a single object contained in a submodule. I'd try to keep that
separation.
They would still be separated and self-contained repositories, but with
my suggestion the submodule repository would be moved out of the working
tree of the containing repository. Which I believe is a good thing,
especially when you switch from one branch in the containing repository
which had the submodule in './foo' to another branch where the submodule
is located in './lib/foo'.
That is a good argument.
But what about the argument when you stop being interested in the
superproject, and move the submodule out of it (then deleting the
superproject)?
However, when a submodule is deleted, wasn't the plan all along to put the
submodule's .git/ into the superproject's .git/submodules-deleted/ or some
such?
Ciao,
Dscho
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:14
Lars Hjemli [off-list ref] writes:
This patch allows .git to be a regular textfile containing the path of
the real git directory (formatted like "gitdir: <path>\n"), which is
useful on platforms lacking support for real symlinks.
Hmmmm. I have suspected all along that these "platforms lacking
support for real symlinks" are the ones whose native line
termination convention is CRLF. How do you envision this file
is initialized? By users editing the file by hand? Or some git
specific tool? If the former, it might make sense to define the
format as "a single line, terminated with platform line
terminator" and open and read it in text mode. If the latter,
we do not have to care, and "terminated with LF" is good enough.
I think a sane simplification is to allow the file to have
any number of optional \r or \n at the end. We may care about
allowing arbitrary and possibly crazy filenames in the tracked
contents, but we can say "Sorry, you cannot create a directory
'ab\nc\r' and use it as the .git directory substitute."
But I am not sure about this part. We found what claims to be
the ".git" fake symlink but it is ill-formed. Don't we want to
diagnose the possible breakage for the user?
+/*
+ if (!is_git_directory(buf + 8))
+ return NULL;
+*/
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:14
Lars Hjemli [off-list ref] writes:
Since .git can be a file refering to the real GIT_DIR, git-sh-setup needs
to use 'git rev-parse --git-dir' to obtain the location of the git
repository.
I wonder if this depend on your [1/5]. Isn't this actually a
simplification (removing 7 adding 5 lines) that applies to the
mainline already? IOW, is there a downside of doing this
without any of the rest of the series?
quoted hunk
@@ -127,20 +127,18 @@ get_author_ident_from_commit () { # if we require to be in a git repository. if test -z "$NONGIT_OK" then+ GIT_DIR=$(git rev-parse --git-dir) || {+ exit=$?+ echo >&2 "Failed to find a valid git directory."+ exit $exit
rev-parse --git-dir would have said "fatal: Not a git
repository" already. Do we still need to say "Failed to
find..."?
From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
On Feb 18, 2008 6:43 AM, Junio C Hamano [off-list ref] wrote:
Lars Hjemli [off-list ref] writes:
quoted
This patch allows .git to be a regular textfile containing the path of
the real git directory (formatted like "gitdir: <path>\n"), which is
useful on platforms lacking support for real symlinks.
I think a sane simplification is to allow the file to have
any number of optional \r or \n at the end.
But I am not sure about this part. We found what claims to be
the ".git" fake symlink but it is ill-formed. Don't we want to
diagnose the possible breakage for the user?
Yes, I think I got to eager in my 'gentleness'. It's probably better
to die() with an appropriate errormessage.
quoted
+/*
+ if (!is_git_directory(buf + 8))
+ return NULL;
+*/
Likewise.
True, I'll uncomment and die().
Thanks for the review.
--
larsh
From: Lars Hjemli <hidden> Date: 2016-06-15 22:44:14
On Feb 18, 2008 6:44 AM, Junio C Hamano [off-list ref] wrote:
Lars Hjemli [off-list ref] writes:
quoted
Since .git can be a file refering to the real GIT_DIR, git-sh-setup needs
to use 'git rev-parse --git-dir' to obtain the location of the git
repository.
I wonder if this depend on your [1/5]. Isn't this actually a
simplification (removing 7 adding 5 lines) that applies to the
mainline already?
True. I'll resend as [1/5] with a fixed up commit message.
quoted
@@ -127,20 +127,18 @@ get_author_ident_from_commit () { # if we require to be in a git repository. if test -z "$NONGIT_OK" then+ GIT_DIR=$(git rev-parse --git-dir) || {+ exit=$?+ echo >&2 "Failed to find a valid git directory."+ exit $exit
rev-parse --git-dir would have said "fatal: Not a git
repository" already. Do we still need to say "Failed to
find..."?
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:14
Hi,
On Mon, 18 Feb 2008, Lars Hjemli wrote:
On Feb 18, 2008 6:43 AM, Junio C Hamano [off-list ref] wrote:
quoted
Lars Hjemli [off-list ref] writes:
quoted
+/*
+ if (!is_git_directory(buf + 8))
+ return NULL;
+*/
Likewise.
True, I'll uncomment and die().
Hmm. From check_repository_format_gently():
if (!nongit_ok)
die ("...")
warning("Expected git repo version <= %d...");
I think we want that, too. (die() when !nongit_ok, but warn otherwise)
Ciao,
Dscho