Is it possible to get branch name in a adapter?

[tjoskar]

Hi,

First of all, great project!

Is it possible to pass information about a branch (or some other git information) to an custom adapter?

I find this line: https://github.com/commitizen/cz-cli/blob/master/src/cli/strategies/git-cz.js#L59 where it looks like you are passing all arguments to git(?). Is it possible to parse the arguments and exclude cz-cli-specific arguments and pass them to a adapter?

Example:

$ git cz --author="Name <email>" --cz-branch-name="$(git rev-parse --abbrev-ref HEAD)"

The command above should pass --author to git commit and --cz-branch-name to the adapter (because the argument starts with --cz-).

What do you think? Is this a good solution? Or is it a better way?

[jimthedev]

Thanks @tjoskar and great idea. It is going to take some time to find the right answer, but it could be very powerful once complete.

This is something that needs to be improved in 3.0 (our next breaking changes version). With that said, before we make these kind of breaking changes we need to be sure we have a comprehensive list of use cases that git cz should cover and also need some time to alert committers of any deprecated functionality that might happen.

Specifically there needs to be some expectation on the part of committers that they can use git cz as a drop-in for git commit.

Up until now, git cz has been a wrapper for the git commit api. The reason for this is that as a developer you may want to always use git cz, even if the repo you're working on does not have a commitizen adapter configured. I'm unclear if this is something people are actually doing but my original intent was for this project to modify git's behavior in as small a way as possible. All we really do is strip out the -m arguments if an adapter is configured and replace it with the template that the adapter returns. Everything else is automatically passed on to git.

I like the idea of having a custom api like --cz-variable-name=value that gets stripped out and passed on. This would allow commitizen to keep the current functionality but also allow adapters to accept certain parameters. One question I have is, how should we reconcile these variables, passed via the command line, with the request to allow variables to be passed through the package.json. Perhaps we just pass it all through and let the adapter writers sort it out for their specific use case.

[brandondurham]

Curious about whether or not this is more attainable now?