[PATCH] Pay attention to GIT_DIR when searching the git directory

Signed-off-by: Jörg Sommer <redacted>
---
 contrib/hooks/setgitperms.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/contrib/hooks/setgitperms.perl b/contrib/hooks/setgitperms.perl
index dab7c8e..0b1bcf2 100644
--- a/contrib/hooks/setgitperms.perl
+++ b/contrib/hooks/setgitperms.perl

@@ -51,7 +51,7 @@ if ((@ARGV < 0) || !GetOptions(
 die $usage unless ($read_mode xor $write_mode);
 
 my $topdir = `git-rev-parse --show-cdup` or die "\n"; chomp $topdir;
-my $gitdir = $topdir . '.git';
+my $gitdir = $ENV{GIT_DIR} || $topdir . '.git';
 my $gitmeta = $topdir . '.gitmeta';
 
 if ($write_mode) {

-- 
1.5.5.1

Hi,

On Mon, 5 May 2008, Jörg Sommer wrote:

Signed-off-by: Jörg Sommer <redacted>

Am I the only one wondering what the subject tries to tell me?

 contrib/hooks/setgitperms.perl |    2 +-

This tells me more...

Please keep in mind that the commit log is meant to demonstrate the 
_intention_ of the patches.  If you do not say _what_ is affected by the 
change, you only confuse the readers.

Ciao,
Dscho

Hi,

Johannes Schindelin schrieb am Mon 05. May, 12:36 (+0100):

On Mon, 5 May 2008, Jörg Sommer wrote:

quoted

 contrib/hooks/setgitperms.perl |    2 +-

This tells me more...

Please keep in mind that the commit log is meant to demonstrate the 
_intention_ of the patches.

The intention is that the variable GIT_DIR is respected when searching
for the git dir.

If you do not say _what_ is affected by the change, you only confuse
the readers.

Do you want something like “initialization: Pay attention to GIT_DIR when
searching the git directory”?

Is there a document with guidelines for commit messages, e.g. write the
first letter upper or lower case?

Bye, Jörg.
-- 
Die Katze steht im Mittelpunkt unserer Arbeit.
Alles was wir tun, ist für sie.

Hi,

On Mon, 5 May 2008, Jörg Sommer wrote:

Johannes Schindelin schrieb am Mon 05. May, 12:36 (+0100):

quoted

Please keep in mind that the commit log is meant to demonstrate the 
_intention_ of the patches.

The intention is that the variable GIT_DIR is respected when searching 
for the git dir.

AFAICT the core of git respects GIT_DIR very much.  Reading your oneline, 
indeed, the whole commit message, scared me a bit, because I thought that 
there was a bug in core git.

Your commit message completely misses out on the fact that it fixes a bug 
in a _hook_, and a _contributed_ at that.

So I would have known _exactly_ what you did if your oneline had read

	contrib/hooks/setgitperms: respect GIT_DIR

Don't you agree?

Ciao,
Dscho

Jörg Sommer [off-list ref] writes:

Johannes Schindelin schrieb am Mon 05. May, 12:36 (+0100):

quoted

If you do not say _what_ is affected by the change, you only confuse
the readers.

Do you want something like “initialization: Pay attention to GIT_DIR when
searching the git directory”?

I think the idea was to use
  "contrib/hooks/setgitperms: Use GIT_DIR if set"
or something like that.
 

Is there a document with guidelines for commit messages, e.g. write the
first letter upper or lower case?

There are a few unwritten conventions.  You can always check existing
commit messages, via

  $ git log --pretty=oneline --abbrev-commit --no-merges

and see that commit title (first line of commit message) is either
short sentence starting with upper case, bt without fullstop, or
sentence preceded by the subsystem affected, using "<subsystem>:"
prefix.

Examples:
  Fix use after free() in builtin-fetch
  git-svn: detect and fail gracefully when dcommitting to a void

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Hi Jakub,

Jakub Narebski schrieb am Mon 05. May, 07:10 (-0700):

Jörg Sommer [off-list ref] writes:

quoted

Johannes Schindelin schrieb am Mon 05. May, 12:36 (+0100):

quoted

quoted

If you do not say _what_ is affected by the change, you only confuse
the readers.

Do you want something like “initialization: Pay attention to GIT_DIR when
searching the git directory”?

I think the idea was to use
  "contrib/hooks/setgitperms: Use GIT_DIR if set"
or something like that.

Well, if this is the prefered form, I'll use it. But I don't like it,
because the affected file is a piece of information that's already in the
commit object. And it makes the :/ syntax useless, because in a series of
commits all commits start with the same string: the filename. Thirdly, in
gitk I've the problem that the space is very limited (because of my
screen) and it is very annoying to see the same string at the begin of
every commit message, especially when I've filtered for one file.

quoted

Is there a document with guidelines for commit messages, e.g. write the
first letter upper or lower case?

There are a few unwritten conventions.

Are there any plans to write them down?

Should I resend the patch or can Junio fix the commit message? I would
take your suggestion.

Bye, Jörg.
-- 
Geld allein macht nicht glücklich, aber es ist besser in einem Taxi zu
weinen, als in der Straßenbahn.
	       	   	       			(Marcel Reich‐Ranicki)

Hi,

On Mon, 5 May 2008, Jörg Sommer wrote:

Hi Jakub,

Jakub Narebski schrieb am Mon 05. May, 07:10 (-0700):

quoted

Jörg Sommer [off-list ref] writes:

quoted

Johannes Schindelin schrieb am Mon 05. May, 12:36 (+0100):

quoted

quoted

If you do not say _what_ is affected by the change, you only 
confuse the readers.

Do you want something like “initialization: Pay attention to GIT_DIR 
when searching the git directory”?

I think the idea was to use
  "contrib/hooks/setgitperms: Use GIT_DIR if set"
or something like that.

Well, if this is the prefered form, I'll use it. But I don't like it,
because the affected file is a piece of information that's already in the
commit object.

Well, I don't like that you thereby waste the time of those who look at 
the commit message.  By your reasoning, one might think that commit 
messages are superfluous, because you can always read the patch, or go 
back to the mailing list thread.

Ciao,
Dscho

quoted

There are a few unwritten conventions.

Are there any plans to write them down?

Actually, they are written down implicitly.  You can look at them with the 
command "git log".

Ciao,
Dscho

On Mon, 5. May 2008, Jörg Sommer wrote:

Hi Jakub,

Jakub Narebski schrieb am Mon 05. May, 07:10 (-0700):

quoted

Jörg Sommer [off-list ref] writes:

quoted

Johannes Schindelin schrieb am Mon 05. May, 12:36 (+0100):

quoted

quoted

If you do not say _what_ is affected by the change, you only confuse
the readers.

Do you want something like “initialization: Pay attention to GIT_DIR when
searching the git directory”?

I think the idea was to use
  "contrib/hooks/setgitperms: Use GIT_DIR if set"
or something like that.

Well, if this is the prefered form, I'll use it. But I don't like it,
because the affected file is a piece of information that's already in the
commit object. 

First, it is "subsystem", not the affected file. 'git-svn', 'gitweb',
'bash', 'completion'; in this case perhaps 'contrib/hooks', i.e.
  "contrib/hooks: Use GIT_DIR in setgitperms hook, if set"
or something like that.  IMVHO if a patch affest specific subsystem
only, and not the core part of git, you should always use subsystem
prefix, unless the name of subsystem can be put / is put in the commit
subject (first line of commit message).

Second, commit message should be written in such way that it is easy to
understand what the commit does from the first line (the commit summary),
and easy to understand the whats and whys of change from the full commit
message.  In "git log" output you don't see files affected by a commit.

And it makes the :/ syntax useless, because in a series of 
commits all commits start with the same string: the filename.

Commits affecting core don't need to start with a filename, dirname,
or subsystem name.  I gave an example _without_ prefix, didn't I?

[...]

quoted

quoted

Is there a document with guidelines for commit messages, e.g. write the
first letter upper or lower case?

There are a few unwritten conventions.

Are there any plans to write them down?

I think it is true for every project that to send good commit you have
to lurk a little, and examine existing commit messages when writting
one.  Linus Torvalds usually writes good commit messages here.

-- 
Jakub Narebski
Poland