From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: felix@debuggable.com, Duy Nguyen <pclouds@gmail.com>,
"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] pathspec: remove check_path_for_gitlink
Date: Fri, 06 May 2016 13:09:55 -0700 [thread overview]
Message-ID: <xmqqd1oz2bjg.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kaJYngaZfhx060C06J57aDqPJfdMD8xzK4dW4nvvktMLQ@mail.gmail.com> (Stefan Beller's message of "Fri, 6 May 2016 12:18:38 -0700")
Stefan Beller <sbeller@google.com> writes:
> It was a bug, but now people in the outside world consider it a feature.
> Search for "Git fake submodules" and you'll find a few users who use this
> technique successfully.
>
> I do not think fixing this bug would do good. So maybe we just let it slip?
I am OK with leaving it unfixed, iow, we just say this:
If deep/in is a different repository, whether it is a submodule,
"git add deep/in/the/tree/is-a-leaf.txt" will give an undefined
result.
But that is totally different from accepting it as a feature. If we
were to accept it as a feature (and we will not), then
I did "git add deep/in/the/tree/is-a-leaf.txt" and have kept the
path tracked. Today I did "git add deep/*" and then the path
disappeared from my project--I now only have deep/in as a
submodule, which is not what I want.
would become a valid bug report. I do not want to see that happen.
I.e. I am *NOT* OK with polluting the codebase with a hack to
respond to such a bug report, e.g. by adding a rule that says "if a
file deep/in/the/tree/is-a-leaf.txt is tracked and deep/in is a
repository, 'git add deep/in' must fail".
The stance "It is a bug, but we do not fix it right now. The
behaviour is undefined" also leaves the door open for a future
enhancement that allows 'git add deep/in/the/tree/is-a-leaf.txt' to
be an equivalent to 'git -C deep/in/the/tree add is-a-leaf.txt'.
next prev parent reply other threads:[~2016-05-06 20:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 22:31 [PATCH] pathspec: remove check_path_for_gitlink Stefan Beller
2016-05-05 23:09 ` Junio C Hamano
2016-05-05 23:15 ` Stefan Beller
2016-05-05 23:27 ` Junio C Hamano
2016-05-05 23:32 ` Stefan Beller
2016-05-05 23:54 ` Junio C Hamano
2016-05-06 0:28 ` Stefan Beller
2016-05-06 6:21 ` Junio C Hamano
2016-05-06 6:58 ` Stefan Beller
2016-05-06 7:14 ` Junio C Hamano
2016-05-06 10:30 ` Duy Nguyen
2016-05-06 17:13 ` Stefan Beller
2016-05-06 19:02 ` Junio C Hamano
2016-05-06 19:18 ` Stefan Beller
2016-05-06 20:09 ` Junio C Hamano [this message]
2016-05-07 7:16 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqd1oz2bjg.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=felix@debuggable.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.