Re: [RFC/PATCH 0/7] Rework git core for native submodules

Ramkumar Ramachandra [off-list ref] writes:

Junio C Hamano wrote:

quoted

When you are changing information _about_ submodules (e.g. you may
be updating the recommended URL to fetch it from), you can use the
usual tools like "git diff" to see how it changed, just like changes
to any other file.  If the information _about_ a submodule A is
stored at path A, and at the same time you have a working tree that
corresponds to the root of the submodule A at that path, it gets
unclear what "git diff A" should report.  Should it report the
change in the submodule itself, or should it report the change in
the information _about_ the submodule?  By separating these two
concepts to two different places, .gitmodules design solves the
issue nicely.

git diff-link.  Just turn it into a buffer and diff as usual.

Sounds like you are saying that you can pile a new command on top of
new command to solve what the existing tools people are familar with
can already solve in a consistent way without adding anything new.
Are you going to dupliate various options to "git diff" and "git
log" in "git diff-link"?  Will you then next need "git log-link"?

Junio C Hamano wrote:

Sounds like you are saying that you can pile a new command on top of
new command to solve what the existing tools people are familar with
can already solve in a consistent way without adding anything new.
Are you going to dupliate various options to "git diff" and "git
log" in "git diff-link"?  Will you then next need "git log-link"?

What I'm saying is: As always, we start with plumbing and work our way
up to porcelain.  We do have git diff-files, diff-index, diff-tree, so
I don't see what the problem with diff-link is.  The point is that we
can get an initial scripted version out quickly.

And no, I never suggested a git log-link.