Re: Finding the repository
On Thu, Oct 24, 2013 at 9:46 AM, Duy Nguyen wrote: > On Thu, Oct 24, 2013 at 2:49 PM, Perry Hutchison > wrote: >> Duy Nguyen wrote: >> >>> ... it's not easy to determine ambiguity here, especially when the >>> repo finding code does not know anything about "bar/barz.c" (is it >>> a pathname or an argument to an option?). ... >>> There are more cases to consider, like what if you do >>> "git rm bar/baz.c and rab/zab.c" where bar and rab are >>> two different repositories.. >> >> So we remove baz.c from bar and zab.c from rab. It's not clear >> to me that there's anything wrong with that -- it's exactly what >> I would expect to have happen (and also what the hackish script >> I posted will do). > > For "git rm", maybe. Many other commands need repo information and it > would not make sense to have paths from two different repositories. > For example, commit, rev-list or log. And it may break more things as > most of current commands are designed to work on one repo from a to z. > Some may support multi-repo operations if they're part of submodule > support. I've done some preliminary work on extending this sort of behavior to submodule commands. For example, git grep --recurse-submodules foo which would look in the current project path and also any submodules encountered. This usage also begs for this extension: git grep --recurse-submodules foo path/to/sub/bar.c Where 'path/to/sub' is a submodule, and therefore a foreign git repo to this one. Solving this is a little bit easier than your case because git is already running inside a repo. Extending the reach to submodules only requires more odb's than our first one to be considered. Along the way, I have considered your case, but I haven't focused on it. Lately I haven't had time to focus on my case either, though. :-\ Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Finding the repository
On Thu, Oct 24, 2013 at 2:49 PM, Perry Hutchison wrote: > Duy Nguyen wrote: > >> ... it's not easy to determine ambiguity here, especially when the >> repo finding code does not know anything about "bar/barz.c" (is it >> a pathname or an argument to an option?). > > IOW, the code that finds the repository is called "too early"? Yes. First it tries to find and setup the repository. Read per-config repo file and add aliases to the database if any. Resolve alias. Run the actual command. Then the command parses the command line. > One way to solve that to that would be to proceed, even if the > repository has to be left as "unknown" until it actually needs to > be consulted -- by which time the subcommand would presumably have > parsed all of the options and pathnames and so would know which is > which. Then, use the pathname(s) to identify the repository(ies). > Yes, if there's more than one repository involved, the subcommand > has to do a "for each repository" loop. The code to do all this > could go in a module shared among the subcommands. That breaks the normal process I described above (i.e. lots of code changes). People would scream at the code changes for a minor convenience. We could refactor the parsing code so that the startup code could do a "dry-run" command line parsing pass first. May work for the majority of commands that do not need special parsing callbacks. Even then we still need more changes because git does not work well if cwd is outside the worktree. Paths like 'bar/baz.c" need to cut "bar/" out. Then if "baz.c" is to printed out again, "bar/" needs to be prepended back.. >> There are more cases to consider, like what if you do >> "git rm bar/baz.c and rab/zab.c" where bar and rab are >> two different repositories.. > > So we remove baz.c from bar and zab.c from rab. It's not clear > to me that there's anything wrong with that -- it's exactly what > I would expect to have happen (and also what the hackish script > I posted will do). For "git rm", maybe. Many other commands need repo information and it would not make sense to have paths from two different repositories. For example, commit, rev-list or log. And it may break more things as most of current commands are designed to work on one repo from a to z. Some may support multi-repo operations if they're part of submodule support. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Finding the repository
Duy Nguyen wrote: > ... it's not easy to determine ambiguity here, especially when the > repo finding code does not know anything about "bar/barz.c" (is it > a pathname or an argument to an option?). IOW, the code that finds the repository is called "too early"? One way to solve that to that would be to proceed, even if the repository has to be left as "unknown" until it actually needs to be consulted -- by which time the subcommand would presumably have parsed all of the options and pathnames and so would know which is which. Then, use the pathname(s) to identify the repository(ies). Yes, if there's more than one repository involved, the subcommand has to do a "for each repository" loop. The code to do all this could go in a module shared among the subcommands. > There are more cases to consider, like what if you do > "git rm bar/baz.c and rab/zab.c" where bar and rab are > two different repositories.. So we remove baz.c from bar and zab.c from rab. It's not clear to me that there's anything wrong with that -- it's exactly what I would expect to have happen (and also what the hackish script I posted will do). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Finding the repository
On Wed, Oct 23, 2013 at 2:52 PM, Perry Hutchison wrote: > At least in version 1.7.0.4, it seems git does not like being run > from outside the repository, even if the file(s) being operated > on are inside the repository, unless it is given a pointer to the > repository via the --git-dir= option or the GIT_DIR enironment > variable. > > For example, suppose /foo/bar is a local repository and baz.c is a > file in the outermost directory that I want to remove. This works: > > $ cd /foo/bar > $ git rm baz.c > > but this, which intuitively should mean exactly the same thing, > fails: > > $ cd /foo > $ git rm bar/baz.c > fatal: Not a git repository (or any of the parent directories): .git I share your pain. In my case I hate to go inside a directory just to grep something. In my opinion git should be flexible and work at least in unambiguous cases. But it's not easy to determine ambiguity here, especially when the repo finding code does not know anything about "bar/barz.c" (is it a pathname or an argument to an option?). There are more cases to consider, like what if you do "git rm bar/baz.c and rab/zab.c" where bar and rab are two different repositories.. And the setup code is not exactly easy to add these stuff in.. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Finding the repository
At least in version 1.7.0.4, it seems git does not like being run from outside the repository, even if the file(s) being operated on are inside the repository, unless it is given a pointer to the repository via the --git-dir= option or the GIT_DIR enironment variable. For example, suppose /foo/bar is a local repository and baz.c is a file in the outermost directory that I want to remove. This works: $ cd /foo/bar $ git rm baz.c but this, which intuitively should mean exactly the same thing, fails: $ cd /foo $ git rm bar/baz.c fatal: Not a git repository (or any of the parent directories): .git I've written a wrapper script that solves this problem, but it is more an illustration or proof of concept than a real "solution" -- the command line parsing may well be imperfect, and it would be semantically incorrect in such cases as committing multiple (individually specified) files: it would do a separate commit of each pathname rather than a single commit of all pathnames. Has anyone considered enhancing the automatic repository search in git itself to look in the directory where the specified file(s) is/are located, as a last resort before failing? (Yes, this does present the potential for operating on multiple repositories with a single invocation of git; would that be a bad thing?) #!/usr/local/bin/bash # smarter git: if the current directory has no .git subdirectory # (i.e. is not in a repository), try running git in the directory # where each file is located instead of in the current directory. [ "$1" == "--version" -o "$1" == "--help" -o "$1" == "--exec-path" \ -o "x$GIT_DIR" != "x" -o -d .git ] && exec git "$@" # Set defaults flags="" dirSet=0 # Collect flag params while [[ "$1" == -?* ]] ; do case "$1" in --git-dir=* ) dirSet=1 ;; * ) esac flags="$flags $1" shift done [ "$dirSet" == "1" ] && exec git $flags "$@" # next word must be the command gitCmd="$1" shift # remaining words must be pathnames for f in "$@" do ( cd $(dirname "$f") && git $flags $gitCmd $(basename "$f") ) done -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
