update-cache ./test.c

update-cache ./test.c

[Lennert Buytenhek]

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

Re: update-cache ./test.c

[Thomas Glanzmann]

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

Re: update-cache ./test.c

[Lennert Buytenhek]

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

Re: update-cache ./test.c

[Lennert Buytenhek]

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");

Re: update-cache ./test.c

[Thomas Glanzmann]

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

Re: update-cache ./test.c

[Junio C Hamano]

>>>>> "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.

Re: update-cache ./test.c

[David Greaves]

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:
<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...