quoted
quoted
quoted
quoted
"PB" == Petr Baudis [off-list ref] writes:
PB> Yes. My point is that sometimes the Cogito commands have
PB> directory-specific functionality even when called without any arguments.
PB> $ pwd
PB> /usr/src/linux
PB> $ date >>README
PB> $ cd fs
PB> $ date >>Makefile
PB> $ cg-commit
PB> will commit only the fs/Makefile change.
Ah, thanks. That what I missed.
On Wed, 18 May 2005, Junio C Hamano wrote:
PB> Yes. My point is that sometimes the Cogito commands have
PB> directory-specific functionality even when called without any arguments.
PB> $ pwd
PB> /usr/src/linux
PB> $ date >>README
PB> $ cd fs
PB> $ date >>Makefile
PB> $ cg-commit
PB> will commit only the fs/Makefile change.
Ah, thanks. That what I missed.
Note that if git-run-with-user-path just has some way to tell what the
relative pathname of the original program was (say $DEF_SUBDIRECTORY),
this could still fairly easily be handled: having the cg-Xcommit program
say "if there are no arguments, we default to $DEF_SUBDIRECTORY" rather
than "with no arguments, default to '.'".
I don't personally much care, since this is all porcelain, but basically I
don't think these things are in any way mutually incompatible, and I do
believe that git-run-with-user-path _could_ be a good way to abstract out
the "where the heck in the tree am I?" issues.
Linus
quoted
quoted
quoted
quoted
"LT" == Linus Torvalds [off-list ref] writes:
LT> ... I do believe that git-run-with-user-path _could_ be a
LT> good way to abstract out the "where the heck in the tree am
LT> I?" issues.
Yes, I am still in search of a good way to abstract that issue
out and I myself is not yet convinced that the command in its
current form _is_ a good enough way yet.
What I am most unhappy about with it lies elsewhere, though.
There needs to be a better way to tell it how the underlying
command handles non-paths arguments, so that I can just say
git-run-with-user-path <some option spec for the command> \
command arg1 arg2 arg3 ...
and if arg1 through argO is non-path options then have it
canonicalize and filter only starting from argO+1. That would
alleviate one issue I have with the current implementation.