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

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
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

Reply via email to