Hello, On Wed, Nov 18, 2009 at 6:24 PM, Jeff King <peff@xxxxxxxx> wrote: > 1. It creates a bad user experience. You are not unreasonable for > wanting to put some specific text in your commit message. Having > git come back and say "oops, I might get confused by this later" > just seems like an annoyance to the user. agreed, though it's not that bad: when learning git, you will be confronted with the fact that the commit message has a few things that are special (well. it's doesn't break git, but the first line should be < 56 chars in length for example). Not being able to have From: lines in them that are not describing an author would then just be one of them. > 2. Mailinfo has to deal with data created by older versions of git. So > in your case, the rebase was a bomb waiting to go off. If we can > fix it so that an existing bomb doesn't go off, rather than not > creating the bomb in the first place, then we are better off. This is a very good point. I didn't quite think about that. > 4. Commit messages can come from other places than "git commit". What > should we do with a commit message like this that is imported from > SVN? Reject the import? Munge the message? I would leave that to the tool that does the import. Probably it would have to munge it. Yes. I DO see though that implementing the check at commit time would lead to problems popping up at other places. > Of course all of that presupposes that we can correctly handle the > existing data after the fact. Even with my patch, you still can't write > "From: foo@xxxxxxxxxxx" as the first line of your commit body. But that can't you? IMHO it would just attribute the commit to foo@xxxxxxxxxxx which can be an equally bad, if not worse thing (I'm saying that without the needed knowledge about git internals to really be sure, so take this with a grain of salt) I just have a bad feeling about trying out heuristics to see whether thing thing after from: is an email address or not as email addresses are notoriously hard to detect. Typing a commit message and applying a patch from an email should be separate things and should be handled separately. Currently they are not and this is what's causing the problem in the first place. Maybe that --strict thing is actually a good thing in the long run, even though I don't quite like it either :-) Interesting problem to have though. Philip -- 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