Re: Why does "merge --continue" expect no arguments?

[Junio C Hamano <gitster@pobox.com>]

Daniel Vicarel <shundra8820@gmail.com> 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.