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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 5, 2013, 17:07 UTC
Message-ID: <7vfvz4dhy9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0mcii_YGqiQTxhSOfgzn7MOHO0TEO3Rx3cRQLOi1ij5Tg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 14 quoted lines

> Junio C Hamano wrote:
>> "git log -p .gitmodules" would be a way to review what changed in
>> the information about submodules.  Don't you need "git log-link" for
>> exactly the same reason why you need "git diff-link" in the first
>> place?
>>
>> So you may not have suggested it, but I suspect that was only
>> because you haven't had enough time to think things through.
>
> What is this git log -p .gitmodules doing?  It's walking down the
> commit history, and picking out the commits in which that blob
> changed.  Then it's diffing the blobs in those commits with each
> other.  Why is git log -p <link> any different?  We already know how
> to diff blobs, and we just need a way to diff links.

You already forget what you invented "git diff-link" as a "solution" for, perhaps?

By recording the submodules themselve and information _about_ the submodules separately (the latter is in .gitmodules), "git diff A" can show the difference in submodule A, while "git diff .gitmodules" can show a change, which is a possibly in-working-tree-only proposed change, in information about submoudules.

Once you start recording the latter also at path "A", it becomes unclear what "git diff A" should show.

That is what I said in the message, to which you invented "diff-link" as a solution to the "unclear"-ness.

Am I misremembering the flow of discussion in this thread?