# update-cache ./test.c 7 messages from 2005-05-01 to 2005-05-01. Participants: Lennert Buytenhek, Thomas Glanzmann, David Greaves, Junio C Hamano. Thread: https://gitlist.dev/t/414 ## Lennert Buytenhek, 2005-05-01 08:41 Subject: update-cache ./test.c Message-ID: <20050501084145.GA30692@xi.wantstofly.org> URL: https://gitlist.dev/e/20050501084145.GA30692%40xi.wantstofly.org ``` Hi, update-cache seems to ignore paths containing path components starting with a dot: pi% update-cache --add ./test.c Ignoring path ./test.c pi% update-cache --add test.c pi% This is slightly annoying as 'find -type f | xargs update-cache --add' doesn't work because of this. ('find * -type f | ...` does.) Instead of ignoring the file, can we just strip off the leading "./" ? --L ``` ## Thomas Glanzmann, 2005-05-01 08:47 Subject: Re: update-cache ./test.c Message-ID: <20050501084710.GJ26663@cip.informatik.uni-erlangen.de> URL: https://gitlist.dev/e/20050501084710.GJ26663%40cip.informatik.uni-erlangen.de In-Reply-To: <20050501084145.GA30692@xi.wantstofly.org> ``` Hello, > update-cache seems to ignore paths containing path components > starting with a dot: > pi% update-cache --add ./test.c > Ignoring path ./test.c > pi% update-cache --add test.c > pi% > This is slightly annoying as 'find -type f | xargs update-cache --add' > doesn't work because of this. ('find * -type f | ...` does.) Instead > of ignoring the file, can we just strip off the leading "./" ? just use a shell script to obtain that: find -type f | sed "s#^./##" | xargs update-cache --add Greetings, Thomas ``` ## Lennert Buytenhek, 2005-05-01 08:54 Subject: Re: update-cache ./test.c Message-ID: <20050501085427.GB30692@xi.wantstofly.org> URL: https://gitlist.dev/e/20050501085427.GB30692%40xi.wantstofly.org In-Reply-To: <20050501084710.GJ26663@cip.informatik.uni-erlangen.de> ``` On Sun, May 01, 2005 at 10:47:10AM +0200, Thomas Glanzmann wrote: > Hello, Hi, > > update-cache seems to ignore paths containing path components > > starting with a dot: > > > pi% update-cache --add ./test.c > > Ignoring path ./test.c > > pi% update-cache --add test.c > > pi% > > > This is slightly annoying as 'find -type f | xargs update-cache --add' > > doesn't work because of this. ('find * -type f | ...` does.) Instead > > of ignoring the file, can we just strip off the leading "./" ? > > just use a shell script to obtain that: > > find -type f | sed "s#^./##" | xargs update-cache --add This also works: find * -type f | xargs update-cache --add But that wasn't quite the point :) It makes sense that update-cache doesn't like ambiguous path names, but it's easier for update-cache to detect and strip "^./" than for me to remember to type sed "s#^./##" every time. --L ``` ## Lennert Buytenhek, 2005-05-01 08:59 Subject: Re: update-cache ./test.c Message-ID: <20050501085922.GC30692@xi.wantstofly.org> URL: https://gitlist.dev/e/20050501085922.GC30692%40xi.wantstofly.org In-Reply-To: <20050501085427.GB30692@xi.wantstofly.org> ``` On Sun, May 01, 2005 at 10:54:27AM +0200, Lennert Buytenhek wrote: > But that wasn't quite the point :) It makes sense that update-cache > doesn't like ambiguous path names, but it's easier for update-cache to > detect and strip "^./" than for me to remember to type sed "s#^./##" > every time. Something like this: --- git/update-cache.c.orig 2005-05-01 10:56:17.859313581 +0200 +++ git/update-cache.c 2005-05-01 10:57:31.634897508 +0200 @@ -328,6 +328,7 @@ for (i = 1 ; i < argc; i++) { char *path = argv[i]; + char *_path; if (allow_options && *path == '-') { if (!strcmp(path, "--")) { @@ -358,12 +359,15 @@ } die("unknown option %s", path); } - if (!verify_path(path)) { + _path = path; + if (!strncmp(_path, "./", 2)) + _path += 2; + if (!verify_path(_path)) { fprintf(stderr, "Ignoring path %s\n", argv[i]); continue; } - if (add_file_to_cache(path)) - die("Unable to add %s to database", path); + if (add_file_to_cache(_path)) + die("Unable to add %s to database", _path); } if (write_cache(newfd, active_cache, active_nr) || rename(lockfile, indexfile)) die("Unable to write new cachefile"); ``` ## Thomas Glanzmann, 2005-05-01 09:04 Subject: Re: update-cache ./test.c Message-ID: <20050501090437.GK26663@cip.informatik.uni-erlangen.de> URL: https://gitlist.dev/e/20050501090437.GK26663%40cip.informatik.uni-erlangen.de In-Reply-To: <20050501085922.GC30692@xi.wantstofly.org> ``` Hello, > --- git/update-cache.c.orig 2005-05-01 10:56:17.859313581 +0200 > +++ git/update-cache.c 2005-05-01 10:57:31.634897508 +0200 > @@ -328,6 +328,7 @@ > for (i = 1 ; i < argc; i++) { > char *path = argv[i]; > + char *_path; I think there is no need to introduce an extra variable. Just increase path by two. I knew that it is easy to fix in the code, but I think the 'logic' should go into the frontend not in the backend. But this one is really easy to fix. Maybe regenerate a patch and sign it off, maybe it will be included. Greetings, Thomas ``` ## David Greaves, 2005-05-01 09:43 Subject: Re: update-cache ./test.c Message-ID: <4274A4C6.3000400@dgreaves.com> URL: https://gitlist.dev/e/4274A4C6.3000400%40dgreaves.com In-Reply-To: <20050501084145.GA30692@xi.wantstofly.org> ``` Lennert Buytenhek wrote: >Hi, > >update-cache seems to ignore paths containing path components >starting with a dot: > > pi% update-cache --add ./test.c > Ignoring path ./test.c > pi% update-cache --add test.c > pi% > >This is slightly annoying as 'find -type f | xargs update-cache --add' >doesn't work because of this. ('find * -type f | ...` does.) Instead >of ignoring the file, can we just strip off the leading "./" > > This is documented behaviour: Files to act on. Note that files begining with '.' are discarded. This includes "./file" and "dir/./file". If you don't want this, then use cleaner names. The same applies to directories ending '/' and paths with '//' "Where?" you ask... Well, Linus hasn't accepted the docs for some reason - you have to search the archives... Sorry about that... David PS Changing this behaviour was discussed and dismissed for the core tools. If the problem appears in Cogito however, then it's worth patching... ``` ## Junio C Hamano, 2005-05-01 10:31 Subject: Re: update-cache ./test.c Message-ID: <7v64y3z18w.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v64y3z18w.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050501085922.GC30692@xi.wantstofly.org> ``` >>>>> "LB" == Lennert Buytenhek writes: LB> Something like this: LB> --- git/update-cache.c.orig 2005-05-01 10:56:17.859313581 +0200 LB> +++ git/update-cache.c 2005-05-01 10:57:31.634897508 +0200 LB> @@ -328,6 +328,7 @@ LB> - if (!verify_path(path)) { LB> + _path = path; LB> + if (!strncmp(_path, "./", 2)) LB> + _path += 2; LB> + if (!verify_path(_path)) { Once you start doing ./ specially, you would be tempted to handle foo/../bar/../../baz, which would lead to complexity Linus did not want in the Core GIT layer. Please do not pursue this path again. I once advocated that the path we get from the user should be treated relative to the working directory on the filesystem and not relative to the cache entry root as the current Core GIT layer does (see archive). With some clever scripting this inconvenience can be hidden by the Porcelain layer without much difficulty [*1*] and that was the reason behind the decision by Linus to keep paths Plumbing layer gets relative to the cache. I do not know Cogito already can do this, but you should be able to do something like: $ cd linux-2.6 $ ls -a ./ ../ .git/ fs/ mm/ Makefile ... $ cd fs $ xx-update-cache Makefile ../Makefile ext3/Makefile $ xx-diff-files Makefile ../Makefile ext3/Makefile where xx-* are what the Porcelain layer would provide the end user with. [Footnotes] *1* (PLUG) An implementation of my little SCM on top of GIT is found at I've been using it to manage the patches I feed Linus on the plumbing side. ```