Hi again,
So we've thought about it for some time, and I really need you to
start reviewing the code now.
I'll just summarize what we've discussed so far:
1. The malleability argument doesn't hold, because we're proposing a
link object with optional fields.
2. The local-fork argument doesn't hold, because users will be
rebasing changes to the link object in exactly the same way as they
currently do with the blob object .gitmodules.
3. The worktree argument doesn't hold, because we're proposing to
treat the link object as nothing more than a blob object that can be
parsed by git-core. It will stage and unstage just like a blob.
Sure, it's not accessible directly by the filesystem: so what? What
is the difference does `emacsclient .gitmodules` versus `git edit-link
clayoven` make to the end-user?
4. The diff-confusion argument is just another by-the-way, but it
doesn't really hold either. Currently, we see:
- Subproject commit b83492
+ Subproject commit 39ab2f
(with diff.submodule set to log, we can actually see the log of the
submodule between these two commits. With links, we will see:
- checkout_rev = b83492
+ checkout_rev = 39ab2f
There's nothing that prevents us from respecting diff.submodule (some
minor glue code will have to be written; that's all).
*. There is actually one thing that .gitmodules does better than
links. foreach. It's trivial to implement with .gitmodules and hard
to implement with links: with .gitmodules, the paths of all the
submodules are in one place. But with links, we'll have to
unpack_trees() every tree in the entire repository, and dig through it
to find all the link objects to initialize. Basically, inefficient
and inelegant. However, I don't think this is a big problem in
practice, since this is not exactly a common operation: I'd probably
want to recurse-submodules once at clone time.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html