git commands that only work correctly at top directory

git commands that only work correctly at top directory

[Nguyen Thai Ngoc Duy]

Here is the list (checks are done in with 1.4.2.rc4):
count-objects (always 0 objects, 0 kilobytes)
bisect (fatal: Not a git repository: '.git'. Bad HEAD - I need a symbolic ref)
describe (fatal: Not a valid object name HEAD)
repack (line 42: cd: .git/objects/pack: No such file or directory. And
it creates a new .git directory in current directory)
git format-patch in subdir generates files in topdir instead of
current dir as documented in its man page

BTW, either git blame or git annotate should be available in git help's listing.
git format-patch with no argument shows nothing. It should show help
usage instead.
I might miss some commands because I only tested commands I'm familiar with.
-- 
Duy

[PATCH] format-patch: use cwd as default output directory

[Matthias Lederhofer]

---
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> git format-patch in subdir generates files in topdir instead of
> current dir as documented in its man page
Here is a patch for this.
---
 builtin-log.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index fbc58bb..130b53a 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -270,6 +270,8 @@ int cmd_format_patch(int argc, const cha
 
 	rev.extra_headers = extra_headers;
 
+	output_directory = prefix;
+
 	/*
 	 * Parse the arguments before setup_revisions(), or something
 	 * like "git fmt-patch -o a123 HEAD^.." may fail; a123 is
-- 
1.4.2.1.ge767

Re: [PATCH] format-patch: use cwd as default output directory

[Nguyen Thai Ngoc Duy]

This patch works great. I assume you forgot it?

On 9/22/06, Matthias Lederhofer <matled@gmx.net> wrote:
> ---
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > git format-patch in subdir generates files in topdir instead of
> > current dir as documented in its man page
> Here is a patch for this.
> ---
>  builtin-log.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-log.c b/builtin-log.c
> index fbc58bb..130b53a 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -270,6 +270,8 @@ int cmd_format_patch(int argc, const cha
>
>         rev.extra_headers = extra_headers;
>
> +       output_directory = prefix;
> +
>         /*
>          * Parse the arguments before setup_revisions(), or something
>          * like "git fmt-patch -o a123 HEAD^.." may fail; a123 is
> --
> 1.4.2.1.ge767
>
>
-- 
Duy

Re: [PATCH] format-patch: use cwd as default output directory

[Junio C Hamano]

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

> This patch works great. I assume you forgot it?

Thanks for reminding.

[PATCH] git-format-patch: fix bug using -o in subdirectories

[Matthias Lederhofer]

This was introduced by me in commit v1.4.2.1-gc08e524.

Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> 
> > This patch works great. I assume you forgot it?
> 
> Thanks for reminding.
Argh, there is a bug.  When prefix is not NULL and -o is specified
git-format-patch fails:
~/src/git/a% ../git-format-patch -o ./b HEAD~1
fatal: Two output directories?
---
 builtin-log.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index 130b53a..9d1ceae 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -270,8 +270,6 @@ int cmd_format_patch(int argc, const cha
 
 	rev.extra_headers = extra_headers;
 
-	output_directory = prefix;
-
 	/*
 	 * Parse the arguments before setup_revisions(), or something
 	 * like "git fmt-patch -o a123 HEAD^.." may fail; a123 is
@@ -350,6 +348,9 @@ int cmd_format_patch(int argc, const cha
 	if (!rev.diffopt.output_format)
 		rev.diffopt.output_format = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
 
+	if (!output_directory)
+		output_directory = prefix;
+
 	if (output_directory) {
 		if (use_stdout)
 			die("standard output, or directory, which one?");
-- 
1.4.2.1.ge767

Re: git commands that only work correctly at top directory

[Matthias Lederhofer]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Here is the list (checks are done in with 1.4.2.rc4):
> count-objects (always 0 objects, 0 kilobytes)
> bisect (fatal: Not a git repository: '.git'. Bad HEAD - I need a symbolic 
> ref)
> describe (fatal: Not a valid object name HEAD)
> repack (line 42: cd: .git/objects/pack: No such file or directory. And
> it creates a new .git directory in current directory)
count-objects and describe work in the current master.
repack/bisect/reset and some other commands make only sense from the
toplevel directory but anyway I would allow them to be run in a
subdirectory and change up to the topdirectory (like git checkout for
branch switching).  Is there any good reason not to do this?  I found
it often annoying to go down to the toplevel directory/get a new shell
just to reset to HEAD~1.

Re: git commands that only work correctly at top directory

[Nguyen Thai Ngoc Duy]

On 9/22/06, Matthias Lederhofer <matled@gmx.net> wrote:
> count-objects and describe work in the current master.
Yes. Somehow my master is not updated to origin :(

> repack/bisect/reset and some other commands make only sense from the
> toplevel directory but anyway I would allow them to be run in a
> subdirectory and change up to the topdirectory (like git checkout for
> branch switching).  Is there any good reason not to do this?  I found
> it often annoying to go down to the toplevel directory/get a new shell
> just to reset to HEAD~1.
In case there is good reason not to do it, I'd like those commands to
tell users run them in top directory. (Although I prefer to run it
everywhere, I hate to cd around just for one command)
-- 
Duy

Re: git commands that only work correctly at top directory

[Petr Baudis]

Dear diary, on Fri, Sep 22, 2006 at 01:26:15PM CEST, I got a letter
where Matthias Lederhofer <matled@gmx.net> said that...
> repack/bisect/reset and some other commands make only sense from the
> toplevel directory but anyway I would allow them to be run in a
> subdirectory and change up to the topdirectory (like git checkout for
> branch switching).  Is there any good reason not to do this?  I found
> it often annoying to go down to the toplevel directory/get a new shell
> just to reset to HEAD~1.

Probably not for repack, but in case of bisect and especially reset it
would be reasonable to expect that it will touch just the subdirectory
and in case of git reset --hard that could be deadly.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

[PATCH] git-repack: allow git-repack to run in subdirectory

[Jeff King]

Now that we explicitly create all tmpfiles below $GIT_DIR, there's no reason
to care about which directory we're in.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-repack.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/git-repack.sh b/git-repack.sh
index 9ae5092..f2c9071 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -4,6 +4,7 @@ # Copyright (c) 2005 Linus Torvalds
 #
 
 USAGE='[-a] [-d] [-f] [-l] [-n] [-q]'
+SUBDIRECTORY_OK='Yes'
 . git-sh-setup
 
 no_update_info= all_into_one= remove_redundant=
-- 
1.4.2.1.gb6052-dirty

Re: git commands that only work correctly at top directory

[Thomas Kolejka]

-------- Original-Nachricht --------
Datum: Fri, 22 Sep 2006 16:21:09 +0700
Von: "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>
An: git@vger.kernel.org
Betreff: git commands that only work correctly at top directory

Did you set $GIT_DIR? ... to an absolute path or "./.git" ?

> Here is the list (checks are done in with 1.4.2.rc4):
> count-objects (always 0 objects, 0 kilobytes)

Works for me in every directory with GIT_DIR abolute or ./.git

> bisect (fatal: Not a git repository: '.git'. Bad HEAD - I need a symbolic
> ref)

with an absolute GIT_DIR works from every directory - at least bisect start

> describe (fatal: Not a valid object name HEAD)

with an absolute GIT_DIR works from every directory.
v1.4.1-gcddb939


> repack (line 42: cd: .git/objects/pack: No such file or directory. And
> it creates a new .git directory in current directory)
> git format-patch in subdir generates files in topdir instead of
> current dir as documented in its man page
> 
> BTW, either git blame or git annotate should be available in git help's
> listing.
> git format-patch with no argument shows nothing. It should show help
> usage instead.
> I might miss some commands because I only tested commands I'm familiar
> with.
> -- 
> Duy


Thomas

-- 
NEU: GMX DSL Sofort-Start-Set - blitzschnell ins Internet!
Echte DSL-Flatrate ab 0,- Euro* http://www.gmx.net/de/go/dsl

[PATCH/RESEND] git-repack: allow git-repack to run in subdirectory

[Jeff King]

Now that we explicitly create all tmpfiles below $GIT_DIR, there's no reason
to care about which directory we're in.

Signed-off-by: Jeff King <peff@peff.net>
---
There was no response on this; is there any reason not to allow this, or
did it just get dropped?

 git-repack.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/git-repack.sh b/git-repack.sh
index 9ae5092..f2c9071 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -4,6 +4,7 @@ # Copyright (c) 2005 Linus Torvalds
 #
 
 USAGE='[-a] [-d] [-f] [-l] [-n] [-q]'
+SUBDIRECTORY_OK='Yes'
 . git-sh-setup
 
 no_update_info= all_into_one= remove_redundant=
-- 
1.4.2.1.gb6052-dirty

Re: [PATCH/RESEND] git-repack: allow git-repack to run in subdirectory

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Now that we explicitly create all tmpfiles below $GIT_DIR, there's no reason
> to care about which directory we're in.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> There was no response on this; is there any reason not to allow this, or
> did it just get dropped?

Simply forgotten; it might be _correct_ but it is not important.

While it may technically be correct that the command could be
run from anywhere, repack is a whole repository operation, and
it is an operation performed not that often.  There is no reason
to forbid it to run from subdirectories, but it does not hurt
users much if it did.

Will queue for "next" and push it out before 1.4.3 if I do not
forget it again ;-).