Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: use existing message #3

Closed
rbutera opened this issue Apr 28, 2015 · 5 comments
Closed

feat: use existing message #3

rbutera opened this issue Apr 28, 2015 · 5 comments

Comments

@rbutera
Copy link

rbutera commented Apr 28, 2015

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

@jimthedev
Copy link
Member

@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
Copy link
Author

rbutera commented Apr 30, 2015

weird, github formatting issue, see the following comment

@rbutera
Copy link
Author

rbutera commented Apr 30, 2015

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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants