Ramkumar Ramachandra <artag...@gmail.com> writes:
> Junio C Hamano wrote:
>> 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"?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html