From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] Rename git-config-set to git-repo-config
Date: Fri, 25 Nov 2005 21:52:31 -0800 [thread overview]
Message-ID: <7v4q609crk.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 7vmzjtn3h1.fsf@assigned-by-dhcp.cox.net
Linus Torvalds <torvalds@osdl.org> writes:
> Please don't.
>
> We should just make the scripts do it automatically instead.
Don't worry, we are in agreement about that goal.
> "git-rev-parse" already has support for all of this, and you can do
>
> GIT_DIR=$(git-rev-parse --git-dir)
> GIT_PREFIX=$(git-rev-parse --show-prefix)
>
> where the first one shows the GIT_DIR, and the second one shows where in a
> git directory we are (empty if we're at the root).
Not in one case -- out-of-tree GIT_DIR. That is what
GIT_WORKING_TREE is about.
> In fact, I'd prefer if _every_ command just did the right thing inside a
> subdirectory.
Of course.
The case your patch does not cover that I am worried about is
where GIT_DIR is totally out of the tree. Something like
GIT_DIR=/home/torvalds/uemacs.git and working tree at
/tmp/uemacs. There is currently no way for the tools to figure
out where the working tree toplevel is in such an arrangement,
and that is when GIT_WORKING_TREE becomes useful.
Under normal use pattern, with GIT_DIR not in such a funny place
but immediately under working tree root, you do not need GIT_DIR
nor GIT_WORKING_TREE. We can figure things ourselves by
chdir()-up and looking for '.git/' directory.
> I sent out this patch a week or two ago - it still applies, and it still
> mostly does the right thing. It makes at least "gitk" work right inside a
> subdirectory, and might make things like "git commit" and friends do the
> same.
I am afraid it needs more work --- as long as a script uses only
C-level that use setup_git_directory(), everything should work,
and in such a case you do not even need sh-setup --- asking
"git-rev-parse --git-dir" is enough, just like you did in
git-add. If the script does not have to know where GIT_DIR is
(and I do not think gitk needs to know it, although it digs
there by hand), it does not even need to do that. As you said,
git-log and git-whatchanged works without any funny trick and
are fine examples of that.
> More testing still needed, but I think this is going in the right
> direction.
>
> Comments? I got none the first time around.
Among the ones I looked at that use git-sh-setup in
Documentation directory of git.git:
- git-checkout nor git-reset do not work because git-read-tree
does not use setup_git_directory(), and git-sh-setup does not
export GIT_DIR.
And exporting GIT_DIR from git-sh-setup is not a solution.
To setup_git_directory(), existence of GIT_DIR environment
currently means you cannot tell where your toplevel is
anymore. We could check GIT_DIR against getcwd() and if it
is a grand*parent directory, do an appropriate thing
including chdir("$GIT_DIR/..") and returning an adjusted
prefix, but we don't. And that would not work if GIT_DIR is
really out-of-tree anyway.
That is why I keep saying GIT_WORKING_TREE. We could export
both GIT_DIR and GIT_WORKING_TREE from git-sh-setup, and
teach the C-level commands that need access to working tree
to look at it, just like we default GIT_OBJECT_DIRECTORY from
git-sh-setup. People with out of tree GIT_DIR needs to
export both GIT_DIR and GIT_WORKING_TREE to override both,
just like people with object directory in nonstandard place
need to export GIT_OBJECT_DIRECTORY.
Maybe GIT_WORKING_TREE can default to "$GIT_DIR/..", just
like GIT_OBJECT_DIRECTORY defaults to "$GIT_DIR/objects".
Another obvious approach is to stop supporting out-of-tree
GIT_DIR, but I suspect that probably means we should ignore
GIT_DIR environment and always chdir()-up to find .git/
(which is fine and sane but is probably an uncomfortably big
change).
- git-prune does not work because git-fsck-objects does not
know where GIT_DIR is (again, GIT_DIR not exported).
- git-tag works.
Here is a list of C-level and their subdirectory-readiness
status.
These do not look at .git at all -- automatically subdirectory
ready ;-):
check-ref-format get-tar-commit-id git index-pack
mailinfo mailsplit patch-id shell show-index stripspace
verify-pack
Uses setup_git_directory() and subdirectory ready:
cat-file config-set diff-files diff-index diff-stages
diff-tree ls-files name-rev rev-list rev-parse
show-branch symbolic-ref update-index update-ref var
Uses enter_repo() to work from the toplevel:
daemon receive-pack upload-pack
Wants GIT_DIR to know where it is and working tree access is
always toplevel:
apply checkout-index clone-pack commit-tree
convert-objects fetch-pack fsck-objects hash-object
http-fetch http-push init-db local-fetch ls-tree
merge-base merge-index mktag pack-objects pack-redundant
peek-remote prune-packed read-tree send-pack ssh-fetch
ssh-upload tar-tree unpack-file unpack-objects
update-server-info write-tree
next prev parent reply other threads:[~2005-11-26 5:52 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-20 17:00 Get rid of .git/branches/ and .git/remotes/? Johannes Schindelin
2005-11-20 18:09 ` Linus Torvalds
2005-11-20 18:29 ` Sven Verdoolaege
2005-11-20 19:07 ` Linus Torvalds
2005-11-20 19:16 ` Andreas Ericsson
2005-11-20 19:50 ` Johannes Schindelin
2005-11-26 23:50 ` Petr Baudis
2005-11-27 0:38 ` Junio C Hamano
2005-11-20 23:26 ` Josef Weidendorfer
2005-11-20 23:58 ` Johannes Schindelin
2005-11-22 17:31 ` Josef Weidendorfer
2005-11-22 17:56 ` Johannes Schindelin
2005-11-22 19:30 ` Andreas Ericsson
2005-11-23 15:08 ` Johannes Schindelin
2005-11-23 23:21 ` Junio C Hamano
2005-11-23 23:29 ` Andreas Ericsson
2005-11-23 23:42 ` Johannes Schindelin
2005-11-24 8:05 ` Andreas Ericsson
2005-11-24 8:33 ` Junio C Hamano
2005-11-24 10:36 ` [PATCH] Rename git-config-set to git-repo-config Johannes Schindelin
2005-11-24 11:33 ` Junio C Hamano
2005-11-24 13:28 ` Johannes Schindelin
2005-11-24 21:24 ` Junio C Hamano
2005-11-24 21:54 ` Johannes Schindelin
2005-11-26 2:22 ` Junio C Hamano
2005-11-26 4:05 ` Linus Torvalds
2005-11-26 4:07 ` Linus Torvalds
2005-11-26 9:51 ` [PATCH 0/8] Make C-level operable from subdirectories Junio C Hamano
2005-11-26 10:59 ` Junio C Hamano
2005-11-26 18:44 ` Ryan Anderson
2005-11-27 9:21 ` [PATCH 6/8] ls-tree: work from subdirectory Junio C Hamano
2005-11-27 11:08 ` Petr Baudis
2005-11-27 18:01 ` Linus Torvalds
2005-11-27 18:22 ` Petr Baudis
2005-11-27 19:00 ` Linus Torvalds
2005-11-28 1:07 ` Junio C Hamano
2005-11-28 1:46 ` Linus Torvalds
2005-11-28 6:11 ` Junio C Hamano
2005-11-28 6:48 ` Linus Torvalds
2005-11-28 8:32 ` Junio C Hamano
2005-11-28 10:51 ` Junio C Hamano
2005-11-28 10:51 ` [PATCH] ls-tree: Resurrect funny name quoting lost during rewrite Junio C Hamano
2005-11-26 5:52 ` Junio C Hamano [this message]
2005-11-26 9:56 ` [PATCH 1/8] git-apply: work from subdirectory Junio C Hamano
2005-11-26 17:36 ` Linus Torvalds
2005-11-26 18:54 ` Junio C Hamano
2005-11-27 4:06 ` Junio C Hamano
2005-11-27 14:39 ` Lars Magne Ingebrigtsen
[not found] ` <7vy839dfzk.fsf@assigned-by-dhcp.cox.net>
2005-11-27 21:13 ` Lars Magne Ingebrigtsen
2005-11-27 22:12 ` Junio C Hamano
2005-11-26 9:56 ` [PATCH 2/8] peek-remote: honor proxy config even " Junio C Hamano
2005-11-26 9:56 ` [PATCH 3/8] fsck-objects: work " Junio C Hamano
2005-11-26 9:56 ` [PATCH 4/8] checkout-index: " Junio C Hamano
2005-11-26 9:57 ` [PATCH 5/8] hash-object: work within subdirectory Junio C Hamano
2005-11-26 9:57 ` [PATCH 6/8] ls-tree: work from subdirectory Junio C Hamano
2005-11-26 17:38 ` Linus Torvalds
2005-11-26 9:57 ` [PATCH 7/8] Make networking commands to work from a subdirectory Junio C Hamano
2005-11-26 9:57 ` [PATCH 8/8] Make the rest of commands " Junio C Hamano
2005-11-22 23:05 ` Get rid of .git/branches/ and .git/remotes/? Josef Weidendorfer
2005-11-23 14:53 ` Johannes Schindelin
2005-11-23 15:39 ` Josef Weidendorfer
2005-11-23 17:22 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v4q609crk.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).