From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:03
Linus Torvalds [off-list ref] writes:
On Tue, 10 Apr 2007, Andy Parkins wrote:
quoted
Would it be nicer if .gitmodules were line-based to aid in merging?
I seriously doubt you'll ever be merging or changing this a lot. So I
don't think it's a huge concern.
I think Andy's comment comes from our earlier discussion on the
other in-tree configuration, .gitattributes file.
We were talking about using in-tree .gitattributes for deciding
if we apply crlf to each paths and other things like which 3-way
file-level merge backend to apply, and need to make the system
gracefully degrade even when in-tree .gitattributes have
conflict markers during a merge. And for that purpose, it is
certainly easier to arrange "pick each line, while ignoring <<<
or === or >>>, and if there are conflicting duplicates do
something sensible about them", if the file is line oriented.
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.
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
From: Sam Vilain <hidden> Date: 2016-06-15 22:43:04
Linus Torvalds wrote:
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..
Whoa... "missing" subproject data?
Surely, unless you're doing lightweight/shallow clones, if you have a
gitlink you've also got the dependent repository? Otherwise the
reachability rule will be broken.
Sam.
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:04
hoi :)
On Thu, Apr 12, 2007 at 12:12:59PM +1200, Sam Vilain wrote:
Linus Torvalds wrote:
quoted
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..
Whoa... "missing" subproject data?
Surely, unless you're doing lightweight/shallow clones, if you have a
gitlink you've also got the dependent repository? Otherwise the
reachability rule will be broken.
With submodules you actually have a natural cutting point where
you can say: no, I don't want to get that.
So for submodules the reachability rule is a little bit more relaxed.
And when you fetch the superproject you now need some way to fetch
the new submodule objects. They may be in the same upstream repository
but it may make sense to have this configurable.
--
Martin Waitz
[ Dang. Power failure in the middle of writing emails. Can't remember
which one was lost. Am rewriting some of this reply in abbreviated form. ]
On Thu, 12 Apr 2007, Sam Vilain wrote:
Linus Torvalds wrote:
quoted
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..
Whoa... "missing" subproject data?
Absolutely. Not just subproject data. The whole subproject is often
missing.
If I fetch the KDE superproject, I generally do *not* want every single
subproject. In fact, I'd likely just want one or two subprojects.
The notion that all subprojects are populated is a *bug*. I would
personally refuse to use such a setup. Even CVS can handle that just fine,
we certainly don't want to be worse than CVS here.
If you just track a project, it's quite common to only check out the "src"
module, and *not* fetch things like the "validation" or "test" module if
you're just following along.
Or you might fetch the "kdebase" module, but that sure doesn't mean that
you want all the other ones (kdevelop source code? full kdelibs sources?
If I'm only interested in kwin and some other random app? No thanks!).
Surely, unless you're doing lightweight/shallow clones, if you have a
gitlink you've also got the dependent repository? Otherwise the
reachability rule will be broken.
The reachability rule *must* be breakable. That's why fsck currently
doesn't care AT ALL.
It's much better to break that rule than to even check it! I'd rather
leave fsck like it is now, than to *ever* fix it, if the "fix" involves
"you have to always fetch all submodules to shut fsck up".
Linus
From: Sam Vilain <hidden> Date: 2016-06-15 22:43:04
Linus Torvalds wrote:
quoted
Whoa... "missing" subproject data?
Absolutely. Not just subproject data. The whole subproject is often
missing.
If I fetch the KDE superproject, I generally do *not* want every single
subproject. In fact, I'd likely just want one or two subprojects.
Ok, but couldn't this be considered a variation of a lightweight checkout?
The only reason I'm worried about this is the case where the
superproject contains *thousands* of subprojects. Eg, a superproject for
all repo.or.cz projects. Say in a day 200 projects get updated with a
few commits - do you have to do 200 pulls or just one? But maybe that
problem can be solved in another way, or maybe it won't really hurt so
much in practice and still be faster/more efficient than rsync mirroring.
This is especially the case in concert with gittorrent, which will need
modifications to support sharing multiple repositories (not that that's
a huge issue, given there's no implementation yet).
quoted
Surely, unless you're doing lightweight/shallow clones, if you have a
gitlink you've also got the dependent repository? Otherwise the
reachability rule will be broken.
The reachability rule *must* be breakable. That's why fsck currently
doesn't care AT ALL.
It's much better to break that rule than to even check it! I'd rather
leave fsck like it is now, than to *ever* fix it, if the "fix" involves
"you have to always fetch all submodules to shut fsck up".
Well fsck can be fixed easily enough to not descend, like lightweight
checkouts.
What I really want to avoid is the situation where you can't checkout,
even though you didn't indicate a shallow/lightweight clone.
What else might this decision impact? Obviously with a smaller base you
have fewer delta targets, though that's probably not a real issue.
Sam.