Daniel Vicarel <shundra8820@xxxxxxxxx> writes: > Fair point. I would argue that in my own personal projects, where I am > the only contributor, sometimes I just want to accept the default > merge message and move on. However, one could apply that reasoning to > _every_ commit message in a personal project, and I certainly don't > believe in that... so yeah, you've given me something to think about. Like everybody else, I've had my fair share of "personal projects" that I was the only developer who lost interest in them in 6 months to 2 years since their inception---after that nobody would care, and in such projects, of course, I can remember what I was thinking when I did some nonsensical change early in their history. I can survive sloppy and crappy messages. But in other projects, I've learned that the author of a commit or a merge with my name and e-mail address 6 months ago often is a total stranger for me sitting in front of the display right now. > I agree that some clearer documentation around `merge --continue` is > worthwhile, to prevent other developers from thinking like myself. > Maybe a warning from the CLI after running `merge --continue`, > recommending `commit` usage instead? Such a warning suggests that the > option _should_ still be deprecated and removed in the future though. > > I am still interested in making a contribution to git, so let me know > which option you would like me to move forward with at this time: > adding the CLI warning, or going straight to a deprecation. Unless of > course you're already on it. :) Welcome to the development community. If you want a starter project, among those I listed, perhaps the doc update would be the quickest one that offers the most to learn from, as the first road block new developers seem to stumble on is not coding standard and stuff but social interaction between the patch submitter and reviewers. Allowing some selected command line option given to "git merge --continue" down to underlying "git commit" would be a lot harder for somebody new to the codebase. It might make sense to allow things like "--no-edit" and "--no-verify" to be passed, but you would never ever want to pass something like "--amend", or (even worse) a pathspec. And coming up with a sensible list of allowed options and arguments would be quite hard.
