Re: update-cache ./test.c

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.