All of lore.kernel.org
 help / color / mirror / Atom feed
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'.

  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.