From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <junkio@cox.net>
Cc: Andy Parkins <andyparkins@gmail.com>,
git@vger.kernel.org,
Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Subject: Re: [PATCH 6/6] Teach core object handling functions about gitlinks
Date: Tue, 10 Apr 2007 13:33:59 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0704101325580.6730@woody.linux-foundation.org> (raw)
In-Reply-To: <7vwt0kugmy.fsf@assigned-by-dhcp.cox.net>
On Tue, 10 Apr 2007, Junio C Hamano wrote:
>
> But I do not think the .gitmodules thing needs that. If we have
> conflicting (or non-conflicting for that matter) submodule
> moves, that's a _MAJOR_ project re-organization, and I do not
> think we would even want to automatically descend into
> submodules for merging or checking-out when we have such a
> situation in the higher level project.
100% agreed.
Also, note that while the ".gitmodules" (or whatever) file will be
required to do things like "git pull", the basic tree-level logic that I
sent out obviously doesn't need/use .gitmodules at all.
So there's a very real issue where a repository with submodules still
"works", even with a .gitmodules file that is totally scrogged and doesn't
have the right information (yet), it's just that it may simply not be able
to do all the operations because it cannot figure out where to pull
missing subproject data from etc..
So there is no reason to believe that we need to magically and
automatically resolve conflicts - if conflicts happen, functionality is
reduced, but it's not reduced so much that you cannot use the tree and try
to resolve them (which is important, btw, since often before you commit
your fix for the conflicts you'd want to *test* that fix, so we definitely
don't want these kinds of files to be so central that it gets hard to get
normal work done without them).
It really boils down to the same design issue: the way I think submodules
should work is that they are very loosely coupled with the supermodule.
The fact that the ".gitmodules" file isn't *that* critical comes largely
from that loose coupling.
Linus
next prev parent reply other threads:[~2007-04-10 20:34 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-10 4:12 [PATCH 0/6] Initial subproject support (RFC?) Linus Torvalds
[not found] ` <Pi ne.LNX.4.64.0704092115020.6730@woody.linux-foundation.org>
2007-04-10 4:13 ` [PATCH 1/6] diff-lib: use ce_mode_from_stat() rather than messing with modes manually Linus Torvalds
2007-04-10 4:13 ` [PATCH 2/6] Avoid overflowing name buffer in deep directory structures Linus Torvalds
2007-04-10 4:14 ` [PATCH 3/6] Add 'resolve_gitlink_ref()' helper function Linus Torvalds
2007-04-10 9:38 ` Alex Riesen
2007-04-10 14:58 ` Linus Torvalds
2007-04-10 15:35 ` Alex Riesen
2007-04-10 15:52 ` Linus Torvalds
2007-04-10 15:57 ` Alex Riesen
2007-04-10 16:16 ` Linus Torvalds
2007-04-10 15:54 ` Josef Weidendorfer
2007-04-10 4:14 ` [PATCH 4/6] Add "S_IFDIRLNK" file mode infrastructure for git links Linus Torvalds
2007-04-10 4:15 ` [PATCH 5/6] Teach "fsck" not to follow subproject links Linus Torvalds
2007-04-11 22:41 ` Sam Vilain
2007-04-11 22:48 ` Linus Torvalds
2007-04-11 22:59 ` Sam Vilain
2007-04-11 23:16 ` Linus Torvalds
2007-04-11 23:05 ` David Lang
2007-04-11 23:53 ` Linus Torvalds
2007-04-11 23:30 ` David Lang
2007-04-12 2:14 ` Linus Torvalds
2007-04-12 2:30 ` Junio C Hamano
2007-04-12 17:18 ` David Lang
2007-04-12 18:32 ` Dana How
2007-04-12 19:17 ` Linus Torvalds
2007-04-13 9:00 ` Rogan Dawes
2007-04-13 15:23 ` Linus Torvalds
2007-04-15 6:50 ` Dana How
2007-04-12 0:00 ` Dana How
2007-04-12 0:03 ` Sam Vilain
2007-04-12 0:34 ` Junio C Hamano
2007-04-12 1:52 ` Linus Torvalds
2007-04-12 2:00 ` Junio C Hamano
2007-04-12 2:06 ` Junio C Hamano
2007-04-12 2:28 ` Linus Torvalds
2007-04-11 23:30 ` Dana How
2007-04-10 4:20 ` [PATCH 6/6] Teach core object handling functions about gitlinks Linus Torvalds
2007-04-10 8:40 ` Frank Lichtenheld
2007-04-10 11:31 ` Alex Riesen
2007-04-10 14:55 ` Linus Torvalds
2007-04-10 16:28 ` Josef Weidendorfer
2007-04-10 16:50 ` Alex Riesen
2007-04-10 17:23 ` Josef Weidendorfer
2007-04-10 18:45 ` Linus Torvalds
2007-04-10 19:04 ` Andy Parkins
2007-04-10 19:20 ` Linus Torvalds
2007-04-10 20:19 ` Junio C Hamano
2007-04-10 20:33 ` Linus Torvalds [this message]
2007-04-12 0:12 ` Sam Vilain
2007-04-12 0:35 ` Martin Waitz
2007-04-12 2:01 ` Linus Torvalds
2007-04-12 3:56 ` Sam Vilain
2007-04-10 19:41 ` David Lang
2007-04-10 20:06 ` Junio C Hamano
2007-04-10 19:29 ` Josef Weidendorfer
2007-04-10 19:45 ` Linus Torvalds
2007-04-11 23:47 ` Sam Vilain
2007-04-12 0:13 ` Linus Torvalds
2007-04-12 0:42 ` Torgil Svensson
2007-04-12 0:56 ` Martin Waitz
2007-04-12 21:23 ` Torgil Svensson
2007-04-11 23:36 ` Sam Vilain
2007-04-11 8:06 ` Martin Waitz
2007-04-11 8:29 ` Alex Riesen
2007-04-11 8:36 ` Martin Waitz
2007-04-11 8:49 ` Alex Riesen
2007-04-11 9:20 ` Martin Waitz
2007-04-11 9:15 ` Junio C Hamano
2007-04-11 10:03 ` Martin Waitz
2007-04-11 20:01 ` Junio C Hamano
2007-04-11 22:19 ` Martin Waitz
2007-04-11 22:36 ` Linus Torvalds
2007-04-11 9:47 ` Andy Parkins
2007-04-11 11:31 ` Martin Waitz
2007-04-11 15:16 ` Linus Torvalds
2007-04-11 22:49 ` Sam Vilain
2007-04-11 23:54 ` Martin Waitz
2007-04-12 1:57 ` Brian Gernhardt
2007-04-12 15:12 ` Josef Weidendorfer
2007-04-10 4:46 ` [PATCH 0/6] Initial subproject support (RFC?) Linus Torvalds
2007-04-10 13:04 ` Alex Riesen
2007-04-10 15:13 ` Linus Torvalds
2007-04-10 15:48 ` Alex Riesen
2007-04-10 16:07 ` Linus Torvalds
2007-04-10 16:43 ` Alex Riesen
2007-04-10 19:32 ` Junio C Hamano
2007-04-10 20:11 ` Linus Torvalds
2007-04-10 20:52 ` Junio C Hamano
2007-04-10 21:02 ` Sam Ravnborg
2007-04-10 21:27 ` Junio C Hamano
2007-04-10 21:03 ` Nicolas Pitre
2007-04-15 23:21 ` J. Bruce Fields
2007-04-11 8:08 ` David Kågedal
2007-04-11 9:32 ` Junio C Hamano
2007-04-15 23:25 ` J. Bruce Fields
2007-04-11 8:32 ` Martin Waitz
2007-04-11 8:42 ` Alex Riesen
2007-04-11 8:57 ` Martin Waitz
2007-04-10 13:39 ` [PATCH] allow git-update-index work on subprojects Alex Riesen
2007-04-10 23:19 ` [PATCH] Allow " Alex Riesen
2007-04-11 2:55 ` Junio C Hamano
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=Pine.LNX.4.64.0704101325580.6730@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=Josef.Weidendorfer@gmx.de \
--cc=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).