>But then I found that that email address is shared to the whole world in git commit summary!
If you're talking about the email address in the commit itself, that's part of the commit object and not anything GitHub does behind your back. If you publish the commit anywhere, not just GitHub, the email address has become public knowledge.
You might find `git add -N` ("--intent-to-add") useful. It's an extra step, yes, but it allows you to e.g. view the content of new files with `git diff` without actually staging the content for commit, and will allow you to stage that file during `git add -p`.
IIRC (I read the git mailing list) there was a lot of arguing about whether generation numbers should be in the commit headers or stored in separate cache, and then a different fix went in to speed up "tag --contains" and the discussion was pretty much abandoned.
git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it yourself, you decide where line breaks should be, not the presentation machinery.
The optimal human-readable line length is something like 66 characters. It's much easier to quickly scan a log message that's 72 characters wide vs. one that is 200 characters wide.
"The optimal human-readable line length" isn't really something that exists, even if we make lots of assumptions about basic stuff like font size, avg word length, and color contrast.
Line length is an easy thing to assume everyone perceives the same way, but even given a consistent environment (definitely not a given in this age of increasingly diverse device dimensions) there's a wide range of preferences with little real impact on readability. Unless, of course, your assumptions about readability clash with the user's preferences or reading environment.
Put simply - make your life easy and reduce problems by just letting the user decide.
Making semantic line breaks (such as for bullets) is understandable, but it still feels wrong that we’re otherwise doing the job of `fold`. I started breaking lines in commit messages because it’s convention, but I still believe this is a tooling issue.
This shell script wraps wide commit messages to the width of your console.
You might be interested in the program "par", which uses dynamic programming to optimize the line breaks, and can automatically handle such things as text prefixed by "> ".
GitHub's online editor has a default commit message along the lines of "Edited path/to/file", and I see a lot of pull requests with that message, and nothing else. That's about the most useless message possible, since it adds no information that isn't already implicit in the commit. It would be better to leave it blank and force users to at least write _something_.
Be careful, we do that by default and we get a lot of "commit", "commit", "commit $date", "merge commit" messages from some programmers. Either a programmer accepts that a meaningful message is important on commits, or they don't. It's a people problem not a technical one.
The problem with that is that at least when I am merging something I often (with Mercurial anyway) don't have anything useful to say -- the commit is even marked specially as a merge commit. Other than bringing in one branch (which has hopefully been correctly commented) no changes were made.
Ah, but what if we encouraged programmers to write better commit messages? What if we splashed on a bit of gamification to raise everyone's level of awareness? Maybe a badge on your profile page...?
How would you objectively determine the usefulness of a commit message, though? While it might contain all the necessary parts, there is no way to determine if the sum of the parts adds up to a useful whole.
Also, badges are done to death. Everyone's got badges these days - so much so they're like ads. Personally, I've developed a blind spot to most of them.
Objectivity is irrelevant and impossible in this context of raising awareness and fun. If the mechanism was something as simple as an upvote next to the commit message, you would let the community define usefulness of the commit message.
Actually if you follow the thread(s) relating to this, a less invasive change to speed up "git tag --contains" was adopted (see git.git@ffc4b8012), so "soon" probably isn't the right word.
If you're talking about the email address in the commit itself, that's part of the commit object and not anything GitHub does behind your back. If you publish the commit anywhere, not just GitHub, the email address has become public knowledge.