Debian Bug report logs - #575917
git-core: --work-tree behaves strangely when called under .git

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Frédéric Brière <fbriere@fbriere.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: git-core: --work-tree behaves strangely when called under .git

Date: Tue, 30 Mar 2010 09:02:18 -0400

Package: git-core
Version: 1:1.7.0.3-1
Severity: normal

Explicitly setting --work-tree without --git-dir does strange things
when one is directly in (or under) the .git directory:

  $ pwd
  /tmp/git

  $ git init
  Initialized empty Git repository in /tmp/git/.git/
  
  $ git --work-tree /tmp/git symbolic-ref HEAD
  refs/heads/master

  $ cd .git
  $ git --work-tree /tmp/git symbolic-ref HEAD
  fatal: ref HEAD is not a symbolic ref

  $ cp HEAD ..
  $ git --work-tree /tmp/git symbolic-ref HEAD
  refs/heads/master


This may sound far-fetched, but I was actually bitten by this when
working on a git-dir located on a different partition, and whose
core.worktree was explicitly set "just in case, 'cause it can't hurt".


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.29.6 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages git-core depends on:
ii  libc6                   2.10.2-6         Embedded GNU C Library: Shared lib
ii  libcurl3-gnutls         7.20.0-2         Multi-protocol file transfer libra
ii  libdigest-sha1-perl     2.12-1           NIST SHA-1 message digest algorith
ii  liberror-perl           0.17-1           Perl module for error/exception ha
ii  libexpat1               2.0.1-7          XML parsing C library - runtime li
ii  perl-modules            5.10.1-11        Core Perl modules
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages git-core recommends:
ii  less                          436-1      pager program similar to more
ii  openssh-client [ssh-client]   1:5.3p1-3  secure shell (SSH) client, for sec
ii  patch                         2.6-2      Apply a diff file to an original
ii  rsync                         3.0.7-2    fast remote file copy program (lik

Versions of packages git-core suggests:
pn  git-arch                     <none>      (no description available)
ii  git-cvs                      1:1.7.0.3-1 fast, scalable, distributed revisi
pn  git-daemon-run               <none>      (no description available)
pn  git-doc                      <none>      (no description available)
ii  git-email                    1:1.7.0.3-1 fast, scalable, distributed revisi
pn  git-gui                      <none>      (no description available)
ii  git-svn                      1:1.7.0.3-1 fast, scalable, distributed revisi
ii  gitk                         1:1.7.0.3-1 fast, scalable, distributed revisi
pn  gitweb                       <none>      (no description available)

-- no debconf information

Message #10 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Frédéric Brière <fbriere@fbriere.net>, control@bugs.debian.org

Cc: 575917@bugs.debian.org

Subject: Re: git-core: --work-tree behaves strangely when called under .git

Date: Mon, 5 Apr 2010 12:13:58 -0500

found 575917 git-core/1:1.7.0.4-1
tags 575917 + upstream
thanks

Frédéric Brière wrote:

> Explicitly setting --work-tree without --git-dir does strange things
> when one is directly in (or under) the .git directory:

Noted.  I will add a test for this to Nguyễn Duy’s making-setup-sane
series.

You might be interested to learn that git’s repository setup code is
insane in several other ways, too.  I can cc you the rebased series
later today if you’d like.

Cheers,
Jonathan

Message #29 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 575917@bugs.debian.org

Cc: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>, Frédéric Brière <fbriere@fbriere.net>, Clemens Buchacher <drizzd@aon.at>

Subject: Re: git-core: --work-tree behaves strangely when called under .git

Date: Tue, 19 Oct 2010 01:41:24 -0500

Hi Duy and Clemens,

I keep forgetting the semantics of the setup vars.  Do you remember?
The result can go in Documentation/technical/api-setup.txt.

Frédéric Brière wrote:

>   $ pwd
>   /tmp/git
> 
>   $ git init
>   Initialized empty Git repository in /tmp/git/.git/
>   
>   $ git --work-tree /tmp/git symbolic-ref HEAD
>   refs/heads/master
> 
>   $ cd .git
>   $ git --work-tree /tmp/git symbolic-ref HEAD
>   fatal: ref HEAD is not a symbolic ref
> 
>   $ cp HEAD ..
>   $ git --work-tree /tmp/git symbolic-ref HEAD
>   refs/heads/master

Yagh.  Given: cwd is .git dir, GIT_DIR unset, GIT_WORK_TREE=/tmp/git

run_builtin() runs the repository setup:

 setup_git_directory() ->
  setup_git_directory_gently(NULL) ->
   setup_git_directory_gently_1(NULL) ->
    setup_bare_git_dir($GIT_WORK_TREE, strlen(cwd), strlen(cwd), cwd, NULL) ->
     set_git_dir(".")

Result:

 GIT_DIR=.
 GIT_WORK_TREE=/tmp/git
 inside_work_tree = -1
 prefix = NULL
 cwd = /tmp/git

Should the result be rather

 GIT_DIR=/tmp/git/.git
 prefix=.git
 inside_work_tree = 1

?  [The following patch is probably broken.  It's more of a "this is
the code path I am talking about" kind of thing than an actual fix.]

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Following up on [1].  Sorry to leave it hanging for so long.
[1] http://thread.gmane.org/gmane.comp.version-control.git/147552/focus=147559

diff --git a/setup.c b/setup.c
index a3b76de..c073e0a 100644
--- a/setup.c
+++ b/setup.c
@@ -313,12 +313,30 @@ const char *read_gitfile_gently(const char *path)
 	return path;
 }
 
-static const char *setup_explicit_git_dir(const char *gitdirenv,
+static const char *setup_git_dir_with_work_tree(const char *gitdirenv,
 				const char *work_tree_env, int *nongit_ok)
 {
 	static char buffer[1024 + 1];
 	const char *retval;
 
+	if (check_repository_format_gently(nongit_ok))
+		return NULL;
+	retval = get_relative_cwd(buffer, sizeof(buffer) - 1,
+			get_git_work_tree());
+	if (!retval || !*retval)
+		return NULL;
+	set_git_dir(make_absolute_path(gitdirenv));
+	if (chdir(work_tree_env) < 0)
+		die_errno ("Could not chdir to '%s'", work_tree_env);
+	strcat(buffer, "/");
+	return retval;
+}
+
+static const char *setup_explicit_git_dir(const char *gitdirenv,
+				const char *work_tree_env, int *nongit_ok)
+{
+	const char *retval;
+
 	if (PATH_MAX - 40 < strlen(gitdirenv))
 		die("'$%s' too big", GIT_DIR_ENVIRONMENT);
 	if (!is_git_directory(gitdirenv)) {
@@ -328,23 +346,13 @@ static const char *setup_explicit_git_dir(const char *gitdirenv,
 		}
 		die("Not a git repository: '%s'", gitdirenv);
 	}
-	if (!work_tree_env) {
-		retval = set_work_tree(gitdirenv);
-		/* config may override worktree */
-		if (check_repository_format_gently(nongit_ok))
-			return NULL;
-		return retval;
-	}
+	if (work_tree_env)
+		return setup_git_dir_with_work_tree(gitdirenv,
+				work_tree_env, nongit_ok);
+	retval = set_work_tree(gitdirenv);
+	/* config may override worktree */
 	if (check_repository_format_gently(nongit_ok))
 		return NULL;
-	retval = get_relative_cwd(buffer, sizeof(buffer) - 1,
-			get_git_work_tree());
-	if (!retval || !*retval)
-		return NULL;
-	set_git_dir(make_absolute_path(gitdirenv));
-	if (chdir(work_tree_env) < 0)
-		die_errno ("Could not chdir to '%s'", work_tree_env);
-	strcat(buffer, "/");
 	return retval;
 }
 
@@ -388,16 +396,19 @@ static const char *setup_bare_git_dir(const char *work_tree_env,
 	int root_len;
 
 	inside_git_dir = 1;
-	if (!work_tree_env)
-		inside_work_tree = 0;
+	inside_work_tree = work_tree_env ? 1 : 0;
 	if (offset != len) {
 		if (chdir(cwd))
 			die_errno("Cannot come back to cwd");
 		root_len = offset_1st_component(cwd);
 		cwd[offset > root_len ? offset : root_len] = '\0';
 		set_git_dir(cwd);
-	} else
+	} else {
+		if (work_tree_env)
+			return setup_git_dir_with_work_tree(".",
+				work_tree_env, nongit_ok);
 		set_git_dir(".");
+	}
 	check_repository_format_gently(nongit_ok);
 	return NULL;
 }

Message #34 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Clemens Buchacher <drizzd@aon.at>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 575917@bugs.debian.org, Nguyễn Thái Ngọc Duy <pclouds@gmail.com>, Frédéric Brière <fbriere@fbriere.net>

Subject: Re: git-core: --work-tree behaves strangely when called under .git

Date: Tue, 19 Oct 2010 10:04:52 +0200

[Message part 1 (text/plain, inline)]

Hi Jonathan,

On Tue, Oct 19, 2010 at 01:41:24AM -0500, Jonathan Nieder wrote:
> 
> I keep forgetting the semantics of the setup vars.  Do you remember?

All I know is that I tried to fix bugs in setup code several times,
and I failed every time.

I remember giving up on this particular problem in the following
thread.  But I'll have to look at it again to find out what exactly
the problem was.

 mid.gname.org/20100523000719.GA32380@localhost

Clemens

[signature.asc (application/pgp-signature, inline)]

Message #39 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 575917@bugs.debian.org, Frédéric Brière <fbriere@fbriere.net>, Clemens Buchacher <drizzd@aon.at>

Subject: Re: git-core: --work-tree behaves strangely when called under .git

Date: Tue, 19 Oct 2010 15:25:12 +0700

2010/10/19 Jonathan Nieder <jrnieder@gmail.com>:
> Yagh.  Given: cwd is .git dir, GIT_DIR unset, GIT_WORK_TREE=/tmp/git

So cwd is /tmp/git/.git, right?

Another the way to "address" this is to ban this case entirely.
GIT_WORK_TREE should only be considered when GIT_DIR is set. I think
there are discussions in the past about this approach.

> run_builtin() runs the repository setup:
>
>  setup_git_directory() ->
>  setup_git_directory_gently(NULL) ->
>   setup_git_directory_gently_1(NULL) ->
>    setup_bare_git_dir($GIT_WORK_TREE, strlen(cwd), strlen(cwd), cwd, NULL) ->
>     set_git_dir(".")
>
> Result:
>
>  GIT_DIR=.
>  GIT_WORK_TREE=/tmp/git
>  inside_work_tree = -1

This is temporary. when is_inside_worktree() is called this variable
should either 0 or 1 (more likely 1)

>  prefix = NULL
>  cwd = /tmp/git

Hmm.. I think cwd is /tmp/git/.git becase cwd has not been changed
yet. (Haven't had time to test it yet)


> Should the result be rather
>
>  GIT_DIR=/tmp/git/.git

Better be relative path here.

>  prefix=.git
>  inside_work_tree = 1
[and cwd = /tmp/git ?]

Why do you think cwd should be moved to /tmp/git? If it follows the
current order of gitdir detection, .git (as cwd) will be recognized as
gitdir and the detection process stops. prefix calculation is not
correct. I should fix that with my long forgotten tp/setup series. But
cwd should stay in /tmp/git/.git and GIT_DIR should be ".".
-- 
Duy

Message #44 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 575917@bugs.debian.org, Frédéric Brière <fbriere@fbriere.net>, Clemens Buchacher <drizzd@aon.at>

Subject: Re: git-core: --work-tree behaves strangely when called under .git

Date: Tue, 19 Oct 2010 15:42:25 +0700

2010/10/19 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
> 2010/10/19 Jonathan Nieder <jrnieder@gmail.com>:
>> Yagh.  Given: cwd is .git dir, GIT_DIR unset, GIT_WORK_TREE=/tmp/git
>
> So cwd is /tmp/git/.git, right?
>
> Another the way to "address" this is to ban this case entirely.
> GIT_WORK_TREE should only be considered when GIT_DIR is set. I think
> there are discussions in the past about this approach.
>
>> run_builtin() runs the repository setup:
>>
>>  setup_git_directory() ->
>>  setup_git_directory_gently(NULL) ->
>>   setup_git_directory_gently_1(NULL) ->
>>    setup_bare_git_dir($GIT_WORK_TREE, strlen(cwd), strlen(cwd), cwd, NULL) ->
>>     set_git_dir(".")
>>
>> Result:
>>
>>  GIT_DIR=.
>>  GIT_WORK_TREE=/tmp/git
>>  inside_work_tree = -1
>
> This is temporary. when is_inside_worktree() is called this variable
> should either 0 or 1 (more likely 1)
>
>>  prefix = NULL
>>  cwd = /tmp/git
>
> Hmm.. I think cwd is /tmp/git/.git becase cwd has not been changed
> yet. (Haven't had time to test it yet)

Replying to myself. setup_git_directory() moves cwd to /tmp/git
because it finds out cwd is inside worktree. Gaah.. all chdir() should
better be handled inside gently_1() to avoid this mess.

I once made setup_git_directory() a thin wrapper of _gently() (i.e no
logic at all). What happened to that patch, hm...
-- 
Duy

Message #49 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 575917@bugs.debian.org, Frédéric Brière <fbriere@fbriere.net>, Clemens Buchacher <drizzd@aon.at>

Subject: Re: git-core: --work-tree behaves strangely when called under .git

Date: Tue, 19 Oct 2010 15:57:03 +0700

2010/10/19 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
> I once made setup_git_directory() a thin wrapper of _gently() (i.e no
> logic at all). What happened to that patch, hm...

For archival purpose:

http://thread.gmane.org/gmane.comp.version-control.git/74901

I'll make another attempt when my nd/setup series is in OK state
again. It's quite a mess after rebase.
-- 
Duy

Message #54 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>

To: Jonathan Niedier <jrnieder@gmail.com>, git@vger.kernel.org

Cc: fbriere@fbriere.net, drizzd@aon.at, 575917@bugs.debian.org

Subject: [long] worktree setup cases

Date: Wed, 20 Oct 2010 15:59:00 +0700

Hi,

I want to know how I expect setup code to work and whether it matches
my expectation. So I list every possible cases and try to sum up what
git does and what I expect. Hopefully all corner cases are covered
(and fixed later). It's not an easy read, but any comments are
appreciated. If all go well, this document should be turned into test
cases.

As a side note, Debian bug #575917 is case #17. I did not take into
account what setup_git_directory() does (which causes #575917)
though. Once the cleanup is done, setup_git_directory() should become
a one-liner around setup_git_directory_gently().

Assumptions:

1. When .git is a file and contains a relative path, I assume it is
   relative to .git file's parent directory.  read_gitfile_gently()
   function will make the path absolute, but it depends on (maybe
   wrong) cwd.

2. Relative path is preferred over absolute path.

3. core.worktree is overidden by GIT_WORK_TREE

There are a few factors that affect gitdir/worktree/cwd/prefix setup.
Those are:

 - GIT_DIR (or --git-dir)
 - GIT_WORK_TREE (or --work-tree)
 - core.worktree
 - .git is a file pointing to real .git directory
 - Bare repo

So there are 2^5 = 32 cases in total. Let's look at them one by
one. What describes here usually matches current code, except for
"should" phrases/sentences. Note that I did not look at the code
carefully so I might misunderstand things.

The following questions must be answered for each case:

0. What setup function handles that case?
1. Is worktree available?
2. Where is new cwd? Is it at worktree root?
3. Prefix?
4. Is (relative) $GIT_DIR accessible from current cwd?
5. What if original cwd is outside worktree, or new cwd if it's not at
   worktree root?

Table of Contents
=================
1 Cases
    1.1 Case 0, 8
    1.2 Case 1, 4, 5, 9, 12, 13
        1.2.1 cwd outside worktree
    1.3 Case 2, 10
    1.4 Case 3, 6, 7, 11, 14, 15
        1.4.1 cwd outside worktree
    1.5 Case 16, 24
    1.6 Case 17, 20, 21, 25, 28, 29
        1.6.1 cwd outside worktree
    1.7 Case 18, 26
    1.8 Case 19, 22, 23, 27, 30, 31


1 Cases
~~~~~~~~

Case#  Bare  .git-file  core.worktree  GIT_DIR  GIT_WORK_TREE
0      0     0          0              0        0
1      0     0          0              0        1
2      0     0          0              1        0
3      0     0          0              1        1
4      0     0          1              0        0
5      0     0          1              0        1
6      0     0          1              1        0
7      0     0          1              1        1
8      0     1          0              0        0
9      0     1          0              0        1
10     0     1          0              1        0
11     0     1          0              1        1
12     0     1          1              0        0
13     0     1          1              0        1
14     0     1          1              1        0
15     0     1          1              1        1
16     1     0          0              0        0
17     1     0          0              0        1
18     1     0          0              1        0
19     1     0          0              1        1
20     1     0          1              0        0
21     1     0          1              0        1
22     1     0          1              1        0
23     1     0          1              1        1
24     1     1          0              0        0
25     1     1          0              0        1
26     1     1          0              1        0
27     1     1          0              1        1
28     1     1          1              0        0
29     1     1          1              0        1
30     1     1          1              1        0
31     1     1          1              1        1

1.1 Case 0, 8
==============

The most used case, nothing special is set.

0. setup_discovered_git_dir()
1. work tree is .git dir's parent directory
2. cwd is at worktree root, i.e. .git dir's parent dir
3. prefix is calculated from original cwd
4. git_dir is set to ".git" (#0) or according to .git file, made
   absolute (#8)
5. N/A

TODO: turn git_dir to relative in #8

1.2 Case 1, 4, 5, 9, 12, 13
============================

0. setup_discovered_git_dir()
1. work tree is set according to GIT_WORK_TREE (#1, #5, #9, #13) or
   core.worktree (#4, #12)
2. cwd is at worktree root, i.e. .git dir's parent dir
3. prefix is calculated from original cwd
4. git_dir is set to ".git" (#1, #4, #5) or according to .git file,
   made absolute (#9, #12, #13)

TODO: turn git_dir to relative in #9, #12, #13

1.2.1 cwd outside worktree
---------------------------

FIXME

1.3 Case 2, 10
===============

0. setup_explicit_git_dir()
1. worktree is set at cwd for legacy reason
2. cwd is unchanged
3. prefix is NULL
4. git_dir is set according to GIT_DIR (#2) or according to .git file,
   made absolute (#10)

TODO: turn git_dir to relative path

Note on #10: setup_git_env() is used to read .git file

1.4 Case 3, 6, 7, 11, 14, 15
=============================

Another normal case where worktree is at an unsual case.

0. setup_explicit_git_dir()
1. worktree is set according to GIT_WORK_TREE (#3, #7, #11, #15) or
   core.worktree (#6, #14)
2. cwd is moved to worktree root dir if original cwd is inside
   worktree
3. prefix is calculated if original cwd is inside worktree
4. git_dir is set to GIT_DIR (#3, #6, #7) or according to .git file,
   made absolute (#11, #14, #15)

TODO: if GIT_DIR is relative, it is assumed relative to original cwd,
so it breaks because cwd now is changed. Right now this does not
happen because git_dir is turned absolute. Although it's better to be
relative.

TODO: turn git_dir to relative in #11, #14, #15

FIXME on #11, #14, #15: setup_git_env() is used to read .git file. cwd
by that time is worktree root, not .git's parent dir anymore.

1.4.1 cwd outside worktree
---------------------------

cwd is left unchanged, prefix is NULL, which is sensible for full tree
operations. is_inside_work_tree() returns 0, operations that require
worktree should check and error out.

TODO: File path output however may not be what user expected because
it will be relative to worktree root, not original cwd.

1.5 Case 16, 24
================

The most used case, nothing special is set.

0. setup_bare_git_dir()
1. no worktree
2. cwd is unchanged (actually it is moved back to original cwd)
3. prefix is NULL
4. git_dir is set in form "../../../" (or ".") (#16) or according to
   .git file, made absolute (#24)
5. N/A

TODO on #24: turn git_dir to relative

FIXME on #24: cwd is not at .git's parent dir, so relative git_dir
fails assumption #1.

1.6 Case 17, 20, 21, 25, 28, 29
================================

0. setup_bare_git_dir()
1. work tree is set according to GIT_WORK_TREE (#17, #21, #25, #29) or
   core.worktree (#20, #28)
2. cwd is unchanged (actually it is moved back to original
   cwd).
3. prefix is calculated from original cwd
4. git_dir is set in form "../../../" (or ".") (#17, #20, #21) or according to
   .git file, made absolute (#25 , #28, #29).

TODO: if core.bare = true, die()

FIXME: cwd should be moved to worktree's root instead. Similarly,
git_dir should be recalculated relative to worktree's root

TODO: turn git_dir to relative in #25, #28, #29 (or all if the above
FIXME turns everything to absolute)

Note on #25, #28, #9: pay attention to assumption #1 when the above
FIXME is done.

1.6.1 cwd outside worktree
---------------------------

FIXME

1.7 Case 18, 26
================

This is bare repo because of core.bare = true.

0. setup_explicit_git_dir()
1. no worktree
2. cwd is unchanged
3. prefix is NULL
4. git_dir is set according to GIT_DIR (#18) or according to .git file,
   made absolute (#126)

FIXME: in current code, I believe this is actually #2/#10 (worktree is
set). Should that be fixed??? "Legacy reason" hanging around so I'm
not sure.

TODO: turn git_dir to relative path

Note on #26: setup_git_env() is used to read .git file

1.8 Case 19, 22, 23, 27, 30, 31
================================

This is bare repo because of core.bare = true.

0. setup_explicit_git_dir()
1. worktree is set according to GIT_WORK_TREE (#19, #23, #27, #31) or
   core.worktree (#22, #30)
2. cwd is moved to worktree root dir if original cwd is inside
   worktree
3. prefix is calculated if original cwd is inside worktree
4. git_dir is set to GIT_DIR (#19, #22, #23) or according to .git file,
   made absolute (#27, #30, #31)
5. N/A

FIXME: just die() in check_repository_format_gently().
-- 
Duy

Message #59 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>

Cc: git@vger.kernel.org, fbriere@fbriere.net, drizzd@aon.at, 575917@bugs.debian.org

Subject: Re: [long] worktree setup cases

Date: Wed, 20 Oct 2010 14:07:09 -0500

Nguyen Thai Ngoc Duy wrote:

> 1. When .git is a file and contains a relative path, I assume it is
>    relative to .git file's parent directory.  read_gitfile_gently()
>    function will make the path absolute, but it depends on (maybe
>    wrong) cwd.

Yep.

> 2. Relative path is preferred over absolute path.

I'm tempted to say: let's use absolute paths where it's more
convenient.  They can be changed to relative paths as an afterthought
after the bugs are gone.

Relative paths have two big advantages over absolute paths,
which are avoiding path traversal overhead and allowing paths
longer than PATH_MAX.  Supporting the latter consistently
would presumably require using openat() and co, though.

> 3. core.worktree is overidden by GIT_WORK_TREE

Yeah.

> So there are 2^5 = 32 cases in total. Let's look at them one by
> one.

Thanks!  To summarize (and make sure I understand correctly):
anything not following the below rules is a bug, yes?

A. Weird cases.

 - using a .git file is just like setting GIT_DIR;
 - setting core.worktree is just like setting GIT_WORK_TREE.

B. Repository search.

 - if GIT_DIR was set explicitly, GIT_WORK_TREE defaults to
   "." (for legacy reasons).

 - otherwise, if original cwd was under repository, it will not
   prompt a search for work tree, even if the repo happens
   to be named ".git" or core.bare is false.  That is, in
   this case, GIT_WORK_TREE defaults to unset.

 - otherwise, if original cwd was under a directory containing
   repository as ".git", GIT_WORK_TREE defaults to that
   directory (i.e., parent to .git dir).

 - otherwise, there is no repository.  GIT_DIR is unset,
   GIT_WORK_TREE defaults to unset.

C. Working directory and prefix

 - if GIT_WORK_TREE is still unset after repository search,
   stay in the original cwd, prefix = NULL.

 - if original cwd is inside worktree, chdir to toplevel,
   prefix = path to original cwd.

 - otherwise, stay in the original cwd, prefix = NULL.

D. User-supplied relative paths.

 - path in .git file is relative to containing directory
 - path in GIT_DIR is relative to original cwd
 - paths in GIT_WORK_TREE and core.worktree are relative to
   $GIT_DIR
 - paths passed to git commands are generally relative to
   original cwd

E. Internally used relative paths.

 - all paths are relative to current cwd.

Message #64 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Junio C Hamano <gitster@pobox.com>

To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>

Cc: Jonathan Niedier <jrnieder@gmail.com>, git@vger.kernel.org, fbriere@fbriere.net, drizzd@aon.at, 575917@bugs.debian.org

Subject: Re: [long] worktree setup cases

Date: Wed, 20 Oct 2010 14:00:45 -0700

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> Assumptions:
>
> 1. When .git is a file and contains a relative path, I assume it is
>    relative to .git file's parent directory.  read_gitfile_gently()
>    function will make the path absolute, but it depends on (maybe
>    wrong) cwd.

Ok.  I agree that a regular file .git that has "gitdir: ../there" in it
should be naming "there" directory next to the directory .git lives in.
It is insane for it to take $(cwd) into account.

> There are a few factors that affect gitdir/worktree/cwd/prefix setup.
> Those are:
>
>  - GIT_DIR (or --git-dir)
>  - GIT_WORK_TREE (or --work-tree)
>  - core.worktree
>  - .git is a file pointing to real .git directory
>  - Bare repo
>
> So there are 2^5 = 32 cases in total.

Hmm, why is core.worktree separate from the second item?  In any case, the
three mechanisms to specify the working tree should only be in effect when
GIT_DIR/--git-dir is used, so the above are not orthogonal, and the total
count should be smaller than 32 cases.

> The following questions must be answered for each case:
>
> 0. What setup function handles that case?
> 1. Is worktree available?
> 2. Where is new cwd? Is it at worktree root?
> 3. Prefix?
> 4. Is (relative) $GIT_DIR accessible from current cwd?
> 5. What if original cwd is outside worktree, or new cwd if it's not at
>    worktree root?

All good questions to ask, except for the last one which I cannot quite
parse.

> Table of Contents
> =================
> 1 Cases
>     1.1 Case 0, 8
>     1.2 Case 1, 4, 5, 9, 12, 13
>         1.2.1 cwd outside worktree
>     1.3 Case 2, 10
>     1.4 Case 3, 6, 7, 11, 14, 15
>         1.4.1 cwd outside worktree
>     1.5 Case 16, 24
>     1.6 Case 17, 20, 21, 25, 28, 29
>         1.6.1 cwd outside worktree
>     1.7 Case 18, 26
>     1.8 Case 19, 22, 23, 27, 30, 31
>
>
> 1 Cases
> ~~~~~~~~
>
> Case#  Bare  .git-file  core.worktree  GIT_DIR  GIT_WORK_TREE
> 0      0     0          0              0        0
> 8      0     1          0              0        0

Ok.

> 1      0     0          0              0        1
> 4      0     0          1              0        0
> 5      0     0          1              0        1
> 9      0     1          0              0        1
> 12     0     1          1              0        0
> 13     0     1          1              0        1

How does it make sense to have GIT_WORK_TREE without GIT_DIR?  Without
GIT_DIR, we will run repository discovery, which means we will always go
up to find a .git dir, and the reason for doing that is because we want to
also work in a subdirectory of a working tree (the very original git never
worked from anywhere other than the root level of the working tree).  By
definition, the root of the working tree is the same as in cases 0/8.

> 2      0     0          0              1        0
> 10     0     1          0              1        0

If you set GIT_DIR, we do no discovery, so git will work only from the
root level of the working tree (or bare repository operation) if you do
not tell us where the working tree is.

> 3      0     0          0              1        1
> 6      0     0          1              1        0
> 7      0     0          1              1        1
> 11     0     1          0              1        1
> 14     0     1          1              1        0
> 15     0     1          1              1        1

Without discovery, we know where the root level of the working tree is,
and we know where the repository is, because you told us.  The answers to
questions 1-5, i.e. semantics observable by the end user, should be the
same as case 0/8 even though the internal codepath to achieve that,
i.e. question 0, may be different.

> 16     1     0          0              0        0
> ...
> 31     1     1          1              1        1

Shouldn't all of these 16 be the same, if the repository is bare?  What is
your definition of bareness?  core.bare?  In any case we should say "you
are using a bare repository, there is no working tree" and cwd shouldn't
change in these cases.  They are all bare and there is no working tree.

Alternatively, you could give precedence to core.worktree and friends, in
which case these can go to the other categories in your description,
ignoring core.bare settings.  For example, 31 explicitly specifies where
the .git directory and the working tree are, which would fall into the
same category as 3,6,7,11,14,15.

Either way is fine.

> 1.1 Case 0, 8
> ==============
>
> The most used case, nothing special is set.
>
> 0. setup_discovered_git_dir()
> 1. work tree is .git dir's parent directory
> 2. cwd is at worktree root, i.e. .git dir's parent dir
> 3. prefix is calculated from original cwd
> 4. git_dir is set to ".git" (#0) or according to .git file, made
>    absolute (#8)
> 5. N/A
>
> TODO: turn git_dir to relative in #8

Ok.

> 1.2 Case 1, 4, 5, 9, 12, 13

As I said already, isn't this a nonsense combination you should error out?

> 1.3 Case 2, 10
> ===============
>
> 0. setup_explicit_git_dir()
> 1. worktree is set at cwd for legacy reason
> 2. cwd is unchanged
> 3. prefix is NULL
> 4. git_dir is set according to GIT_DIR (#2) or according to .git file,
>    made absolute (#10)
>
> TODO: turn git_dir to relative path
>
> Note on #10: setup_git_env() is used to read .git file

Ok.

> 1.4 Case 3, 6, 7, 11, 14, 15
> =============================
>
> Another normal case where worktree is at an unsual case.
>
> 0. setup_explicit_git_dir()
> 1. worktree is set according to GIT_WORK_TREE (#3, #7, #11, #15) or
>    core.worktree (#6, #14)
> 2. cwd is moved to worktree root dir if original cwd is inside
>    worktree
> 3. prefix is calculated if original cwd is inside worktree
> 4. git_dir is set to GIT_DIR (#3, #6, #7) or according to .git file,
>    made absolute (#11, #14, #15)
>
> TODO: if GIT_DIR is relative, it is assumed relative to original cwd,
> so it breaks because cwd now is changed. Right now this does not
> happen because git_dir is turned absolute. Although it's better to be
> relative.
>
> TODO: turn git_dir to relative in #11, #14, #15
>
> FIXME on #11, #14, #15: setup_git_env() is used to read .git file. cwd
> by that time is worktree root, not .git's parent dir anymore.

Ok.

> 1.4.1 cwd outside worktree
> ---------------------------
>
> cwd is left unchanged, prefix is NULL, which is sensible for full tree
> operations. is_inside_work_tree() returns 0, operations that require
> worktree should check and error out.
>
> TODO: File path output however may not be what user expected because
> it will be relative to worktree root, not original cwd.

This is operating out of bounds of the original design criteria; we
probably do not error out now, which is an original bug, but I understand
that you are trying to enhance this to reach into a submodule repository
and its working tree from its superproject.  As long as we can make such
an enhancement in a way that produces sensible and consistent output, that
kind of change would be fine.

I suspect that you would need to pass in "make the path relative to this"
using some means that do not exist in the current structure of the code.

Also I suspect that for the purpose of your enhancement, the first three
lines of this paragraph would not be true.  Think of a case where you are
at the superproject level and running a recursive grep into its submodule
at "nitfol", that has contents recorded at the path "xyzzy/frotz.txt".

If you keep cwd unchanged, the path appears at nitfol/xyzzy/frotz.txt in
the working tree from the end user's point of view, so you need to pass
"nitfol/" as a different kind of "prefix" that needs to be used to modify
the path recorded in the contents tracked by the submodule.  The grep
running in the submodule will read xyzzy/frotz.txt from the index (which
is how it notices which paths are of interest), use the "nitfol/" prefix
to turn it into a path in the working tree, read from that file and report
hits.  This is an example of an operation that clearly require a working
tree, and does not have to error out.

Alternatively, if you move cwd to the top of the working tree of the
submodule, you would still need to pass "nitfol/" prefix, but it needs to
be used only in the output phase.  The grep running in the submodule will
read xyzzy/frotz.txt from the index (which is how it notices which paths
are of interest), read from the file in the working tree (relative to cwd
which now is at the root level of the submodule), and use "nitfol/" as
output prefix when reporting.

Message #69 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: git@vger.kernel.org, fbriere@fbriere.net, drizzd@aon.at, 575917@bugs.debian.org

Subject: Re: [long] worktree setup cases

Date: Thu, 21 Oct 2010 08:46:44 +0700

On Thu, Oct 21, 2010 at 2:07 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> So there are 2^5 = 32 cases in total. Let's look at them one by
>> one.
>
> Thanks!  To summarize (and make sure I understand correctly):
> anything not following the below rules is a bug, yes?

Let's see.

> A. Weird cases.
>
>  - using a .git file is just like setting GIT_DIR;

Yes, except that GIT_DIR can be detected early when cwd has not been
moved. When .git is found a file, cwd could have been changed.

> B. Repository search.
>
>  - if GIT_DIR was set explicitly, GIT_WORK_TREE defaults to
>   "." (for legacy reasons).

Correct.

>  - otherwise, if original cwd was under repository, it will not
>   prompt a search for work tree, even if the repo happens
>   to be named ".git" or core.bare is false.  That is, in
>   this case, GIT_WORK_TREE defaults to unset.

What do you mean by "under repository"? If the repo is /tmp/git/.git,
then cwd is at /tmp/git/.git?

>  - otherwise, if original cwd was under a directory containing
>   repository as ".git", GIT_WORK_TREE defaults to that
>   directory (i.e., parent to .git dir).

Yes.

>  - otherwise, there is no repository.  GIT_DIR is unset,
>   GIT_WORK_TREE defaults to unset.

- Otherwise, move up one dir and repeat?

> C. Working directory and prefix
>
>  - if GIT_WORK_TREE is still unset after repository search,
>   stay in the original cwd, prefix = NULL.

if GIT_WORK_TREE and core.worktree are still unset, we get a bare repo
here (or force it to be a bare repo), so yes, cwd should stay in
original cwd and prefix = NULL.

>  - if original cwd is inside worktree, chdir to toplevel,
>   prefix = path to original cwd.

Yes.

>  - otherwise, stay in the original cwd, prefix = NULL.

I'm not really happy with this, which is why I wrote the
--cwd-to-worktree and --worktree-to-cwd patch. But this should be
enough for full-tree operations to work, so yes.

> D. User-supplied relative paths.
>
>  - path in .git file is relative to containing directory
>  - path in GIT_DIR is relative to original cwd
>  - paths in GIT_WORK_TREE and core.worktree are relative to
>   $GIT_DIR

I think $GIT_WORK_TREE is relative to original cwd. Yes, core.worktree
should be relative to $GIT_DIR.

>  - paths passed to git commands are generally relative to
>   original cwd

And filename output should also be relative to original cwd (except a
few special, like diff output).

> E. Internally used relative paths.
>
>  - all paths are relative to current cwd.

Yes.
-- 
Duy

Message #74 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>

To: Junio C Hamano <gitster@pobox.com>

Cc: Jonathan Niedier <jrnieder@gmail.com>, git@vger.kernel.org, fbriere@fbriere.net, drizzd@aon.at, 575917@bugs.debian.org

Subject: Re: [long] worktree setup cases

Date: Thu, 21 Oct 2010 09:23:28 +0700

On Thu, Oct 21, 2010 at 4:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> There are a few factors that affect gitdir/worktree/cwd/prefix setup.
>> Those are:
>>
>>  - GIT_DIR (or --git-dir)
>>  - GIT_WORK_TREE (or --work-tree)
>>  - core.worktree
>>  - .git is a file pointing to real .git directory
>>  - Bare repo
>>
>> So there are 2^5 = 32 cases in total.
> Hmm, why is core.worktree separate from the second item?

It's how the code does it. GIT_WORK_TREE can be detected early, when
cwd has not been moved. When core.worktree is found, cwd could be
somewhere. I need to separate those cases to make sure cwd is not
misused after it's been moved.

> In any case, the
> three mechanisms to specify the working tree should only be in effect when
> GIT_DIR/--git-dir is used, so the above are not orthogonal, and the total
> count should be smaller than 32 cases.

Good to hear. I forgot that GIT_DIR must be set for the three
mechanisms in effect.

>> The following questions must be answered for each case:
>>
>> 0. What setup function handles that case?
>> 1. Is worktree available?
>> 2. Where is new cwd? Is it at worktree root?
>> 3. Prefix?
>> 4. Is (relative) $GIT_DIR accessible from current cwd?
>> 5. What if original cwd is outside worktree, or new cwd if it's not at
>>    worktree root?
>
> All good questions to ask, except for the last one which I cannot quite
> parse.

Skip "or new cwd... worktree root" part.

>> 1 Cases
>> ~~~~~~~~
>>
>> Case#  Bare  .git-file  core.worktree  GIT_DIR  GIT_WORK_TREE
>> 0      0     0          0              0        0
>> 8      0     1          0              0        0
>
> Ok.
>
>> 1      0     0          0              0        1
>> 4      0     0          1              0        0
>> 5      0     0          1              0        1
>> 9      0     1          0              0        1
>> 12     0     1          1              0        0
>> 13     0     1          1              0        1
>
> How does it make sense to have GIT_WORK_TREE without GIT_DIR?  Without
> GIT_DIR, we will run repository discovery, which means we will always go
> up to find a .git dir, and the reason for doing that is because we want to
> also work in a subdirectory of a working tree (the very original git never
> worked from anywhere other than the root level of the working tree).  By
> definition, the root of the working tree is the same as in cases 0/8.

OK.

>> 2      0     0          0              1        0
>> 10     0     1          0              1        0
>
> If you set GIT_DIR, we do no discovery, so git will work only from the
> root level of the working tree (or bare repository operation) if you do
> not tell us where the working tree is.

OK

>> 3      0     0          0              1        1
>> 6      0     0          1              1        0
>> 7      0     0          1              1        1
>> 11     0     1          0              1        1
>> 14     0     1          1              1        0
>> 15     0     1          1              1        1
>
> Without discovery, we know where the root level of the working tree is,
> and we know where the repository is, because you told us.  The answers to
> questions 1-5, i.e. semantics observable by the end user, should be the
> same as case 0/8 even though the internal codepath to achieve that,
> i.e. question 0, may be different.

OK too.

>> 16     1     0          0              0        0
>> ...
>> 31     1     1          1              1        1
>
> Shouldn't all of these 16 be the same, if the repository is bare?  What is
> your definition of bareness?  core.bare?  In any case we should say "you
> are using a bare repository, there is no working tree" and cwd shouldn't
> change in these cases.  They are all bare and there is no working tree.

Better this way. Although some sanity checks can be used. Like setting
core.bare and explicitly requesting worktree is insane.

> Alternatively, you could give precedence to core.worktree and friends, in
> which case these can go to the other categories in your description,
> ignoring core.bare settings.  For example, 31 explicitly specifies where
> the .git directory and the working tree are, which would fall into the
> same category as 3,6,7,11,14,15.

I don't want to ignore core.bare. If there are bare/worktree
conflicts, notify users. There are cases that a normal repo tends to
become a bare repo for just one operation. It's when "." is found a
repo, handled by setup_bare_git_dir(). In these cases, we might want
to consider core.worktree and friends again.

> Either way is fine.
-- 
Duy

Message #79 received at 575917@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Frédéric Brière <fbriere@fbriere.net>

Cc: 575917@bugs.debian.org

Subject: Re: git-core: --work-tree behaves strangely when called under .git

Date: Fri, 21 Jan 2011 21:17:50 -0600

tags 575917 + fixed-upstream
thanks

Frédéric Brière wrote:

> Explicitly setting --work-tree without --git-dir does strange things
> when one is directly in (or under) the .git directory:
>
>   $ pwd
>   /tmp/git
>
>   $ git init
>   Initialized empty Git repository in /tmp/git/.git/
>
>   $ git --work-tree /tmp/git symbolic-ref HEAD
>   refs/heads/master
>
>   $ cd .git
>   $ git --work-tree /tmp/git symbolic-ref HEAD
>   fatal: ref HEAD is not a symbolic ref
>
>   $ cp HEAD ..
>   $ git --work-tree /tmp/git symbolic-ref HEAD
>   refs/heads/master
>
>
> This may sound far-fetched, but I was actually bitten by this when
> working on a git-dir located on a different partition, and whose
> core.worktree was explicitly set "just in case, 'cause it can't hurt".

Fixed by v1.7.4-rc0~4^2~9 (setup: limit get_git_work_tree()'s to
explicit setup case only, 2010-11-26).  Tweaked by 4868b2ea from the
"next" branch (setup: officially support --work-tree without
--git-dir, 2010-01-19), whose change description is instructive:

	The original intention of --work-tree was to allow people to work in a
	subdirectory of their working tree that does not have an embedded .git
	directory.  Because their working tree, which their $cwd was in, did not
	have an embedded .git, they needed to use $GIT_DIR to specify where it is,
	and because this meant there was no way to discover where the root level
	of the working tree was, so we needed to add $GIT_WORK_TREE to tell git
	where it was.

	However, this facility has long been (mis)used by people's scripts to
	start git from a working tree _with_ an embedded .git directory, let git
	find .git directory, and then pretend as if an unrelated directory were
	the associated working tree of the .git directory found by the discovery
	process.  It happens to work in simple cases, and is not worth causing
	regression to these scripts.

Thanks for a very helpful test case.

Message #88 received at 575917-close@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 575917-close@bugs.debian.org

Subject: Bug#575917: fixed in git 1:1.7.4.1-1

Date: Thu, 17 Feb 2011 12:17:30 +0000

Source: git
Source-Version: 1:1.7.4.1-1

We believe that the bug you reported is fixed in the latest version of
git, which is due to be installed in the Debian FTP archive:

git-all_1.7.4.1-1_all.deb
  to main/g/git/git-all_1.7.4.1-1_all.deb
git-arch_1.7.4.1-1_all.deb
  to main/g/git/git-arch_1.7.4.1-1_all.deb
git-core_1.7.4.1-1_all.deb
  to main/g/git/git-core_1.7.4.1-1_all.deb
git-cvs_1.7.4.1-1_all.deb
  to main/g/git/git-cvs_1.7.4.1-1_all.deb
git-daemon-run_1.7.4.1-1_all.deb
  to main/g/git/git-daemon-run_1.7.4.1-1_all.deb
git-doc_1.7.4.1-1_all.deb
  to main/g/git/git-doc_1.7.4.1-1_all.deb
git-email_1.7.4.1-1_all.deb
  to main/g/git/git-email_1.7.4.1-1_all.deb
git-gui_1.7.4.1-1_all.deb
  to main/g/git/git-gui_1.7.4.1-1_all.deb
git-man_1.7.4.1-1_all.deb
  to main/g/git/git-man_1.7.4.1-1_all.deb
git-svn_1.7.4.1-1_all.deb
  to main/g/git/git-svn_1.7.4.1-1_all.deb
git_1.7.4.1-1.diff.gz
  to main/g/git/git_1.7.4.1-1.diff.gz
git_1.7.4.1-1.dsc
  to main/g/git/git_1.7.4.1-1.dsc
git_1.7.4.1.orig.tar.gz
  to main/g/git/git_1.7.4.1.orig.tar.gz
gitk_1.7.4.1-1_all.deb
  to main/g/git/gitk_1.7.4.1-1_all.deb
gitweb_1.7.4.1-1_all.deb
  to main/g/git/gitweb_1.7.4.1-1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 575917@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonathan Nieder <jrnieder@gmail.com> (supplier of updated git package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 15 Feb 2011 19:27:38 -0600
Source: git
Binary: git git-man git-core git-doc git-arch git-cvs git-svn git-email git-daemon-run git-gui gitk gitweb git-all
Architecture: all source
Version: 1:1.7.4.1-1
Distribution: unstable
Urgency: low
Maintainer: Gerrit Pape <pape@smarden.org>
Changed-By: Jonathan Nieder <jrnieder@gmail.com>
Description: 
 git        - fast, scalable, distributed revision control system
 git-all    - fast, scalable, distributed revision control system (all subpacka
 git-arch   - fast, scalable, distributed revision control system (arch interop
 git-core   - fast, scalable, distributed revision control system (obsolete)
 git-cvs    - fast, scalable, distributed revision control system (cvs interope
 git-daemon-run - fast, scalable, distributed revision control system (git-daemon s
 git-doc    - fast, scalable, distributed revision control system (documentatio
 git-email  - fast, scalable, distributed revision control system (email add-on
 git-gui    - fast, scalable, distributed revision control system (GUI)
 git-man    - fast, scalable, distributed revision control system (manual pages
 git-svn    - fast, scalable, distributed revision control system (svn interope
 gitk       - fast, scalable, distributed revision control system (revision tre
 gitweb     - fast, scalable, distributed revision control system (web interfac
Closes: 465776 466471 499002 507476 524309 540001 575917 576887 577471 578752 581691 583693 583699 585725 588103 598245 600566 600785 606975 607044 610423 610481 611608
Changes: 
 git (1:1.7.4.1-1) unstable; urgency=low
 .
   * new upstream release (closes: #600566, #575917, #578752, #583693,
     #583699, #588103, #507476, #540001, #524309, #581691, #600785,
     #577471, #607044, #606975, #610423, #610481).
 .
   [ Anders Kaseorg ]
   * debian/git.docs, debian/rules: deal with RelNotes subdirectory.
   * debian/diff/0007-gitk-Take-only-numeric-...diff: new; gitk: do
     not error out when git version number contains "-rc".
 .
   [ Jonathan Nieder ]
   * add myself as uploader.
   * debian/diff/0003, 0007, 0010-0034: remove, applied upstream.
   * debian/rules: accept patches with .patch suffix, too (thx Anders
     Kaseorg).
   * debian/rules: use patch -N -r- so patch application is idempotent.
   * update debian/copyright.
   * debian/diff/0001-ident-check-etc-mailname...diff: avoid calls to
     gethostbyname when mailname is not an fqdn (closes: #611608).
   * debian/diff/0005-gitk-use-...diff: new; gitk: use standard desktop
     fonts by default.  The appearance for users that already have a
     generated ~/.gitk file is not affected (closes: #466471).
   * debian/diff/0006-gitk-...diff: new; gitk: avoid spurious matches
     in "All fields" search (thx Frédéric Brière, closes: #465776).
   * debian/control: git-cvs: recommend cvs2git for one-time conversions
     (closes: #585725).
   * debian/control: git-core: explain that it still may be needed (thx
     Denis Laxalde).
   * debian/control: gitweb: allow lynx-cur to satisfy dependency on a
     CGI implementation (thx Ivan Shmakov).
   * debian/control, debian/rules: new architecture-independent package
     git-man: manual pages that were previously in the main git package.
   * debian/rules: do not build documentation on autobuilders (closes:
     #499002).
   * debian/control: Build-Depends-Indep: asciidoc, xmlto, docbook-xsl.
   * debian/rules: git-gui: install git-gui--askpass helper to
     /usr/lib/git-core (closes: #598245).
   * debian/rules: git-doc: install symlink to html documentation in
     /usr/share/doc/git (thx Ian Jackson).
   * debian/watch: new; point to upstream sources.
   * debian/implicit: create DEBIAN/md5sums with correct permissions.
   * debian/diff/0003-remove-shebang...diff: new; do not start shell
     libraries with #!/bin/sh.
   * debian/rules: do not try to strip scripts even if they begin
     with "# " in place of "#!".
   * debian/diff/0004-pre-rebase-hook-capture...diff: new;
     hooks/pre-rebase: use a <<HERE document to prevent syntax checkers
     from treating documentation as code.
   * debian/implicit: check for debian/$pkg.doc-base.$docid.
   * debian/git-doc.doc-base.*: new; catalog provided documentation.
   * debian/implicit: check for debian/$pkg.lintian-overrides.
   * debian/git.lintian-overrides: new; document some deviations from
     lintian guidelines.
   * debian/control: Standards-Version: 3.9.1.0.
 .
   * debian/git.README.Debian: server logs go in /var/log/apache2.
   * debian/diff/0002-Revert-Merge-branch-jn-gitweb...diff: remove.
   * debian/diff/0006, 0008, 0009-instaweb...diff: remove, no longer
     needed.
   * debian/rules, debian/control: move gitweb script to the main git
     package for use by instaweb; make gitweb into a configuration
     package.
   * debian/gitweb.NEWS.Debian, debian/git.README.Debian,
     debian/gitweb.conf: static files moved to /usr/share/gitweb/static.
   * debian/gitweb.conf: disable rename patches (@diff_opts = ()).
   * debian/diff/0001-Revert-gitweb-...diff: remove; no longer needed.
   * debian/rules: gitweb: move gitweb.cgi script to /usr/share;
     add a symlink at /usr/lib/cgi-bin/gitweb.cgi for compatibility.
 .
   * debian/git.emacsen-install, debian/rules, debian/git.postinst,
     debian/git.prerm: put emacs support files in /usr/share/git-core
     instead of /usr/share/doc/git/contrib.
   * debian/implicit: check for arbitrary debian/$pkg.README.*, not just
     README.source and README.Debian.
   * debian/git.README.emacs: new; introduction to the emacs support
     (text taken from contrib/emacs/README).
 .
   [ Kevin Ryde ]
   * debian/rules, debian/git.emacsen-*, debian/git.postinst,
     debian/git.prerm: Make M-x git-status and git-blame modes available
     with emacs23 (closes: #576887).
Checksums-Sha1: 
 454abccda82b0e5ae7d82c60df95f5fe30d51e69 1436 git_1.7.4.1-1.dsc
 2c9c9ac6dd6ae284df2282bb0c4145c0ae0e7e35 3266745 git_1.7.4.1.orig.tar.gz
 a2cdc8ed70b6c7b7c81050db851eed4ae7c46d98 402484 git_1.7.4.1-1.diff.gz
 96abd1b428884ff1658e25460c78990f249dd566 1639718 git-doc_1.7.4.1-1_all.deb
 6c4e9a61f6e7e50e626ad6666863eb14aa3115f3 386026 git-arch_1.7.4.1-1_all.deb
 452028cba6abaa84d5f3cdf94402d5a6b47455d8 457992 git-cvs_1.7.4.1-1_all.deb
 1aa1567131b1f52c30b43b9e9954afb1dd56a9d7 437754 git-svn_1.7.4.1-1_all.deb
 c1810309d276d79e3899ac85c9ff8dc022ee89b0 373080 git-daemon-run_1.7.4.1-1_all.deb
 e0500154020a1339bbab0d7db6af8d356676540b 390972 git-email_1.7.4.1-1_all.deb
 49b76d65cc7c06a16a9c80931b2eccd7d4f7a241 633922 git-gui_1.7.4.1-1_all.deb
 c5da6c0326defee5a2772b32f9c2b529757ea555 498734 gitk_1.7.4.1-1_all.deb
 4aa64839c62ac780e1e0c3720ac678e7733f3286 383134 gitweb_1.7.4.1-1_all.deb
 397d1bb3abf61e4f43951f5b8ad4574e31ddc16e 371460 git-all_1.7.4.1-1_all.deb
 ffd6bd7b39b91dd66c5d2b98239492a826cbee9e 1336 git-core_1.7.4.1-1_all.deb
 5c133d9d1654d094463e0fddba797de60b1d2e0e 938934 git-man_1.7.4.1-1_all.deb
Checksums-Sha256: 
 ac242c36ec673683dc6a165ea15ab4659924c90a97ccaa0d53000966a691a2b0 1436 git_1.7.4.1-1.dsc
 1855df9f23f8296c24482416cf10bbbaef40f837d30ff02ecf31f2694c325277 3266745 git_1.7.4.1.orig.tar.gz
 bfd435ff77f364ac4e6054b8506e2b110703aa53675091b72557dcf943e962b2 402484 git_1.7.4.1-1.diff.gz
 46cd7b1ed2338f34ea44ad0b336941d5713be0277300681f3140fecc853483c6 1639718 git-doc_1.7.4.1-1_all.deb
 65318f6f273c516cbb885dcd8674c66be1487209d283ea73816988acf4ac5c9c 386026 git-arch_1.7.4.1-1_all.deb
 296f41e0b8deeec79f53ce8a11524b6714a6711bcbe08c02c01843e666d5faed 457992 git-cvs_1.7.4.1-1_all.deb
 0633ba3b3a9e390ce0b7f2a443f3f717772ae2e62fe0f9497078f080a8dc02f2 437754 git-svn_1.7.4.1-1_all.deb
 85a7a8a4e9cfe1ec18dfceb5207b39794a62e35fe91af7d7bb4dd848eaa98f52 373080 git-daemon-run_1.7.4.1-1_all.deb
 f470ce38eba3671ba46103289e2a15274610cb8d6698357ee402637f8bde25f8 390972 git-email_1.7.4.1-1_all.deb
 662393f15a90faf0749982afcddd9bc393b38acca1fe8fe1f57b6fab11fa8bd4 633922 git-gui_1.7.4.1-1_all.deb
 9d40ff6646ae2f1898a9bdef0e3fdebecea3ae2ed8925ac9a458f3e5e3649843 498734 gitk_1.7.4.1-1_all.deb
 dec1a6dd4db7e572bb7c54b5774b3d3b67ddbdbc2472dbd609e82e72bbc88013 383134 gitweb_1.7.4.1-1_all.deb
 65609c1132f1a11330c50ecfc4b3ab7dc9a0c87ad96991bdfd9f7c4852f41c98 371460 git-all_1.7.4.1-1_all.deb
 ac6b3f5d86005b49957b6a6f3ffe4c403bdc41f47ccf811f6f9b735bff17bf99 1336 git-core_1.7.4.1-1_all.deb
 2a4ec7d8c40ef8cfc1c107de1df99ababddfa77634e98ca1b2ef8bd54ed961b3 938934 git-man_1.7.4.1-1_all.deb
Files: 
 19aec48a88c642f378a9933a504fcab5 1436 vcs optional git_1.7.4.1-1.dsc
 1276aa1366bd3c670e9c51f1bff12f36 3266745 vcs optional git_1.7.4.1.orig.tar.gz
 36e04488680d57b513ac3b840844b94a 402484 vcs optional git_1.7.4.1-1.diff.gz
 e7f79fd736d1c476383c52d1cd19496d 1639718 doc optional git-doc_1.7.4.1-1_all.deb
 760acf52d5a99ed3fd19178f23372f41 386026 vcs optional git-arch_1.7.4.1-1_all.deb
 0dd4d96de84ab8ee6e7fc275430ab49e 457992 vcs optional git-cvs_1.7.4.1-1_all.deb
 bbe84f5bb1724082834313cdff3a9cff 437754 vcs optional git-svn_1.7.4.1-1_all.deb
 499ea96dbd14deccac0a089c03921779 373080 vcs optional git-daemon-run_1.7.4.1-1_all.deb
 0cfb71b4f253fe88269d76b710ce2462 390972 vcs optional git-email_1.7.4.1-1_all.deb
 04535918668f71bea565ae7496590254 633922 vcs optional git-gui_1.7.4.1-1_all.deb
 a2156ce5c0a15aacdb9df7ae63999703 498734 vcs optional gitk_1.7.4.1-1_all.deb
 d3aaef1ded07729024375a9bf1f8e2a1 383134 vcs optional gitweb_1.7.4.1-1_all.deb
 e84c9ac9452c37e6011ffc48ca053711 371460 vcs optional git-all_1.7.4.1-1_all.deb
 5ccaeef1abbb1debf65c09766c2ff86c 1336 vcs optional git-core_1.7.4.1-1_all.deb
 28d0be6d985e3f9bf8071601a6c1c6bf 938934 vcs optional git-man_1.7.4.1-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1bqScACgkQGJoyQbxwpv/CiACgidlYAgvKP9U626u4US+/jj1p
4qQAni2trKCqN6+c4N2F/gOvbJU5hgIb
=aIcU
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.