Junio C Hamano wrote:
> Would it be possible that (at least some part of, or possibly all
> of) your ideas had some merit, but with all your hostility against
> the current system and the work that went behind it, you did not
> communicate well enough to make others understand you?
Agreed. My annoyance with the current system did go a little
overboard, and I've been having a splitting headache for the last few
days.
> What I found very hard to read in this thread was that your messages
> all went like this:
>
> 1. In the current system, I have to be at the top level of a
> submodule to work in it (or some other problems).
>
> 2. I will fix it in a more "elegant" way.
>
> 3. I have to have a new object at the submodule path, not the
> current "submodule is a commit bound at the submodule path, and
> information about the submodule is in .gitmodules".
>
> There was very little concrete explanation on how #3 leads to #2,
> i.e. the overall design of your new system and how it will work,
> other than you would read what we currently write in .gitmodules
> from a new kind of object.
I had no way of expressing what I wanted to do except by writing code
when I started off this thread, but am in much better shape now. Let
me try to explain my fundamental assumptions and code in a concise way
now.
1. Having a toplevel .gitmodules means that any git-core command like
add/ rm/ mv will be burdened with looking for the .gitmodules at the
toplevel of the worktree and editing it appropriately along with
whatever it was built to do (ie. writing to the index and committing
it). This is highly unnatural. Putting the information in link
objects means that we get a more natural UI + warts like
cd-to-toplevel disappear with no extra code.
2. If we want to make git-submodule a part of git-core (which I think
everyone agrees with), we will need to make the information in
.gitmodules available more easily to the rest of git-core. One way to
do it without breaking anything is to unpack the root tree, look for
an entry with the path .gitmodules and handle it different from other
blobs: ie. parse it into structured data that the rest of git-core can
consume. However, I think it is very gross as the blob is not
inherently special in any way: it's just incidentally stored at a
specific tree path. The alternative is to have an inherently special
kind of blob (ie. link object). In the git-core code, I can simply
match for a link object and operate on it accordingly. As opposed to
matching a blob object, and its tree path. Moreover, this means that
the user can simply git edit-link <link> from anywhere in the worktree
instead of having to refer to the appropriate section in the toplevel
.gitmodules.
3. Currently diffing/ merging one huge .gitmodules file is a mess, as
it doesn't have to conform to a strict format. This means that I can
get conflicts between these two:
url = gh:artagnon/clayoven
url =gh:artagnon/clayoven
Moreover, since the fields are not ordered, a simple reordering of the
fields will cause a merge conflict. The correct way to fix this is to
split up .gitmodules into many logical files, have a git
edit-gitmodules which reduces user input to a strict format, and then
write custom diff/merge drivers. My proposal involves having a git
edit-link, and teaching git-core to diff/merge appropriately. The
information is already in logical bits.
4. The only seeming disadvantage of not having a file accessible via
the filesystem is that it doesn't behave like a full blob. But it
does; the code to unstage a link object (emulation) is actually very
simple: I'm currently writing it.
5. Having a first-class link object comes with functional advantages.
It means that I can have a ref pointing to link objects and easily
initialize a nested repository without having to initialize the
containing repository (ie. essentially replacing repo). We can have
true floating submodules, which is really nice in my opinion: you can
fix a library at v3.1 and switch it to v3.2 at some point in the
future without using ugly SHA-1 hexes anywhere.
6. While it is possible to work top-down from the current system, that
approach is clearly taking too long and is too painful. This explains
why submodules haven't come a long way in the last five years. With
my approach, I'm trying to make life simpler for everyone: it will
suddenly become much easier to hack on submodules, and it can improve
more rapidly over the next five years. I'm not thinking about
short-term fixes precisely for this reason: the long-term goal is
worth a little bit of short-term inconvenience.
7. I estimate that replacing the current submodule system without
feature regressions will not take a lot of effort and can be done with
minimal breakages. It's not a lot of code or anything very complex.
We just have to follow along the lines of how git-core handles blobs,
and write a little bit of code to make links behave like blobs (I'm
halfway done with this already).
--
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