Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html