threads / discuss / 414

update-cache ./test.c

Subject: update-cache ./test.c

## tl;dr

7 messages between May 1, 2005 and May 1, 2005.

replies: 6people: 4as markdown or json

Lennert Buytenhek· May 1, 2005, 08:41 UTC · lore
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· May 1, 2005, 08:47 UTC · re: Lennert Buytenhek · lore

Re: update-cache ./test.c

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· May 1, 2005, 08:54 UTC · re: Thomas Glanzmann · lore

Re: update-cache ./test.c

On Sun, May 01, 2005 at 10:47:10AM +0200, Thomas Glanzmann wrote:
> Hello,
Hi,
Show 15 quoted lines
> > 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· May 1, 2005, 08:59 UTC · re: Lennert Buytenhek · lore

Re: update-cache ./test.c

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· May 1, 2005, 09:04 UTC · re: Lennert Buytenhek · lore

Re: update-cache ./test.c

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
Junio C Hamano· May 1, 2005, 10:31 UTC · re: Lennert Buytenhek · lore

Re: update-cache ./test.c

>>>>> "LB" == Lennert Buytenhek <buytenh@wantstofly.org> 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 <http://members.cox.net/junkio/> I've been using it to manage the patches I feed Linus on the plumbing side.

David Greaves· May 1, 2005, 09:43 UTC · re: Lennert Buytenhek · lore

Re: update-cache ./test.c

Lennert Buytenhek wrote:
Show 15 quoted lines
>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:
<file>
    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...

← back to recent threads