John Keeping <john@xxxxxxxxxxxxx> writes: > Yes (ish), the intended usage is something like this: > > prefix=$(git rev-parse --show-prefix) > cd_to_toplevel > ... parse options here ... > # Convert remaining arguments (filenames) into top-level paths: > eval "set $(git rev-parse --prefix "$prefix" --sq -- "$@")" > > The "ish" is that my current implementation introduced a new variable > instead of simply resetting the existing "prefix" variable, which I > assume is what you mean. This is very sensible. > That is probably simpler than my > implementation, but loses the ability to be at an intermediate level, > for example: > > cd Documentation/ > eval "set $(git rev-parse --prefix technical/ --sq -- api-strbuf.txt)" I am not sure in what situation it makes sense to do this. Where does "technical/" come from? For a script that wants to work from a subdirectory, end-user input would come in the form relative to the current directory, i.e. "Documentation/" from the top-level, so... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html