Re: update-cache ./test.c

quoted

quoted

quoted

quoted

"LB" == Lennert Buytenhek [off-list ref] 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.