Everduin94 / better-commits

A CLI for creating better commits following the conventional commits specification

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

append_hashtag option does not work when ticket cannot be inferred

nathonius opened this issue · comments

When I have a branch without a ticket that can be inferred, eg my-feature-branch, but specify the ticket manually, the hash is not added to the ticket. Example:

.better-commits.json (partial)

	"check_ticket": {
		"infer_ticket": true,
		"confirm_ticket": true,
		"add_to_title": true,
		"append_hashtag": true,
		"surround": "",
		"title_position": "start"
	},

output (branch my-branch):

┌   better-commits 
│
◇  Found repository config
│
◇   Checking Git Status 
│
◆  Changes to be committed:
│  styles.css
│
◇  Select a commit type
│  ✨ feat
│
◇  Add ticket / issue (optional)
│  5
│
◇  Write a brief title describing the commit
│  abc
│
◇  Write a detailed description of the changes (optional)
│  123
│
◇  Select optional footers (<space> to select)
│  closes <issue/ticket>
│
◇  Commit Preview ─╮
│                  │
│  ✨ feat: 5 abc   │
│                  │
│  123             │
│                  │
│  Closes: 5       │
│                  │
├──────────────────╯
│
◇  Confirm Commit?
│  No
│
●  Exiting without commit

Thanks for taking the time to open an issue! Makes sense.

It's relatively simple, but I'm not 100% sure on how I want to solve this yet.

I'm leaning towards appending the hashtag to the prompt regardless. And if the value is only #, programmatically remove it. The thing I worry about is users wanting to make a commit w/o a ticket number and thinking they need to backspace or remove that hashtag manually.

Alternatively, automatically appending the hashtag if missing. But, the other day I was transitioning some issues to Linear app and realized I was appending hashtags when I didn't actually want them on the ticket number. Maybe, automatically appending if the option is on and the ticket matches a number regex?

I read the "append_hashtag" option as whether or not to add a hash to the ticket reference, regardless of the tickets content. So to me adding the # regardless makes sense. But it's also not a big deal to specify the # when manually adding the ticket.

I read the "append_hashtag" option as whether or not to add a hash to the ticket reference, regardless of the tickets content

To clarify a little on this. But, I could be off-base in my initial assumption. The README description of that property is

"If true add hashtag to ticket (Ideal for Github Issues)"

AFAIK most ticket systems use something like XYZ-123 or FLO-11. i.e. Github is the only ticket system I know of that uses a hashtag + a number. - Which is why I mention *"Maybe, automatically appending if the option is on and the ticket matches a number regex". *

Because if the option always forces a hashtag. The user doesn't have the ability to modify it during the prompt. - I ran into this issue when migrating from Github issues to Linear.app. But, I was still able to remove the hashtag in the prompt when using a linear ticket as opposed to a github issue.

Long explanation short 😅 - I'm wondering if people use hashtags with tickets like XYZ-123. If that were the case, then I guess I would just go for automatically appending and view my scenario above as an edge case. Otherwise, I think always appending given a number regex might be a better option. Or, adding a prop like force-hashtag. Kind of overkill, but would have the most flexibility.

If I understand it correctly, the option actually prepends the hashtag and does not produce text like this: 12# ?

So it might be worth to update the name to add_hashtag or prepend_hashtag?

🎉 This issue has been resolved in version 1.13.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@nathonius @MrGreenTea - Deprecated the old append_hashtag in favor of prepend_hashtag.

You can set it to "Always" to enable this behavior. Always prepending the hashtag regardless of inference. Alternatively, it can be set to "Prompt" to use the original behavior. Default is "Never".