feat: use existing message

[rbutera]

if git cz is passed the argument -m then that message should be passed to the "short imperative tense description of the change"

[jimthedev]

@raibutera Great idea. One thing we need to consider is that you can do this in git:

git commit -m "This is a line" -m "This is a second line" -m "This is a third line"

If someone uses this format in git cz then we need to be able to accommodate all of the messages that they pass. I am thinking that we can show the ui then allow people to write {m1} or {m2} or {m3} in the ui where they want to use the various arguments that they passed in via the cli. How does that sound?

[rbutera]

weird, github formatting issue, see the following comment

[rbutera]

the -m flag

In my personal opinion, users of cz-cli would probably expect that the -m flag would be inserted as the 'short' message.

multiple -m flags

As a result, passing in multiple -m flags doesn't really make sense in the context of cz-cli. Any attempt to coerce the existing behaviour to fit the commitizen model would be strained.

A more sensible implementation would just combine the three passed messages (truncated to 100 char total) and insert that into the short message. This is the easiest solution to implement quickly anyway.

So git cz -m 'add commitizen' -m 'because' -m 'it's cool' would produce a short message section of 'add commitizen because it's cool'

Commitizen Specific Flags

There's also no real reason why we couldn't implement extra, commitizen specific flags. NB: we should just take extra care to avoid conflicts with existing git commit flags. (Except for -m, because commitizen makes -m redundant)

Commizen Specific Flags Suggestion

• -m (for short message)
• -type
• -scope
• -body
• -notes / -footer

maybe we can add shorthand aliases for type, scope, body and notes, ie: --t --s --b --n/--f

Prompt Behaviour

I don't really see the point in passing in messages via flag of the user still has to use the wizard-like prompt. It's less friction to just not pass anything at all than have to remember the order in which the messages were passed. That's the main complaint I have with the {m1}/{m2}/{m3} idea.

Example of Suggested Behaviour

Complete (All Flags)

Input 'git cz -type "feat" -m "add commitizen support" -scope "development" -body "Lorem ipsum dolor sit amet consectetur adipiscing elit In aliquet magna et ligula porttitor viverra. I'm just typing more to break the 100 char limit." -notes "fixes #1234"

this would produce

feat(development): add commitizen support 

Lorem ipsum dolor sit amet consectetur adipiscing elit In aliquet magna et ligula porttitor viverra.
I'm just typing more to break the 100 char limit.

fixes #1234

Incomplete (1+ flags missing)

If I reran the same command as above but, for example, omitted the -notes flag, the prompt would just come up with List any breaking changes or issues closed by this change:.

[jimthedev]

Thanks for laying this out in an organized way.

I like the idea and I think we can probably make this work with the current system of allowing adapters to coexist for various conventions. Most of what you're talking about should be implemented in the cz-conventional-changelog adapter repo even though any future adapter could certainly implement the same functionality since the cz-cli is really just a thin wrapper.

[jimthedev]

I am closing this for now and have opened an issue with the cz-conventional-changelog adapter since that is really where this issue belongs.

The only part of this issue that the cli can assist with is the passing of raw and/or parsed arguments into the adapters' prompter method. I don't really expect that this getting completed until I finalize a versioned programmatic adapter spec.