{"thread":{"id":"414","subject":"update-cache ./test.c","startedAt":"2005-05-01T08:41:45Z","lastAt":"2005-05-01T10:31:11Z","messageCount":7,"participants":["Lennert Buytenhek","Thomas Glanzmann","David Greaves","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2281","messageId":"20050501084145.GA30692@xi.wantstofly.org","threadId":"414","inReplyTo":null,"subject":"update-cache ./test.c","fromName":"Lennert Buytenhek","fromEmail":"buytenh@wantstofly.org","sentAt":"2005-05-01T08:41:45Z","receivedAt":"2005-05-01T08:41:45Z","isPatch":false,"sender":{"key":"buytenh@wantstofly.org","avatar":null},"body":"Hi,\n\nupdate-cache seems to ignore paths containing path components\nstarting with a dot:\n\n\tpi% update-cache --add ./test.c\n\tIgnoring path ./test.c\n\tpi% update-cache --add test.c\n\tpi%\n\nThis is slightly annoying as 'find -type f | xargs update-cache --add'\ndoesn't work because of this.  ('find * -type f | ...` does.)  Instead\nof ignoring the file, can we just strip off the leading \"./\" ?\n\n\n--L\n"},{"id":"2282","messageId":"20050501084710.GJ26663@cip.informatik.uni-erlangen.de","threadId":"414","inReplyTo":"20050501084145.GA30692@xi.wantstofly.org","subject":"Re: update-cache ./test.c","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-05-01T08:47:10Z","receivedAt":"2005-05-01T08:47:10Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> update-cache seems to ignore paths containing path components\n> starting with a dot:\n\n> \tpi% update-cache --add ./test.c\n> \tIgnoring path ./test.c\n> \tpi% update-cache --add test.c\n> \tpi%\n\n> This is slightly annoying as 'find -type f | xargs update-cache --add'\n> doesn't work because of this.  ('find * -type f | ...` does.)  Instead\n> of ignoring the file, can we just strip off the leading \"./\" ?\n\njust use a shell script to obtain that:\n\nfind -type f | sed \"s#^./##\" | xargs update-cache --add\n\nGreetings,\n\tThomas\n"},{"id":"2283","messageId":"20050501085427.GB30692@xi.wantstofly.org","threadId":"414","inReplyTo":"20050501084710.GJ26663@cip.informatik.uni-erlangen.de","subject":"Re: update-cache ./test.c","fromName":"Lennert Buytenhek","fromEmail":"buytenh@wantstofly.org","sentAt":"2005-05-01T08:54:27Z","receivedAt":"2005-05-01T08:54:27Z","isPatch":false,"sender":{"key":"buytenh@wantstofly.org","avatar":null},"body":"On Sun, May 01, 2005 at 10:47:10AM +0200, Thomas Glanzmann wrote:\n\n> Hello,\n\nHi,\n\n\n> > update-cache seems to ignore paths containing path components\n> > starting with a dot:\n> \n> > \tpi% update-cache --add ./test.c\n> > \tIgnoring path ./test.c\n> > \tpi% update-cache --add test.c\n> > \tpi%\n> \n> > This is slightly annoying as 'find -type f | xargs update-cache --add'\n> > doesn't work because of this.  ('find * -type f | ...` does.)  Instead\n> > of ignoring the file, can we just strip off the leading \"./\" ?\n> \n> just use a shell script to obtain that:\n> \n> find -type f | sed \"s#^./##\" | xargs update-cache --add\n\nThis also works:\n\n\tfind * -type f | xargs update-cache --add\n\nBut that wasn't quite the point :)  It makes sense that update-cache\ndoesn't like ambiguous path names, but it's easier for update-cache to\ndetect and strip \"^./\" than for me to remember to type sed \"s#^./##\"\nevery time.\n\n\n--L\n"},{"id":"2284","messageId":"20050501085922.GC30692@xi.wantstofly.org","threadId":"414","inReplyTo":"20050501085427.GB30692@xi.wantstofly.org","subject":"Re: update-cache ./test.c","fromName":"Lennert Buytenhek","fromEmail":"buytenh@wantstofly.org","sentAt":"2005-05-01T08:59:22Z","receivedAt":"2005-05-01T08:59:22Z","isPatch":false,"sender":{"key":"buytenh@wantstofly.org","avatar":null},"body":"On Sun, May 01, 2005 at 10:54:27AM +0200, Lennert Buytenhek wrote:\n\n> But that wasn't quite the point :)  It makes sense that update-cache\n> doesn't like ambiguous path names, but it's easier for update-cache to\n> detect and strip \"^./\" than for me to remember to type sed \"s#^./##\"\n> every time.\n\nSomething like this:\n\n--- git/update-cache.c.orig\t2005-05-01 10:56:17.859313581 +0200\n+++ git/update-cache.c\t2005-05-01 10:57:31.634897508 +0200\n@@ -328,6 +328,7 @@\n \n \tfor (i = 1 ; i < argc; i++) {\n \t\tchar *path = argv[i];\n+\t\tchar *_path;\n \n \t\tif (allow_options && *path == '-') {\n \t\t\tif (!strcmp(path, \"--\")) {\n@@ -358,12 +359,15 @@\n \t\t\t}\n \t\t\tdie(\"unknown option %s\", path);\n \t\t}\n-\t\tif (!verify_path(path)) {\n+\t\t_path = path;\n+\t\tif (!strncmp(_path, \"./\", 2))\n+\t\t\t_path += 2;\n+\t\tif (!verify_path(_path)) {\n \t\t\tfprintf(stderr, \"Ignoring path %s\\n\", argv[i]);\n \t\t\tcontinue;\n \t\t}\n-\t\tif (add_file_to_cache(path))\n-\t\t\tdie(\"Unable to add %s to database\", path);\n+\t\tif (add_file_to_cache(_path))\n+\t\t\tdie(\"Unable to add %s to database\", _path);\n \t}\n \tif (write_cache(newfd, active_cache, active_nr) || rename(lockfile, indexfile))\n \t\tdie(\"Unable to write new cachefile\");\n\n\n"},{"id":"2285","messageId":"20050501090437.GK26663@cip.informatik.uni-erlangen.de","threadId":"414","inReplyTo":"20050501085922.GC30692@xi.wantstofly.org","subject":"Re: update-cache ./test.c","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-05-01T09:04:37Z","receivedAt":"2005-05-01T09:04:37Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> --- git/update-cache.c.orig\t2005-05-01 10:56:17.859313581 +0200\n> +++ git/update-cache.c\t2005-05-01 10:57:31.634897508 +0200\n> @@ -328,6 +328,7 @@\n\n>  \tfor (i = 1 ; i < argc; i++) {\n>  \t\tchar *path = argv[i];\n> +\t\tchar *_path;\n\nI think there is no need to introduce an extra variable. Just increase\npath by two. I knew that it is easy to fix in the code, but I think the\n'logic' should go into the frontend not in the backend. But this one is\nreally easy to fix. Maybe regenerate a patch and sign it off, maybe it\nwill be included.\n\nGreetings,\n\tThomas\n"},{"id":"2287","messageId":"4274A4C6.3000400@dgreaves.com","threadId":"414","inReplyTo":"20050501084145.GA30692@xi.wantstofly.org","subject":"Re: update-cache ./test.c","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-05-01T09:43:34Z","receivedAt":"2005-05-01T09:43:34Z","isPatch":false,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Lennert Buytenhek wrote:\n\n>Hi,\n>\n>update-cache seems to ignore paths containing path components\n>starting with a dot:\n>\n>\tpi% update-cache --add ./test.c\n>\tIgnoring path ./test.c\n>\tpi% update-cache --add test.c\n>\tpi%\n>\n>This is slightly annoying as 'find -type f | xargs update-cache --add'\n>doesn't work because of this.  ('find * -type f | ...` does.)  Instead\n>of ignoring the file, can we just strip off the leading \"./\"\n>  \n>\n\nThis is documented behaviour:\n<file>\n    Files to act on.\n    Note that files begining with '.' are discarded. This includes\n    \"./file\" and \"dir/./file\". If you don't want this, then use   \n    cleaner names.\n    The same applies to directories ending '/' and paths with '//'\n\n\n\"Where?\" you ask...\n\nWell, Linus hasn't accepted the docs for some reason - you have to\nsearch the archives...\n\nSorry about that...\n\nDavid\nPS Changing this behaviour was discussed and dismissed for the core tools.\nIf the problem appears in Cogito however, then it's worth patching...\n\n\n"},{"id":"2288","messageId":"7v64y3z18w.fsf@assigned-by-dhcp.cox.net","threadId":"414","inReplyTo":"20050501085922.GC30692@xi.wantstofly.org","subject":"Re: update-cache ./test.c","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-01T10:31:11Z","receivedAt":"2005-05-01T10:31:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LB\" == Lennert Buytenhek <buytenh@wantstofly.org> writes:\n\nLB> Something like this:\n\nLB> --- git/update-cache.c.orig\t2005-05-01 10:56:17.859313581 +0200\nLB> +++ git/update-cache.c\t2005-05-01 10:57:31.634897508 +0200\nLB> @@ -328,6 +328,7 @@\nLB> -\t\tif (!verify_path(path)) {\nLB> +\t\t_path = path;\nLB> +\t\tif (!strncmp(_path, \"./\", 2))\nLB> +\t\t\t_path += 2;\nLB> +\t\tif (!verify_path(_path)) {\n\nOnce you start doing ./ specially, you would be tempted to\nhandle foo/../bar/../../baz, which would lead to complexity\nLinus did not want in the Core GIT layer.  Please do not pursue\nthis path again.\n\nI once advocated that the path we get from the user should be\ntreated relative to the working directory on the filesystem and\nnot relative to the cache entry root as the current Core GIT\nlayer does (see archive).  With some clever scripting this\ninconvenience can be hidden by the Porcelain layer without much\ndifficulty [*1*] and that was the reason behind the decision by\nLinus to keep paths Plumbing layer gets relative to the cache.\n\nI do not know Cogito already can do this, but you should be able\nto do something like:\n\n    $ cd linux-2.6\n    $ ls -a\n    ./  ../  .git/ fs/ mm/ Makefile ...\n    $ cd fs\n    $ xx-update-cache Makefile ../Makefile ext3/Makefile\n    $ xx-diff-files Makefile ../Makefile ext3/Makefile\n\nwhere xx-* are what the Porcelain layer would provide the end\nuser with.\n\n\n[Footnotes]\n*1* (PLUG) An implementation of my little SCM on top of GIT is\nfound at <http://members.cox.net/junkio/>   I've been using it\nto manage the patches I feed Linus on the plumbing side.\n\n\n"}]}