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 GIT_DIR or using the '--git-dir' option, Git 'add'
will not make any exception for it and think of it as a new (weird)
directory. In particular, 'git add -A' with a consequent commit will
add this repository into itself with all its guts.

    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 '.git_new' to the ignores or excludes. But is this really
what you expect?

    I come forward to offer my own will to fix this behaviour (which
is rooted in 'dir.c'). However there are uncertainties, and I'm asking
for an opinion.

    Apparently, the assumption that the repository is in '.git' has
propagated far enough. In particular, every '.git' within the working
tree seems to be ignored for the purpose of staging. Is this a
consistent behaviour? And, perhaps there are a million more places
where the name '.git' is hard-coded, and it might be reasonable to
question the legitimacy for that. Or, in contrast, to what degree or
depth (in the source code) does one *expect* Git to rename all its
hard-coded '.git's into '.gut's when a "GIT_DIR=.gut" is supplied?

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