{"thread":{"id":"206","subject":"\"GIT_INDEX_FILE\" environment variable","startedAt":"2005-04-21T18:09:52Z","lastAt":"2005-04-22T22:55:35Z","messageCount":14,"participants":["Linus Torvalds","Davide Libenzi","Junio C Hamano","Zach Welch","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1152","messageId":"Pine.LNX.4.58.0504211100330.2344@ppc970.osdl.org","threadId":"206","inReplyTo":null,"subject":"\"GIT_INDEX_FILE\" environment variable","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-21T18:09:52Z","receivedAt":"2005-04-21T18:09:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nThis checkin goes along with the previous one, and makes it easier to use \nall the normal git operations on temporary index files:\n\n Add support for a \"GIT_INDEX_FILE\" environment variable.\n \n We use that to specify alternative index files, which can be useful\n if you want to (for example) generate a temporary index file to do\n some specific operation that you don't want to mess with your main\n one with.\n \n It defaults to the regular \".git/index\" if it hasn't been specified.\n\nand it's particularly useful for doing things like \"read a tree into a \ntemporary index file, and write the result out\". For example, say that you \nwanted to know what the Makefile looked like in a particular release, \nyou could do\n\n GIT_INDEX_FILE=.tmp-index read-tree $release\n GIT_INDEX_FILE=.tmp-index checkout-cache --prefix=old- Makefile\n rm .tmp-index\n\nand you're done. Your old Makefile version is now in \"old-Makefile\" (and\nthis is also where it's nice that checkout-cache refuses to overwrite\nexisting files by default: if you forgot or messed up the prefix, it's all\ngood).\n\nYou can also use it to test merges without screwing up your old index file \nin case something goes wrong.\n\nDid I already happen to mention that I think that the git model is the\nbest model ever, and that I'm just not an incredibly good-looking hunk and\nbecomingly modest, I'm smart too?\n\n\t\tLinus\n"},{"id":"1153","messageId":"Pine.LNX.4.58.0504211110210.28776@bigblue.dev.mdolabs.com","threadId":"206","inReplyTo":"Pine.LNX.4.58.0504211100330.2344@ppc970.osdl.org","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-04-21T18:11:18Z","receivedAt":"2005-04-21T18:11:18Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Thu, 21 Apr 2005, Linus Torvalds wrote:\n\n> Did I already happen to mention that I think that the git model is the\n> best model ever, and that I'm just not an incredibly good-looking hunk and\n> becomingly modest, I'm smart too?\n\nYou forgot, *again*, to take your medications !!\n\n\n\n- Davide\n\n"},{"id":"1159","messageId":"Pine.LNX.4.58.0504211130480.2344@ppc970.osdl.org","threadId":"206","inReplyTo":"Pine.LNX.4.58.0504211100330.2344@ppc970.osdl.org","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-21T18:37:48Z","receivedAt":"2005-04-21T18:37:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 21 Apr 2005, Linus Torvalds wrote:\n> \n> You can also use it to test merges without screwing up your old index file \n> in case something goes wrong.\n\nBtw, if it wasn't obvious, for the merge thing to work you need to first\ncopy the old index file _or_ generate a new temporary index file first, so\nthat doing the three-way merge has a previous index file to work with. Ie\nit would look something like\n\n\tcp .git/index .tmp-index\n\tGIT_INDEX_FILE=.tmp-index read-tree -m $orig $branch1 $branch2\n\nbut this same approach can also be used to merge things _without_ actually\nhaving any specific version checked out, in which case it would just be\n\n\tGIT_INDEX_FILE=.tmp-index read-tree $orig\n\tGIT_INDEX_FILE=.tmp-index read-tree -m $orig $branch1 $branch2\n\nwhich allows you to create a merged index file that is totally independent \non whatever (if anything) you happen to be working on right now.\n\nTogether with a SHA1_FILE_DIRECTORY, it allows you to do merges entirely\noutside any real git tree, and without any other setup. That's quite nice\nfor the case where your actual working tree may be dirty, and you don't\nwant to mess around in it.\n\n\t\t\tLinus\n"},{"id":"1223","messageId":"7vis2fbr0p.fsf@assigned-by-dhcp.cox.net","threadId":"206","inReplyTo":"Pine.LNX.4.58.0504211100330.2344@ppc970.osdl.org","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Junio C Hamano","fromEmail":"junio@siamese.dyndns.org","sentAt":"2005-04-22T00:21:10Z","receivedAt":"2005-04-22T00:21:10Z","isPatch":false,"sender":{"key":"junio@siamese.dyndns.org","avatar":null},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> Add support for a \"GIT_INDEX_FILE\" environment variable.\n \nLT> We use that to specify alternative index files, which can be useful\nLT> if you want to (for example) generate a temporary index file to do\nLT> some specific operation that you don't want to mess with your main\nLT> one with.\n \nLT> It defaults to the regular \".git/index\" if it hasn't been specified.\n\nThis is all good. I have a related issue I'd like to hear your\nopinion about.\n\nWhen I am not in the top-level directory, relative to the tree\nstructure $GIT_INDEX_FILE describes, obviously I cannot just say\n\"show-diff path-pattern\" (or even just \"show-diff\") without\nfirst chdir'ing to the top. My current workaround I use in the\njit-show-diff wrapper script is quite ugly:\n\n - Starting from dir=\"${PWD-\"$(pwd)\"}\", repeatedly do\n dir=$(dirname dir) until I find a $dir/.git directory. Call\n the first directory I find that has .git subdirectory\n $GIT_PROJECT_TOP.\n\n - At the same time, inspect GIT_INDEX_FILE and\n SHA1_FILE_DIRECTORY environment variables. If they are not\n set, set them to $GIT_PROJECT_TOP/.git/index and\n $GIT_PROJECT_TOP/.git/objects, respectively and export them.\n\n - Figure out the name of the current working directory relative\n to $GIT_PROJECT_TOP. I'll call this value $R for brevity in\n the following description.\n\n - chdir to $GIT_PROJECT_TOP and run \"show-diff\" with the\n original flags and _all_ the user supplied paths prefixed\n with $R.\n\nTo illustrate what I just said:\n\n $ /bin/ls -aF\n ./ ../ .git/ a/\n $ /bin/ls -aF .git\n . ../ HEAD index objects/ \n $ cd a\n $ /bin/ls -aF\n . ../ bar foo/\n $ show-diff -r foo ; # of course this does not work.\n $ jit-show-diff -r foo\n\n The wrapper figures out that .. is the project top to chdir\n to, and $R is \"a/\". Using these values, it eventually calls:\n\n cd .. ; show-diff -r \"a/foo\"\n\nThis is not so hard to arrange in the wrapper, but this is quite\nbrittle. The show-diff command happens to take only -r, -z, and\n-q flag parameters so the wrapper can prefix $R to all the other\nparamters, but for other git core commands when to prefix $R and\nwhen not to soon becomes a maintenance nightmare.\n\nI am thinking about an alternative way of doing the above by\nsome modifications to the git core. I think the root of this\nproblem is that there is no equivalent to GIT_INDEX_FILE and\nSHA1_FILE_DIRECTORY that tells the core git where the project\ntop directory (i.e. the root of the working tree that\ncorresponds to what $GIT_INDEX_FILE describes) is.\n\nI am wondering if this alternative is acceptable by you before I\nspend too much time on it.\n\n - A new environment variable GIT_WORKING_TREE points at the\n root of the working tree.\n\n - Each git core command [*1*] that looks at the working tree is\n modified to take the user supplied pathname as a path\n relative to the current working directory, and use\n GIT_WORKING_TREE value to figure out which path the user is\n talking about, relative to the tree structure GIT_INDEX_FILE\n describes.\n\nThere is no need for jit-show-diff-wrapper when the above change\nhappens. The user (or Cogito) has to set and export\nGIT_WORKING_TREE once, and whereever the user happens to be the\ncore git command would just work as expected.\n\nWhat do you think?\n\n\n[Footnotes]\n\n*1* Yes I am aware that there are tons of them that need this\nsurgery if we wanted to take this approach.\n\n"},{"id":"1238","messageId":"Pine.LNX.4.58.0504212200400.2344@ppc970.osdl.org","threadId":"206","inReplyTo":"7vis2fbr0p.fsf@assigned-by-dhcp.cox.net","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-22T05:05:06Z","receivedAt":"2005-04-22T05:05:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 21 Apr 2005, Junio C Hamano wrote:\n> \n> I am thinking about an alternative way of doing the above by\n> some modifications to the git core. I think the root of this\n> problem is that there is no equivalent to GIT_INDEX_FILE and\n> SHA1_FILE_DIRECTORY that tells the core git where the project\n> top directory (i.e. the root of the working tree that\n> corresponds to what $GIT_INDEX_FILE describes) is.\n\nI'd _really_ prefer to just try to teach people to work from the \"top\" \ndirectory instead.\n\n> - A new environment variable GIT_WORKING_TREE points at the\n> root of the working tree.\n> \n> - Each git core command [*1*] that looks at the working tree is\n> modified to take the user supplied pathname as a path\n> relative to the current working directory, and use\n> GIT_WORKING_TREE value to figure out which path the user is\n> talking about, relative to the tree structure GIT_INDEX_FILE\n> describes.\n\nI really don't like it that much, but to some degree it obviously is\nexactly what \"--prefix=\" does to checkout-cache. It's basically saying \nthat all normal file operations have to be prefixed with a magic string. \n\nAnd git really doesn't do too many of those, so maybe it's ok. What would \nthe patch look like? I don't really love the idea, but if the patch is \nclean enough...\n\n\t\tLinus\n"},{"id":"1240","messageId":"7vzmvr72j6.fsf@assigned-by-dhcp.cox.net","threadId":"206","inReplyTo":"Pine.LNX.4.58.0504212200400.2344@ppc970.osdl.org","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-22T06:23:41Z","receivedAt":"2005-04-22T06:23:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> I'd _really_ prefer to just try to teach people to work from\nLT> the \"top\" directory instead.\n\nI share the sentiment, but I do not think that is an option.\nThere are three possibilities:\n\n - Train people to always work from the top and never support\n working in subdirectory at any layer.\n\n - Admit that people cannot be trained, and support it at Cogito\n layer.\n\n - Further admit that to support it without core layer help,\n what Cogito layer needs to do involves quite a lot of \"yuck\"\n factor.\n\nFor somebody whose primary concern is to pull the whole tree\nfrom outside and watch out for merge conflicts, always working\nfrom the top may be a practical option. But you also have to\nconsider that the people who actually feed those whole trees to\nyou probably do most of their work in their subdirectories. You\nwould want to make life easier for them in order for you to get\nhigh-quality results from them.\n\nI initially thought that the third one in the above list was the\ncase, and that's why I asked. After reviewing the core layer to\nsee the extent of the damage the proposed change would cause, to\nmy surprise, it turns out that it is not all that bad. It\nprobably is not surprising to you because of the way you\ndesigned things --- doing as much as possible in the dircache,\nand avoiding looking at the working tree.\n\nThe commands I would want to take paths relative to the user cwd\nare quite limited; note that I just want these available to the\nuser and I do not care which one, the core or Cogito, groks the\ncwd relative paths:\n\n check-files paths...\n show-diff [-R] [-q] [-s] [-z] [paths...]\n update-cache [--add] [--remove] [--refresh]\n [--cacheinfo mode blob-id] paths...\n\nThe only parameters that needs $R prefixing are the \"paths...\"\nabove. I think the wrapper layer can manage without the help\nfrom the core layer for these small number of commands using the\nworkaround I outlined in my previous message.\n\nIn addition, there is another one that looks at the working\ntree:\n\n diff-cache [-z] [-r] [--cached] tree-id\n\nBut this one is even easier. The wrapper layer needs to figure\nout the project top, chdir to it and run the underlying\ndiff-cache there.\n\nLT> I really don't like it that much, but to some degree it\nLT> obviously is exactly what \"--prefix=\" does to\nLT> checkout-cache. It's basically saying that all normal file\nLT> operations have to be prefixed with a magic string.\n\nMore or less so. I actually was thinking about going a bit more\nthan just prefix, and normalizing paths in the core layer, in\norder to get something like the following operate sensibly:\n\n $ find . -type f | xargs update-cache\n $ cd mozilla-sha1 && show-diff ../*.h\n\nBut this may be going a bit overboard.\n\nLT> And git really doesn't do too many of those, so maybe it's\nLT> ok. What would the patch look like? I don't really love the\nLT> idea, but if the patch is clean enough...\n\nPlease forget this one for a bit. I'm attacking this from both\nfronts.\n\nCore changes supporting the \"project root\" notion is what we are\ndiscussing here. As I said, I do not think it would be a huge\nchange as I feared initially, but after the initial \"let's get\nthe list of commands and analyze how they use the paths\" phase,\nI have backburnered this approach, at least for now. Working\naround in the wrapper layer without core support seems to be a\nviable option, especially now I know that what needs to be\nwrapped are not that many, and that is what I've been looking\nat this evening.\n\nFor your amusement, eh, rather, to test your \"yuck\" tolerance\n;-), I've attached two scripts. jit-find-index is a helper\nscript for wrappers. It finds the project root and computes $R\nprefix; the wrappers call it and eval its result.\njit-update-cache is a wrapper to run update-cache inside of\nsubdirectory. This is the worst example among the four wrappers.\n\nNot-Signed-off-yet-by: Junio C Hamano \n---\n\n jit-find-index | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++\n jit-update-cache | 23 +++++++++++++++++++++\n 2 files changed, 83 insertions(+)\n\n--- /dev/null\t2005-03-19 15:28:25.000000000 -0800\n+++ jit-find-index\t2005-04-21 22:59:55.000000000 -0700\n@@ -0,0 +1,60 @@\n+#!/bin/sh\n+\n+sq=s/\\'/\\''\\\\'\\'\\'/g ;# see sq-expand in show-diff.c\n+\n+lookfor_index=${GIT_INDEX_FILE-.git/index}\n+lookfor_object=${SHA1_FILE_DIRECTORY-.git/objects}\n+\n+index= object= project_top=\n+\n+# No point in looking for something specified with an absolute path.\n+case \"$lookfor_index\" in\n+/*) index=\"$lookfor_index\" ;;\n+esac\n+case \"$lookfor_object\" in\n+/*) object=\"$lookfor_object\" ;;\n+esac\n+\n+# Beware of symlinks. We need to find out what the current directory\n+# is called relative to the path recorded in the dircache.\n+dir=${PWD-$(pwd)} cwd=\"$dir\" down=\n+\n+while \n+ case \"$dir\" in /) break ;; esac && # we searched all.\n+ case \",$index,$object,$project_top,\" in\n+ *,,*) ;;\n+ *) break ;; # we now have all.\n+ esac\n+do\n+ case \"$index\" in\n+ '') test -f \"$dir/$lookfor_index\" &&\n+\tindex=\"$dir/$lookfor_index\" ;;\n+ esac\n+ case \"$object\" in\n+ '') test -d \"$dir/$lookfor_object\" &&\n+\tobject=\"$dir/$lookfor_object\" ;;\n+ esac\n+\n+ case \"$project_top\" in\n+ '') test -d \"$dir/.git\" &&\n+\tproject_top=\"$dir\" &&\n+\tworking_dir=\"$down\" ;;\n+ esac\n+ down=\"$(basename \"$dir\")/$down\"\n+ dir=$(dirname \"$dir\")\n+done\n+\n+if test ! -f \"$index\" || test ! -d \"$object\" || test ! -d \"$project_top\"\n+then\n+ echo >&2 \\\n+ \"Cannot find the project top, index file, or object database.\"\n+ echo exit 1 ;# love this!\n+else\n+ # Working directory relative to the project top\n+\n+ echo \"GIT_INDEX_FILE='$(echo \"$index\" | sed -e \"$sq\")'\"\n+ echo \"SHA1_FILE_DIRECTORY='$(echo \"$object\" | sed -e \"$sq\")'\"\n+ echo \"GIT_PROJECT_TOP='$(echo \"$project_top\" | sed -e \"$sq\")'\"\n+ echo \"GIT_WORKING_DIR='$(echo \"$working_dir\" | sed -e \"$sq\")'\"\n+ echo export GIT_INDEX_FILE SHA1_FILE_DIRECTORY GIT_PROJECT_TOP\n+fi\n\n\n\n--- /dev/null\t2005-03-19 15:28:25.000000000 -0800\n+++ jit-update-cache\t2005-04-21 22:59:48.000000000 -0700\n@@ -0,0 +1,23 @@\n+#!/bin/sh\n+\n+eval \"$(jit-find-index)\"\n+sq=s/\\'/\\''\\\\'\\'\\'/g\n+RQ=$(echo \"$GIT_WORKING_DIR\" | sed -e \"$sq\")\n+args=\n+while case \"$#\" in 0) break ;; esac\n+do\n+\tcase \"$1\" in\n+\t--add | --remove | --refresh)\n+\t args=\"${args}$1 \" ;;\n+\t--cacheinfo)\n+\t args=\"${args}$1 \"\n+\t shift; args=\"${args}'$(echo \"$1\" | sed -e \"$sq\")' \"\n+\t shift; args=\"${args}'$(echo \"$1\" | sed -e \"$sq\")' \" ;;\n+\t*)\n+\t args=\"${args}'$RQ$(echo \"$1\" | sed -e \"$sq\")' \" ;;\n+\tesac\n+\tshift\n+done\n+eval \"set x $args; shift\"\n+\n+cd $GIT_PROJECT_TOP && exec update-cache \"$@\"\n\n\n\n"},{"id":"1251","messageId":"4268C070.3010706@superlucidity.net","threadId":"206","inReplyTo":"Pine.LNX.4.58.0504212200400.2344@ppc970.osdl.org","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Zach Welch","fromEmail":"zw@superlucidity.net","sentAt":"2005-04-22T09:14:24Z","receivedAt":"2005-04-22T09:14:24Z","isPatch":false,"sender":{"key":"zw@superlucidity.net","avatar":null},"body":"Howdy,\n\nLinus Torvalds wrote:\n> On Thu, 21 Apr 2005, Junio C Hamano wrote: \n>>I am thinking about an alternative way of doing the above by\n>>some modifications to the git core. I think the root of this\n>>problem is that there is no equivalent to GIT_INDEX_FILE and\n>>SHA1_FILE_DIRECTORY that tells the core git where the project\n>>top directory (i.e. the root of the working tree that\n>>corresponds to what $GIT_INDEX_FILE describes) is.\n> \n> I'd _really_ prefer to just try to teach people to work from the \"top\" \n> directory instead.\n\nWould it be okay if that were settable on a per-repository basis? :)\nOr do you have specific subset of operations you want restricted?\n\n>> - A new environment variable GIT_WORKING_TREE points at the\n>> root of the working tree.\n[snip]\n> I really don't like it that much, but to some degree it obviously is\n> exactly what \"--prefix=\" does to checkout-cache. It's basically saying \n> that all normal file operations have to be prefixed with a magic string. \n\nI'm going to script it one way or the other, but the environment route\nallows me to set things up after a fork and before exec in Perl. This\nworks regardless of what git command I'm running, and should work even\nwith ithreads. This ease of use would not be the case with the\n'--prefix' solution, as scripting the commands would requiring passing\narguments to those commands that need/support them at a higher level\nthan is desirable.\n\nAt present, I have implemented Yogi to support being able to run\ncommands from a different working directory than the root of the\nrepository, and that behavior might be per-repository settable\n(someday). If I had my way, I would like to see git support the\nfollowing variables:\n\n GIT_WORKING_DIRECTORY - default to '.'\n GIT_CACHE_DIRECTORTY - default to ${GIT_WORKING_DIRECTORY}/.git\n GIT_OBJECT_DIRECTORY - defaults to ${GIT_CACHE_DIRECTORY}/objects\n\nThe reasoning is simple: One object repository can be shared among\nnumerous working caches, which can be shared among multiple working\ndirectories (e.g. any directories under the project root, but maybe also\nimport/exports, or other magic...). There are two layers of one to many\nrelationships between the three classes of directories, and my scripts\nwant to make use of that flexibility to the hilt.\n\nAlso, do you really think git will only ever have the index file, and\nnot someday possibly other related bits? (You may have said that\nelsewhere, but I missed it.) If that's ever the case, the directory\nvariable is the way to go; scripts can be forward compatible and won't\nrisk accidentally mingling repository data when their scripts have only\nset GIT_INDEX_FILE and not GIT_SOME_OTHER_FILE.\n\nThat said, I think GIT_INDEX_FILE would supplement the above scheme\nnicely, overriding a default of ${GIT_CACHE_DIRECTORY}/index, because of\nuse cases you've described.\n\nCheers,\n\nZach\n"},{"id":"1255","messageId":"20050422103519.GB14565@pasky.ji.cz","threadId":"206","inReplyTo":"7vzmvr72j6.fsf@assigned-by-dhcp.cox.net","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-22T10:35:19Z","receivedAt":"2005-04-22T10:35:19Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Apr 22, 2005 at 08:23:41AM CEST, I got a letter\nwhere Junio C Hamano told me that...\n> >>>>> \"LT\" == Linus Torvalds writes:\n> - Further admit that to support it without core layer help,\n> what Cogito layer needs to do involves quite a lot of \"yuck\"\n> factor.\n\nI actually thought that I would just walk to parent directories at the\ntime of invocation, to find the .git directory, then save that to\n$gitdir and use that to always reference to it, setting also\nGIT_INDEX_FILE etc. I basically just postponed this until I have some\nkind of library or something, and do all this stuff in a single common\ninit routine. I think it should be doable pretty well in Cogito alone,\nbut of course I won't mind if someone does it in git core. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1311","messageId":"Pine.LNX.4.58.0504221147050.2344@ppc970.osdl.org","threadId":"206","inReplyTo":"7vzmvr72j6.fsf@assigned-by-dhcp.cox.net","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-22T19:24:58Z","receivedAt":"2005-04-22T19:24:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 21 Apr 2005, Junio C Hamano wrote:\n> \n> The commands I would want to take paths relative to the user cwd\n> are quite limited; note that I just want these available to the\n> user and I do not care which one, the core or Cogito, groks the\n> cwd relative paths:\n\nI've thought about this, and looked at the sources, and it wouldn't be \nhorrible.\n\nHOWEVER, the more I thought about it, the less sense it made. The fact is, \nyou can do _exactly_ what you are talking about by just wrapping the calls \nin\n\n\t( cd $WORKING_DIR && git-cmd )\n\nwhich simply doesn't have any downsides that I can see. It always does the \nright thing, and it means that the tools will never have to care about \nwhat the base is. Keeping the core tools is important, because if they \nmess up, you're in serious trouble. In contrast, if higher levels mess up, \nyou're not likely to have caused anything irrevocable.\n\nIn fact, I probably shouldn't even have done the \"--prefix=\" stuff for\ncheck-out, since the common \"check out in a new directory\" case (not the\n\"prefix file\" case can be pretty easily emulated with a fairly trivial \nscript, something like\n\n\t#!/bin/sh\n\tCURRENT_DIR=$(pwd)\n\tGIT_INDEX_FILE=${GIT_INDEX_FILE:-$CURRENT_DIR/.git/index}\n\tSHA1_FILE_DIRECTORY=${SHA1_FILE_DIRECTORY:-$CURRENT_DIR/.git/objects}\n\tTARGET=$1\n\tshift 1\n\tmkdir $TARGET && cd $TARGET && checkout-cache \"$@\"\n\nbut since it was (a) very easy to add to that particular program, and (b) \nexporting a while directory is pretty fundamental, I'll just leave that \nstrange special case around.\n\nSo to the core tools, there really _are_ just two special things: the \nindex file, and the place where to find the sha1 objects. The working \ndirectory is really nothing but \"pwd\", which can be trivially changed \nbefore invocation, ie the addition of a new environment variable really \ndoesn't _buy_ anything except for complexity.\n\n\t\tLinus\n"},{"id":"1315","messageId":"7vbr867ecy.fsf@assigned-by-dhcp.cox.net","threadId":"206","inReplyTo":"Pine.LNX.4.58.0504221147050.2344@ppc970.osdl.org","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-22T20:20:29Z","receivedAt":"2005-04-22T20:20:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> ... The fact is, you can do _exactly_ what you are talking\nLT> about by just wrapping the calls in\n\nLT> \t( cd $WORKING_DIR && git-cmd )\n\nLT> which simply doesn't have any downsides that I can see.\n\nAlmost, with a counter-example. Please try this yourself:\n\n $ cd mozilla-sha1\n $ echo '/* garbage */' >>sha1.c\n $ sh -c 'cd .. && show-diff \"$0\" \"$@\"' sha1.c\n $ cd .. && show-diff mozilla-sha1/sha1.c\n\nSome commands that take working tree relative paths do strange\nthings without the path munging I discussed in the original\nmessage (\"$R- prefixing\") if you chdir to the $WORKING_DIR. The\njit-update-cache wrapper I sent in the previous message is an\nexample of how Cogito layer can work it around. It does not\nbreak my \"yuck\" meter but I think it probably makes most people\nbarf ;-). I was trying to make this path munging part easier\nfor the upper layer by making the core aware of WORKING_DIR.\n\nHere is an updated set of commands that needs such path munging:\n\n check-files paths...\n show-diff [-R] [-q] [-s] [-z] [paths...]\n update-cache [--add] [--remove] [--refresh]\n [--cacheinfo mode blob-id] paths...\n checkout-cache [-f] [-a] paths...\n\nThat said, I do not think the above set is too many to warrant a\ncore surgery (I am agreeing with your conclusion here). Unless\nwe also normalize path to support something like:\n\n $ cd mozilla-sha1\n $ echo '/* garbage */' >>cache.h\n $ sh -c 'cd .. && show-diff \"$0\" \"$@\"' ../cache.h\n\nin the core, that is.\n\n"},{"id":"1330","messageId":"Pine.LNX.4.58.0504221503270.2344@ppc970.osdl.org","threadId":"206","inReplyTo":"7vbr867ecy.fsf@assigned-by-dhcp.cox.net","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-22T22:14:16Z","receivedAt":"2005-04-22T22:14:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 22 Apr 2005, Junio C Hamano wrote:\n> \n> Almost, with a counter-example. Please try this yourself:\n\nI agree that what git outputs is always \"based on the archive base\". But \nthat's an independent issue from \"where is the working directory\". That's \nthe issue of \"how do you want me to print out the results\".\n\nTo see just how independent that is, think about how git-pasky (and,\nindeed, standard \"show-diff\") already prints out the results in a\n_different_ base than the working directory _or_ the base. Ie the way we \nalready do\n\n\t--- a/Makefile\n\t+++ b/Makefile\n\t... patch ...\n\nfor a patch to \"Makefile\" in the top-level directory.\n\nIOW, showing pathnames is different from _using_ them. And if you were \nplanning on using the same logic for both, you'd have been making a \nmistake in the first place.\n\nTo _use_ pathnames, you use \"pwd\". To _show_ them, you use some other\nmechanism. You must not mix up those two issues, or you'd always get\n\"show-diff\" wrong.\n\nI actually think that showing the pathnames is up to the wrapper scripts. \nGit core really always just works on the \"canonical\" format.\n\n(And I personally think that \"show-diff\" is really part of the \"wrapper\nscripts\" around git. I wrote it originally just because I needed something\nto verify the index file handling, not because it's \"core\" like the other\nprograms. I do _not_ consider \"show-diff\" to be part of the core git code,\nreally. Same goes for \"git-export\", btw - for the same reasons. It's not\n\"fundamental\").\n\n\t\tLinus\n"},{"id":"1336","messageId":"7v4qdy5tpo.fsf@assigned-by-dhcp.cox.net","threadId":"206","inReplyTo":"Pine.LNX.4.58.0504221503270.2344@ppc970.osdl.org","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-22T22:31:47Z","receivedAt":"2005-04-22T22:31:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> On Fri, 22 Apr 2005, Junio C Hamano wrote:\n>> \n>> Almost, with a counter-example. Please try this yourself:\n\nLT> I agree that what git outputs is always \"based on the archive base\". But \nLT> that's an independent issue from \"where is the working directory\".\n\nI am not talking about output, but the input. I do not mind\n(and I rather prefer) the output is always canonical.\n\n"},{"id":"1338","messageId":"20050422223341.GC21204@pasky.ji.cz","threadId":"206","inReplyTo":"Pine.LNX.4.58.0504221503270.2344@ppc970.osdl.org","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-22T22:33:41Z","receivedAt":"2005-04-22T22:33:41Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Apr 23, 2005 at 12:14:16AM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> (And I personally think that \"show-diff\" is really part of the \"wrapper\n> scripts\" around git. I wrote it originally just because I needed something\n> to verify the index file handling, not because it's \"core\" like the other\n> programs. I do _not_ consider \"show-diff\" to be part of the core git code,\n> really. Same goes for \"git-export\", btw - for the same reasons. It's not\n> \"fundamental\").\n\nNote that Cogito almost actually does not use show-diff anymore.\nI'm doing diff-cache now, since that is what matters to me.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1345","messageId":"Pine.LNX.4.58.0504221544190.2344@ppc970.osdl.org","threadId":"206","inReplyTo":"20050422223341.GC21204@pasky.ji.cz","subject":"Re: \"GIT_INDEX_FILE\" environment variable","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-22T22:55:35Z","receivedAt":"2005-04-22T22:55:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Apr 2005, Petr Baudis wrote:\n> \n> Note that Cogito almost actually does not use show-diff anymore.\n> I'm doing diff-cache now, since that is what matters to me.\n\nIndeed. \"diff-tree\" (between releases) and \"diff-cache\" (between a\nrelease and the current state) are clearly much more fundamental\noperations.\n\nAlso, they have absolutely zero policy, and they're designed to be used\nwith the same scripting engines (ie hopefully you can use just one tool to\nshow the output of either in whatever format you want).\n\nThey show you what the canonical names and associated information is, and\nthat's it. What you _do_ with them ends up being outside the scope of git,\nexactly like it should be. Details like \"what format of diff\" to produce \nshould be left to the tools around it.\n\nIn contrast, \"show-diff\" was _literally_ written to check what the\ndifference between the \"real\" file and a \"sha1\" file was, back when I\ncouldn't write the sha1 files correctly (ie I corrupted anything that \ndidn't fit in the first \"[un]compression block\", and then calling \"diff\" \nto show the difference between the original and the regenerated data was \nvery important).\n\nSo \"show-diff\" just kind of expanded from an early debugging tool to\nsomething that _almost_ looks like a real tool. But it's absolutely the\nright thing to use \"diff-tree\" and \"diff-cache\" instead.\n\n\t\t\tLinus\n"}]}