On Fri, 10 Feb 2006 01:05:28 -0800, Junio C Hamano wrote: > > Linus Torvalds <torvalds@osdl.org> writes: > > > Under that logic, "git status -v" would show all the diffs (not just > > filenames) and "git commit -v .." would be the same as "git commit .." but > > the "-v" flag would have been passed down to the "git status" call, so the > > commit message file would be pre-populated with the diff. > > Now that is done and sitting at the tip of "next". Thanks. This does look quite useful. A couple of comments, though: 1) I think the patch should come after the traditional status summary, not before. If something is obviously "wrong" (non-updated file, etc.) that will be more obvious in the summary, so it's good to present that up front, and not bury it after the patch, (which might make it initially invisible without scrolling). 2) Using the "^---$" separator to separate the the edited contents into a commit message and ignored content seems risky to me. One risk is that the user might put that magic string in the commit message. Perhaps the risk is low, but it would be a silent destruction of historical data, which seems like a bad trap. A second risk is that with the current patch-then-summary order it is actually quite easy to inadvertently clobber the separator while editing the commit message. Particularly because the separator is placed exactly where the user must begin editing. So it would be easy to leave the separator trailing on a line of commit message comments or else introducing some initial whitespace that would break it. Moving the patch after the summary (as discussed above) would help greatly in avoiding the clobbered separator, but wouldn't address the separator-appears-in-commit-message problem. -Carl - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2.1.8 : 2006-02-11 07:35:27 EST