Re: [PATCH] Support "core.excludesfile = ~/.gitignore"

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] Support "core.excludesfile = ~/.gitignore"

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:13

Jeff King [off-list ref] writes:
quoted
Perhaps we should rid of the worktree that is separate and floats
unrelated to where $GIT_DIR is.
I assumed people were actually using it, which is why it was
implemented.
Judging from the occasional "I tried core.worktree but it does not work in
this and that situations" I see here and on #git, my impression is that
new people try it, saying "git is cool -- unlike cvs that sprinkles those
ugly CVS directories all over the place, it only contaminates my work tree
with a single directory '.git' and nothing else.  Ah, wait --- what's this
core.worktree thing?  Can I get rid of that last one as well?  That sounds
even cooler".

IOW, I do not think it is really _needed_ per-se as a feature, but it was
done because it was thought to be doable, which unfortunately turned out
to involve hair-pulling complexity that the two attempts that led to the
current code still haven't resolved.

I really wish we do not have to worry about that anymore.

limiting relationship of git dir and worktree (was Re: [PATCH] Support "core.excludesfile = ~/.gitignore")

From: Jeff King <hidden>
Date: 2016-06-15 22:45:13

On Sun, Aug 24, 2008 at 04:40:21PM -0700, Junio C Hamano wrote:
Judging from the occasional "I tried core.worktree but it does not work in
this and that situations" I see here and on #git, my impression is that
new people try it, saying "git is cool -- unlike cvs that sprinkles those
ugly CVS directories all over the place, it only contaminates my work tree
with a single directory '.git' and nothing else.  Ah, wait --- what's this
core.worktree thing?  Can I get rid of that last one as well?  That sounds
even cooler".

IOW, I do not think it is really _needed_ per-se as a feature, but it was
done because it was thought to be doable, which unfortunately turned out
to involve hair-pulling complexity that the two attempts that led to the
current code still haven't resolved.

I really wish we do not have to worry about that anymore.
Well, as a non-user of this feature, I certainly have no argument
against taking it out. Maybe the subject line will pull some other
people into the discussion.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help