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
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 r
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 wo
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 o
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
5 matches
Mail list logo