From: Junio C Hamano <gitster@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org, Petr Baudis <pasky@suse.cz>,
"Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: Not going beyond symbolic links
Date: Mon, 04 Aug 2008 23:11:11 -0700 [thread overview]
Message-ID: <7vej54xa80.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: alpine.LFD.1.10.0808041921530.3299@nehalem.linux-foundation.org
Linus Torvalds <torvalds@linux-foundation.org> writes:
> IOW, sometimes you may _want_ to use symlinks that way, even within one
> project - with a symlink allowing you to move parts of it around
> "transparently".
While I admit that I have managed a large directory split across
partitions grafted via symlinks in pre-git days myself, ever since you
started "tracking" symbolic links with 8ae0a8c (git and symlinks as
tracked content, 2005-05-05), you have pretty much been committed to
"track" symbolic links.
This goes even before that commit. The readdir() loop done in show-files.c
with 8695c8b (Add "show-files" command to show the list of managed (or
non-managed) files., 2005-04-11) does not dereference symbolic links
pointing at a directory elsewhere, which we still have as read_directory()
in dir.c without much change in the basic structure.
I would give some leeway to other people who made comments in this thread,
who may not be so familiar with the low-level git codebase, but I have to
say that if you claim that dereferencing symbolic links in the middle is a
feature, you are not being completely honest, you haven't thought through
the issues, and/or you simply forgot the details. I'd suspect most likely
it is the last one ;-).
The thing is, the "feature" is not very well supported, even without the
fixes from last night. If you have a symlink "sym" that points at "dir"
that has "file" in it, and if neither "sym" nor "dir/file" are tracked,
you can "git add sym/file" to add it (I called it a bug).
However:
(1) starting from the same condition, "git add ." does _not_ add it (you
get the symbolic link "sym" added to your index instead, as well as
"dir/file");
(2) after you add "sym/file" through the bug, if you say "git add .", it
will be removed from the index and you will instead have "sym" and
"dir/file" (with an ancient git before 1.5.0, you will get "unable to
add sym" error instead).
(3) after you add "sym/file", "git diff" will immediately notice that you
have removed it (this is a fairly recent fix; 1.5.4.X doesn't notice
it).
You cannot have it as a reliably usable feature without a major surgery,
and this is fundamental. You simply cannot have it both ways without
telling git which symlink is "tracked" and which are only there for
storage sizing.
If you seriously want to claim that we support such a feature, you would
at least need to:
(0) have a way for the user to say, "the project tree may have a
directory D, but I do not want to check it out as a directory because
my partition is too small. Whenever you need to create a directory
there and hang a tree underneath, instead create a symlink that
points at /export/large/D instead". Most likely this information
would go to .git/config;
(1) whereever we run "create leading directories", we notice and honor
the above configuration (mostly entry.c::create_directories() called
from entry.c::checkout_entry());
(2) whenever we need to check out a file to path D, instead of
recursively remove everything under it, we remove the symlink and
deposit the file there (mostly entry.c::remove_subtree() and
unpack-trees.c::verify_absent());
(3) whenever we traverse working tree using readdir(), notice that the
symbolic link we are looking at is the funny "pointing elsewhere but
this is really a directory" specified in (0) and recurse into the
directory pointed by it (dir.c::read_directory_recursive() but there
may be others)
(4) and we teach has_symlink_leading_path() to special case such a path
you configured in (0).
I personally do not think adding these to support such a "feature" is such
a high priority, and I do not think it is honest to claim we support such
a feature without doing any of the above. The current reality is that our
symlink support is still broken in corner cases, and being able to easily
add "sym/path" via "git add" and "git update-index --add" is one of them.
next prev parent reply other threads:[~2008-08-05 6:12 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 19:11 [RFC][PATCH 0/7] Submodule support in git mv, git rm Petr Baudis
2008-07-16 19:11 ` [PATCH 1/7] git-mv: Remove dead code branch Petr Baudis
2008-07-16 19:11 ` [PATCH 2/7] t7400: Add short "git submodule add" testsuite Petr Baudis
2008-07-16 19:11 ` [PATCH 3/7] git submodule add: Fix naming clash handling Petr Baudis
2008-07-16 19:11 ` [PATCH 4/7] submodule.*: Introduce simple C interface for submodule lookup by path Petr Baudis
2008-07-16 19:11 ` [PATCH 5/7] git mv: Support moving submodules Petr Baudis
2008-07-17 2:37 ` Junio C Hamano
2008-07-17 13:06 ` Petr Baudis
2008-07-17 22:31 ` [PATCH] git-mv: Keep moved index entries inact Petr Baudis
2008-07-17 22:34 ` [PATCH] git mv: Support moving submodules Petr Baudis
2008-07-19 23:54 ` [PATCH] git-mv: Keep moved index entries inact Junio C Hamano
2008-07-21 0:23 ` Petr Baudis
2008-07-21 0:25 ` [PATCHv2] " Petr Baudis
2008-07-21 4:36 ` Junio C Hamano
2008-07-26 6:46 ` Junio C Hamano
2008-07-27 13:41 ` Petr Baudis
2008-07-27 13:47 ` [PATCH] t/t7001-mv.sh: Propose ability to use git-mv on conflicting entries Petr Baudis
2008-07-28 1:13 ` Junio C Hamano
2008-07-28 1:21 ` Junio C Hamano
2008-07-28 14:20 ` [PATCHv2] git-mv: Keep moved index entries inact SZEDER Gábor
2008-07-28 15:06 ` Johannes Schindelin
2008-07-28 15:14 ` Johannes Schindelin
2008-07-28 18:24 ` Johannes Schindelin
2008-07-28 19:19 ` Junio C Hamano
2008-07-28 23:41 ` Johannes Schindelin
2008-07-28 23:55 ` Johannes Schindelin
2008-07-29 0:17 ` Petr Baudis
2008-07-29 0:46 ` Junio C Hamano
2008-07-29 5:23 ` Junio C Hamano
2008-08-04 7:49 ` Not going beyond symbolic links Junio C Hamano
2008-08-04 7:51 ` [PATCH 1/2] update-index: refuse to add working tree items beyond symlinks Junio C Hamano
2008-08-04 7:52 ` [PATCH 2/2] add: " Junio C Hamano
2008-08-05 0:21 ` Not going beyond symbolic links Linus Torvalds
2008-08-05 0:54 ` Junio C Hamano
2008-08-05 1:43 ` Linus Torvalds
2008-08-05 1:59 ` Johannes Schindelin
2008-08-05 2:28 ` Linus Torvalds
2008-08-05 6:11 ` Junio C Hamano [this message]
2008-08-05 12:54 ` Dmitry Potapov
2008-08-05 23:57 ` Junio C Hamano
2008-08-05 17:15 ` Linus Torvalds
2008-08-05 4:44 ` Junio C Hamano
2008-08-05 11:23 ` Johannes Schindelin
2008-08-05 3:01 ` Junio C Hamano
2008-08-05 3:04 ` david
2008-08-07 6:52 ` Junio C Hamano
2008-08-08 20:55 ` Junio C Hamano
2008-08-08 23:45 ` Linus Torvalds
2008-07-21 1:20 ` [PATCH] git-mv: Keep moved index entries inact Johannes Schindelin
2008-07-21 7:18 ` Petr Baudis
2008-07-21 7:38 ` Junio C Hamano
2008-07-16 19:11 ` [PATCH 6/7] git rm: Support for removing submodules Petr Baudis
2008-07-16 22:41 ` Johannes Schindelin
2008-07-17 12:35 ` Petr Baudis
2008-07-17 12:59 ` Johannes Schindelin
2008-07-16 19:11 ` [PATCH 7/7] t7403: Submodule git mv, git rm testsuite Petr Baudis
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vej54xa80.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
--cc=spearce@spearce.org \
--cc=torvalds@linux-foundation.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).