[PATCH] -C/--chdir command line option

[PATCH] -C/--chdir command line option

[Maciej Pasternacki]

In my project cl-librarian, which is a layer built upon different
version control systems, I need to run git pull, but start it from
outside of work tree; however, pull needs to be in work tree (as in
getcwd()) in order to update said work tree.  --git-dir and
--work-tree options don't work; I discussed it on #git yesterday,
and it turned out that this issue is nontrivial:

231701 <doener> hm, require_work_tree checks if you are _in_ the work tree,
    and pull only switches to the work tree after the require_work_tree
    call...
231710 <doener> looks like a chicken-egg-problem
231715 <shd> japhy`: spawning commands requires forking anyway, so do chdir in
    forked process
231739 <doener> if you move the "cd_to_toplevel" call up in git-push, so that
    it happens before require_work_tree, then it works
231747 <japhy`> shd: yup, that would be a workaround, but I tried to avoid
    shell-quoting ;)
231749 <japhy`> doener: push?
231756 <doener> ehrm, pull
    channel #git
231820 <doener> but I guess doing the cd_to_toplevel first might break somehow
    if there is no working tree...
231843 <japhy`> Oh.
231922 <doener> I'd just ask on the list about that.

I don't like the idea of doing chdir() myself -- this would expose me to a
whole world of portability issues, and I don't feel like spending time to
figure out how to do a fork on windows ;) the best workaround that occured to
me was adding -C/--chdir option to main git binary, like one that Make accepts.
This fixed my problem, I paste the resulting patch below:

>From 4461cd1be99772c93a83bcdfe6e6a86e71abaa35 Mon Sep 17 00:00:00 2001
From: Maciej Pasternacki <maciej@pasternacki.net>
Date: Sun, 19 Oct 2008 01:33:49 +0200
Subject: [PATCH] Add command line option --chdir/-C to allow setting git process work directory.

Signed-off-by: Maciej Pasternacki <maciej@pasternacki.net>
---
 Documentation/git.txt |    6 +++++-
 git.c                 |    9 ++++++++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index df420ae..6676d68 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -12,7 +12,7 @@ SYNOPSIS
 'git' [--version] [--exec-path[=GIT_EXEC_PATH]]
     [-p|--paginate|--no-pager]
     [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
-    [--help] COMMAND [ARGS]
+    [-C DIRECTORY|--chdir=DIRECTORY] [--help] COMMAND [ARGS]
 
 DESCRIPTION
 -----------
@@ -185,6 +185,10 @@ help ...`.
 	environment is not set, it is set to the current working
 	directory.
 
+-C <directory>::
+--chdir=<directory>::
+	Change working directory before doing anything.
+
 
 FURTHER DOCUMENTATION
 ---------------------
diff --git a/git.c b/git.c
index 89feb0b..8c97671 100644
--- a/git.c
+++ b/git.c
@@ -115,7 +115,14 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)
 			setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);
 			if (envchanged)
 				*envchanged = 1;
-		} else {
+		} else if (!strcmp(cmd, "-C") || !strcmp(cmd, "--chdir")) {
+                        chdir((*argv)[1]);
+                        (*argv)++;
+                        (*argc)--;
+                        handled++;
+                } else if (!prefixcmp(cmd,"--chdir=")) {
+                        chdir(cmd+8);
+                } else {
 			fprintf(stderr, "Unknown option: %s\n", cmd);
 			usage(git_usage_string);
 		}
-- 
1.6.0.1

Re: [PATCH] -C/--chdir command line option

[Jeff King]

On Sat, Oct 18, 2008 at 05:02:27PM -0700, Maciej Pasternacki wrote:

> In my project cl-librarian, which is a layer built upon different
> version control systems, I need to run git pull, but start it from
> outside of work tree; however, pull needs to be in work tree (as in
> getcwd()) in order to update said work tree.  --git-dir and
> --work-tree options don't work; I discussed it on #git yesterday,
> and it turned out that this issue is nontrivial:
> [...]
> the best workaround that occured to me was adding -C/--chdir option to
> main git binary, like one that Make accepts.  This fixed my problem, I
> paste the resulting patch below:

I'm not completely opposed to -C, as it does match some other tools,
but it does seem superfluous with --git-dir and --work-tree. Which makes
me feel like we are just papering over a bug instead of actually fixing
it (and to be honest, I always wondered what the point of "make -C" was
in the face of "cd dir && make").

I'm not sure if the actual problem is related to the oft-discussed,
unresolved work-tree startup woes, or is something much simpler to fix.
I'll try to look closer later today.

A few comments on your patch:

> From 4461cd1be99772c93a83bcdfe6e6a86e71abaa35 Mon Sep 17 00:00:00 2001
> From: Maciej Pasternacki <maciej@pasternacki.net>
> Date: Sun, 19 Oct 2008 01:33:49 +0200
> Subject: [PATCH] Add command line option --chdir/-C to allow setting git process work directory.
> 
> Signed-off-by: Maciej Pasternacki <maciej@pasternacki.net>

Please follow the usual list conventions; this stuff should be the
actual headers of your mail, not in the body of the message. And some of
the justification you gave above should be part of the commit message.

> +		} else if (!strcmp(cmd, "-C") || !strcmp(cmd, "--chdir")) {
> +                        chdir((*argv)[1]);

No error detection and reporting? I think I would be quite happy for
"git -C /some/path clean -dx" to bail out when it saw that it couldn't
change directory instead of just deleting the contents of wherever I
happened to be.

Also, the envchanged flag should probably be set, as for the git-dir and
work-tree options.

-Peff

Re: [PATCH] -C/--chdir command line option

[Maciej Pasternacki]

On 2008-10-19, at 15:17, Jeff King wrote:

> On Sat, Oct 18, 2008 at 05:02:27PM -0700, Maciej Pasternacki wrote:
>
>> In my project cl-librarian, which is a layer built upon different
>> version control systems, I need to run git pull, but start it from
>> outside of work tree; however, pull needs to be in work tree (as in
>> getcwd()) in order to update said work tree.  --git-dir and
>> --work-tree options don't work; I discussed it on #git yesterday,
>> and it turned out that this issue is nontrivial:
>> [...]
>> the best workaround that occured to me was adding -C/--chdir option  
>> to
>> main git binary, like one that Make accepts.  This fixed my  
>> problem, I
>> paste the resulting patch below:
>
> I'm not completely opposed to -C, as it does match some other tools,
> but it does seem superfluous with --git-dir and --work-tree. Which  
> makes
> me feel like we are just papering over a bug instead of actually  
> fixing
> it (and to be honest, I always wondered what the point of "make -C"  
> was
> in the face of "cd dir && make").

The point of make -C is exactly my usage pattern: invoking make from  
external program.  I have seen, at least in Lisp (external-program)  
and Python (os.spawn, subprocess), libraries to safely and portably  
execute external program by giving literal list of arguments (an easy  
to use wrapper to fork()+exec(); I don't know if such feature exists  
for C).  This allows me not to worry about quoting strange characters  
in pathnames (think injections, if just making it possible to use "&"  
character in directory name is not good enough a reason).  The  
equivalent of "cd dir && make" would be to use system() or invoke sh - 
c; both would require shell-quoting the directory pathname, and would  
carry portability issues -- how do I know that shell on target system  
is actually called "sh" and it supports "&&"?  At least Windows  
systems would be problematic.

The -C option allows me to just specify the directory as it is, and  
child process, after the fork, will take care of the chdir().  No  
quoting, no portability problems, injection-safety included.

As for -C being superfluous: --git-dir and --work-tree seem to support  
weird usage patterns (like work tree separate from git-dir), but it  
seems to me that --work-tree could be just made a synonym of -C, and  
it would behave as expected without creating chicken-and-egg problem  
that doener on #git found (which I don't really understand, but I also  
can't see what --work-tree allows that -C would not -- except creating  
more fragility).  I won't push on --work-tree and -C being  
functionally synonymous, since I don't know git well enough, it's just  
my impression at the moment.

> Please follow the usual list conventions; this stuff should be the
> actual headers of your mail, not in the body of the message. And  
> some of
> the justification you gave above should be part of the commit message.

ACK.  That was how I understood instructions linked from git.or.cz,  
I'll paste message correctly for next version of the patch.

>> +		} else if (!strcmp(cmd, "-C") || !strcmp(cmd, "--chdir")) {
>> +                        chdir((*argv)[1]);
>
> No error detection and reporting? I think I would be quite happy for
> "git -C /some/path clean -dx" to bail out when it saw that it couldn't
> change directory instead of just deleting the contents of wherever I
> happened to be.

Oops.  Looks like I'm spoiled by high-level languages that would  
automatically catch and display an error.  I'll prepare patch v2 today.

> Also, the envchanged flag should probably be set, as for the git-dir  
> and
> work-tree options.

OK.  I thought it means literally environment change, as in setenv().

Thank you for your comments, off to make v2 patch,
Maciej.

-- 
-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-

Re: [PATCH] -C/--chdir command line option

[Jeff King]

On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:

> As for -C being superfluous: --git-dir and --work-tree seem to support  
> weird usage patterns (like work tree separate from git-dir), but it seems 

Hmm. Yeah, thinking about it more, -C is not really superfluous with
respect to those options. You don't want to say "here is the work-tree,
and here is the git-dir". You want to say "find the work-tree and
git-dir for me using the usual rules, as if I were in this directory."

So you couldn't just say:

  git --work-tree=/chdir/path

since that would assume your current directory was the git-dir. You
would need:

  git --work-tree=/chdir/path --git-dir=/chdir/path/.git

but then you are overriding any usual lookup rules (e.g., somebody
having set GIT_DIR in the environment).

Though I am not clear from your original description if that is even
what you want. It sounds like you might be doing:

  git -C /chdir/path --git-dir=/back/to/where/I/was

in which case I think work-tree _is_ a better fit.

> to me that --work-tree could be just made a synonym of -C, and it would 
> behave as expected without creating chicken-and-egg problem that doener on 
> #git found (which I don't really understand, but I also can't see what 
> --work-tree allows that -C would not -- except creating more fragility).  

--work-tree allows you say "I'm _already_ in the git-dir, but please use
this other place for the work-tree". So you can, for example, checkout
files from a bare repository.

>> Also, the envchanged flag should probably be set, as for the git-dir
>> and work-tree options.
>
> OK.  I thought it means literally environment change, as in setenv().

It is really used to tell the options parser for aliases that some
options which change the operating environment should not be used in an
alias. I.e., something like:

  git config alias.foo "--git-dir=/path/to/whatever log"

isn't allowed, because we have already done some work on setting up the
git-dir at this point. IMHO, this is a limitation of the current
approach to setting up the environment, but fixing it would be
nontrivial.

I'm not 100% sure that doing a chdir should be disallowed in this
instance, but I suspect it would cause problems. I think it is better in
this instance to be conservative and disallow it in aliases.

-Peff

Re: [PATCH] -C/--chdir command line option

[Maciej Pasternacki]

On 2008-10-19, at 16:16, Jeff King wrote:

> Though I am not clear from your original description if that is even
> what you want. It sounds like you might be doing:
>
>  git -C /chdir/path --git-dir=/back/to/where/I/was
>
> in which case I think work-tree _is_ a better fit.

No.  I have a regular "git clone"'d work tree inside some "shelf"  
directory containing many repos (not only from git), and I'd like to  
pull changes into this work tree.  As simple as "cvs up".  But -- I  
don't want to chdir() there myself, and I had no problem with cvs, svn  
and darcs (didn't do other VC systems yet).  So, -C would do exactly  
what I need.

>>> Also, the envchanged flag should probably be set, as for the git-dir
>>> and work-tree options.
>>
>> OK.  I thought it means literally environment change, as in setenv().
>
> It is really used to tell the options parser for aliases that some
> options which change the operating environment should not be used in  
> an
> alias. I.e., something like:
>
>  git config alias.foo "--git-dir=/path/to/whatever log"
>
> isn't allowed, because we have already done some work on setting up  
> the
> git-dir at this point. IMHO, this is a limitation of the current
> approach to setting up the environment, but fixing it would be
> nontrivial.
>
> I'm not 100% sure that doing a chdir should be disallowed in this
> instance, but I suspect it would cause problems. I think it is  
> better in
> this instance to be conservative and disallow it in aliases.

In this case, I think envchanged should not be set -- I would expect - 
C dir to work *exactly* like "cd dir && git ...", including  
configuration, environment variables and so on.  OTOH, option like "-- 
no-env" may be useful in my case -- I want git to behave consistently  
on users' machines, regardless of their configuration.  This, however,  
is only a minor issue.

Regards,
Maciej.

-- 
-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-

Re: [PATCH] -C/--chdir command line option

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:
>
>> As for -C being superfluous: --git-dir and --work-tree seem to support  
>> weird usage patterns (like work tree separate from git-dir), but it seems 
>
> Hmm. Yeah, thinking about it more, -C is not really superfluous with
> respect to those options. You don't want to say "here is the work-tree,
> and here is the git-dir". You want to say "find the work-tree and
> git-dir for me using the usual rules, as if I were in this directory."

I think that interpretation of -C, if the option existed, makes sense, but
I do not understand why the tool that drives git refuses to chdir to the
repository for itself in the first place.

The only excuse I remember seeing in the thread was that "make has '-C'
option, so let's have it, because it is similar", which does not justfiy
addition of that option to git at all to me.

With "make", the -C option can be justified as a necessary tool to write a
recursive Makefile that can be sanely and easily processed without
actually executing any commands (iow, imaging implementing "make" that
allows you to write "cd there && $(MAKE)" in the toplevel Makefile and
tells the users what would happen in "there" when run as "make -n").

And even in "make" context, not all implementations have it.  I think it
is only GNU and fairly recent BSDs.

Re: [PATCH] -C/--chdir command line option

[Junio C Hamano]

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

> The only excuse I remember seeing in the thread was that "make has '-C'
> option, so let's have it, because it is similar", which does not justfiy
> addition of that option to git at all to me.

Just after having said that "make has it, so let's have it ourselves, too"
is a non-excuse to any feature bloat, one thing I could accept a patch to
imitate what "make" does, especially if we are going to actually clean up
the startup sequence like we have discussed sometime ago to fix breakage
around --work-tree, is to have VAR=VAL (e.g. "make CFLAGS=-O2") on the
command line.  We could use that syntax to allow configuration variables
to be overridden, like so:

	$ git core.whitespace=cr-at-eol log -p master..next

I wouldn't however suggest allowing the syntax to set environment
variables, like:

	$ git GIT_AUTHOR_NAME="A U Thor" commit

as this is something your shell lets you do easily, i.e:

	$ GIT_AUTHOR_NAME="A U Thor" git commit

But overriding some configuration variables for a single command
invocation is not something you can do without actually editing the
configuration file for some variables, so the former would be justified.

Re: [PATCH] -C/--chdir command line option

[Alex Riesen]

2008/10/20 Junio C Hamano <gitster@pobox.com>:
> Junio C Hamano <gitster@pobox.com> writes:
> I wouldn't however suggest allowing the syntax to set environment
> variables, like:
>
>        $ git GIT_AUTHOR_NAME="A U Thor" commit
>
> as this is something your shell lets you do easily, i.e:
>
>        $ GIT_AUTHOR_NAME="A U Thor" git commit
>

No, someplace else it doesn't (yes, windows again).
It is mostly hard to do there, because the system shell is so
primitive, and installation of something sane (sh or env) is
an additional (and hard to explain to windows zealots) hassle.

And even in something like Perl it is hard: you cannot
change the environment just for the child process, you
have to change your own, run the process and change
it back.

So, yes, I like your suggestion, but I'd like to _include_
setting all the Git's environment.

Re: [PATCH] -C/--chdir command line option

[Maciej Pasternacki]

On 2008-10-20, at 06:55, Junio C Hamano wrote:

>>> As for -C being superfluous: --git-dir and --work-tree seem to  
>>> support
>>> weird usage patterns (like work tree separate from git-dir), but  
>>> it seems
>>
>> Hmm. Yeah, thinking about it more, -C is not really superfluous with
>> respect to those options. You don't want to say "here is the work- 
>> tree,
>> and here is the git-dir". You want to say "find the work-tree and
>> git-dir for me using the usual rules, as if I were in this  
>> directory."
>
> I think that interpretation of -C, if the option existed, makes  
> sense, but
> I do not understand why the tool that drives git refuses to chdir to  
> the
> repository for itself in the first place.

The tool (a) manages many repositories, and I don't want to chdir()  
back and forth, (b) should be able to manage those repositories not  
disturbing anything other.  It comes as a Common Lisp library, which  
will usually be called by end user, but can also be called  
programmatically, and I wouldn't want any library to change my cwd; it  
could chdir() back, of course, but this would still be a race  
condition if other threads were running at the same time.

And there is the Lisp-specific thing, that the language comes from  
before Unix domination, and things as simple as changing the process'  
cwd are actually nontrivial to do portably (there is equivalent of cwd  
inside Lisp world, which is used by Lisp-level file access routines,  
but chdir() is not in ANSI standard, is done differently by every  
implementation, and would require some kind of compatibility layer).

For me, -C would make life much easier, and I gave other arguments for  
it before.  It would suffice if --work-tree worked with "git pull", if  
-C doesn't pass, but it seems to me that -C has some merits.

Regards,
Maciej.

-- 
-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-

Re: [PATCH] -C/--chdir command line option

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 20.10.2008 06:55:
> Jeff King <peff@peff.net> writes:
> 
>> On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:
>>
>>> As for -C being superfluous: --git-dir and --work-tree seem to support  
>>> weird usage patterns (like work tree separate from git-dir), but it seems 
>> Hmm. Yeah, thinking about it more, -C is not really superfluous with
>> respect to those options. You don't want to say "here is the work-tree,
>> and here is the git-dir". You want to say "find the work-tree and
>> git-dir for me using the usual rules, as if I were in this directory."
> 
> I think that interpretation of -C, if the option existed, makes sense, but
> I do not understand why the tool that drives git refuses to chdir to the
> repository for itself in the first place.
> 
> The only excuse I remember seeing in the thread was that "make has '-C'
> option, so let's have it, because it is similar", which does not justfiy
> addition of that option to git at all to me.

I want to have '-j2' ;)

Seriously:

git -C elsewhere command opts

is shorther and more direct than

(cd elsewhere && git command opts)

which is the true equivalent, or

pushd elsewhere; git command opts; popd

And much shorter than using --git-dir and --work-tree, which are
semi-broken right now.

I just think it's very useful to be able to peek into a repo somewhere
else quickly; or for transferral of objects between unrelated objects
(run rev-parse elsewhere etc.).

Michael

Re: [PATCH] -C/--chdir command line option

[Nguyen Thai Ngoc Duy]

On 10/19/08, Jeff King <peff@peff.net> wrote:
>  I'm not sure if the actual problem is related to the oft-discussed,
>  unresolved work-tree startup woes, or is something much simpler to fix.
>  I'll try to look closer later today.

I think all commands should be able to jump to worktree even if you
are outside work-tree. git-pull and similar commands are easy because
they don't take pathnames. The way pathnames are handled in git does
not make it easy for outside current working directory, because if old
cwd is outside worktree, the parameter "prefix" sent to those commands
become "../../blah/", not a real prefix anymore. If a command expects
an index pathname, then that prefix should be rejected. If they expect
a filesystem pathname, it can be used with care.
-- 
Duy