On Thu, Nov 19, 2009 at 10:33:05PM -0800, Junio C Hamano wrote: > Dmitry Potapov <dpotapov@xxxxxxxxx> writes: > > > It is more difficult to make this mistake with Git than many others > > VCSes, because Git shows the list of files that are changed but not > > committed as well as the list of untracked files when you try to commit > > something. > > Not really in practice. Too many people carry their existing practice of > using -m to write a useless single liner commit log message that they > acquired while using their previous SCM. Well, at least, Git allows to avoid this mistake and produce good commit messages, but you are right it is difficult to break old bad habits... > Arguably, useless log messages > are less of a problem on systems like CVS/SVN because they do not do > useful log summarization such as "log -- paths..." or "shortlog", so they > can be excused for learning the practice in the first place, though. I think quite often commits in CVS/SVN cannot be summarized, because a single commit often contains what would be a short series of patches in Git plus a few separated fix-ups that are completely unrelated to the whole series. It is trivial to split your changes in a few separate commits in Git, but it is difficult to do that with CVS/SVN. > That incidentally is exactly why earlier we (mostly me and Linus) > recommended people not to teach "commit -m" to new people, but of course > nobody listened ;-). Those who got used to '-m' in another VCS will quickly find it on their own... BTW, Git User's Manual uses "git commit -m" 8 times in different examples, largely to explain what is committed here, and I think it is similar with other introductions to Git. Though, clearly '-m' is rarely useful in practice... Dmitry -- 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