On Sat, May 17, 2014 at 11:31 PM, Pasha Bolokhov
pasha.bolok...@gmail.com wrote:
Now if you guys don't see anything against this, I would shoot out a
patch?
If you have written the patch already, I see no harm in sending it
here. I'm concerned about the perfomance impact on this code,
Hi again
I've come up with a fix for this. It's just two and a half lines,
and required more studying the code than typing.
A lot of path-processing work has been implemented in abspath.c and
dir.c, including the symlinks and checking whether one path is a
subdirectory of another. I
Hi,
I've looked more attentively, here are my observations and the
resulting suggestions:
- Suggest only to check *string-wise* the given path against
$GIT_DIR. Both or one of them may be relative paths (but comparison
best be performed when converted to absolute paths). That's the only
On Thu, May 1, 2014 at 4:35 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Now I know, the '--git-dir' option may usually be meant to use
when the repository is somewhere outside of the work tree, and such a
problem would not arise. And even if it is inside, sure enough, you
can add this
Hi Jonathan
Thanks for the answers
I think it's more that it never came up. Excluding the current
$GIT_DIR from what git add can add (on top of the current rule of
excluding all instances of .git) seems like a sensible change,
assuming it can be done without hurting the code too much.
Hi
It turns out Git treats the directory '.git' differently enough
from everything else. That may be ok, but here's one place where I
encountered an unpleasant (and imho unexpected) behaviour:
if you supply a different repository base name, say, '.git_new',
by either setting
Hi Pavel,
Pasha Bolokhov wrote:
It turns out Git treats the directory '.git' differently enough
from everything else. That may be ok,
Yeah, it's intended.
[...]
if you supply a different repository base name, say, '.git_new',
by either setting GIT_DIR or using the '--git-dir'
7 matches
Mail list logo