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
