On Thu, Oct 24, 2013 at 2:49 PM, Perry Hutchison <per...@pluto.rain.com> wrote: > Duy Nguyen <pclo...@gmail.com> 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
