All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Jens Lehmann <Jens.Lehmann@web.de>,
	Git Mailing List <git@vger.kernel.org>,
	Dennis Kaarsemaker <dennis@kaarsemaker.net>
Subject: Re: [PATCH] pathspec: adjust prefixlen after striping trailing slash
Date: Sun, 14 Jun 2015 14:34:45 -0700	[thread overview]
Message-ID: <xmqq4mmam0sq.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACsJy8A5ikjGmj+ysTUt9FFi9X0WzVXvnFSVbmFoe8rzHdNNoA@mail.gmail.com> (Duy Nguyen's message of "Sun, 14 Jun 2015 20:16:46 +0700")

Duy Nguyen <pclouds@gmail.com> writes:

> I think we should stop the ok-to-replace feature when submodules are
> involved, we consider submdules much more valuable than symlinks.

Hmm, I am not sure "valuable" is a good criterion to decide what
should happen, though.

The push to use ".git" that is a file pointing at a repository that
is safely stored away is a move to make valuable submodule more
easily removable from the working tree without losing information,
so that we can remove it from the working tree when the user
instructs us to, just like we can remove a symlink safely without
losing information.  The only thing we need to be careful is that
that the path that corresponds to the index entry is not "dirty".
That is, for a symlink, if you make it point at something different
without doing "git add" it, you would lose that working-tree-only
change when we "kill" that symbolic link in order to replace it with
a regular directory.  For a submodule, if you have uncommitted
changes in the submodule working tree, you would lose that the same
way when we "kill" that submodule in order to replace that directory
as part of the superproject's working tree.

There may need some more safety implemented (i.e. how we detect the
"dirty"-ness and when we stop the operation based on that), but I
would imagine there is nothing fundamentally special about submodule
that does not apply to a symlink or a normal blob.

      reply	other threads:[~2015-06-14 21:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13 16:55 assert failed in submodule edge case Dennis Kaarsemaker
2015-04-13 16:57 ` Dennis Kaarsemaker
2015-04-16 19:27 ` Jens Lehmann
2015-04-18  1:19   ` [PATCH] pathspec: adjust prefixlen after striping trailing slash Nguyễn Thái Ngọc Duy
2015-04-19 12:53     ` Jens Lehmann
2015-04-20  1:34       ` Duy Nguyen
2015-04-20  5:37         ` Junio C Hamano
2015-04-20  5:52           ` Duy Nguyen
2015-04-21 21:08             ` Junio C Hamano
2015-04-22 19:14               ` Jens Lehmann
2015-04-22 19:58                 ` Junio C Hamano
2015-04-22 22:32                   ` Jens Lehmann
2015-04-23  3:47                     ` Junio C Hamano
2015-06-14 13:16                       ` Duy Nguyen
2015-06-14 21:34                         ` Junio C Hamano [this message]

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=xmqq4mmam0sq.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Jens.Lehmann@web.de \
    --cc=dennis@kaarsemaker.net \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.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.