mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2026-03-22 12:44:37 -05:00
Allow to use "ref" as short form of "refactor" #117
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/conventionalcommits.org#117
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Snelius30 on GitHub (Dec 25, 2020).
It's most annoying long term for me. I guess it will be good to add "ref" as a short form.
Propose as equal form
refactor(CClass): Remove paramsand
ref(CClass): Remove params@nikolay commented on GitHub (Jan 5, 2021):
It's ambiguous as 'ref' abbreviation means only 'reference.'
@Snelius30 commented on GitHub (Jan 6, 2021):
'reference' is out of context there
@MohammedNoureldin commented on GitHub (Mar 20, 2021):
I would say
refaorrefac, as for me it does not make sense to usefeatinstead of feature, whilerefactoris longer than feature. Especially thatrefactoris one of the most used prefixes.In general, I find all prefixes are relatively long and not consistent (different char count), especially with 50 char limit.
@nikolay commented on GitHub (Mar 22, 2021):
@MohammedNoureldin If most of your commits are refactorings, that this is an indicator that you need to revisit your process.
@MohammedNoureldin commented on GitHub (Mar 22, 2021):
@nikolay , no it is not. But this is not my point. My point is, it makes no sense to use
featinstead offeature(7 chars), while usingrefactor(8 chars) as a full word. and I believe this is what the author of this issue meant (and I fully support his opinion).@Conaclos commented on GitHub (Aug 3, 2022):
rejig?
@nikolay commented on GitHub (Aug 3, 2022):
@MohammedNoureldin The difference is that there's an established abbreviation of
refmeaningreference! Meanwhile,feateven outside of the domain of computer science meansfeature. No need to invent new abbreviations - the English language has enough already!@SmartManoj commented on GitHub (Jul 30, 2024):
Proposal: Adopt "rftr" as a shorthand for "refactor" in commit message conventions.
Benefits:
This change could enhance the commit message structure. Feedback and discussion on this proposal are welcome. Adjustments to better fit specific needs are encouraged.
@nikolay commented on GitHub (Aug 2, 2024):
@SmartManoj "Premature optimization is the root of all evil." You're creating more problems than you're solving - now there's AI autocompletion in the terminal if you're too lazy to type 4 more characters! No English speaker will guess that "rftr" stands for "refactor," just like no English speaker will assume that "ref" stands for "refactor"! Also, typing is a form of exercise that burns calories - embrace this opportunity!
Do not try to draw parallels with "feat," which is a standard English abbreviation like "doc"!
@SmartManoj commented on GitHub (Aug 3, 2024):
Thank you for your feedback. I understand your concerns, especially regarding potential confusion and the use of AI autocompletion tools. The intention behind proposing "rftr" wasn't to replace clarity with brevity but to introduce a shorthand that could become consistent and recognizable within a specific team or project context, much like how "feat" has been widely adopted.
While "rftr" may not be immediately intuitive, consistent use within a team could establish its meaning, just as other shorthand conventions have been accepted. The goal is to create a pattern that aligns with existing practices like "feat" while improving efficiency for those who prefer or need shorter commit messages. Of course, adopting this shorthand would be entirely optional and dependent on team consensus.
Since you mentioned AI autocompletion in the terminal, could you recommend a tool that effectively handles these scenarios? It might be a valuable addition to our workflow as well.
Looking forward to your thoughts!
@nikolay commented on GitHub (Aug 3, 2024):
@SmartManoj Again,
feat1 anddoc2 are standard abbreviations. Also,featis also a word - maybe, in this case, it wasn't even meant to meanfeaturebutI would never remember
rftras it doesn't follow the English rules for abbreviations!@nikolay commented on GitHub (Aug 3, 2024):
@SmartManoj Last but not least - one must be able to read good abbreviations as a word, for example,
ASAPandSQL. Good like withrftr!@SmartManoj commented on GitHub (Aug 3, 2024):
Thank you for your feedback. You’ve made some excellent points about the nature of abbreviations. However, I’d like to clarify that "rftr" is intended as shorthand, not a strict abbreviation. The goal is to create a concise form that, while not conforming to traditional English abbreviation rules, serves a functional purpose within a team's specific context.
Shorthands like "rftr" are designed to improve efficiency and consistency within a project, even if they don't follow conventional abbreviation norms or spell out a word phonetically. The idea is that, over time, "rftr" can become easily recognized within an environment, much like other project-specific conventions.
That said, I understand the importance of intuitive and recognizable forms. However, after reconsidering, I believe "rftr" still suits the needs by being concise and distinct.
If you have any further thoughts or suggestions on this, I'd be glad to discuss them!
Thank you again for the valuable discussion!
@nikolay commented on GitHub (Aug 3, 2024):
@SmartManoj There are many FOSS tools for expanding shorthand codes into text, and Espanso 1 comes to mind. Let's not allow "convention commits" to become "cryptic commits." Language and unambiguity are crucial considerations.
@SmartManoj commented on GitHub (Aug 4, 2024):
Thank you for your input. I completely agree that clarity and unambiguity are vital when it comes to committing messages. While the intention behind proposing "rftr" was to create consistent and efficient shorthand within a specific context, I understand the concern about potentially making commits less readable.
The mention of tools like Espanso is a good point; however, it's important to note that Espanso is a text expander, not a text predictor. I’m using AutoHotKey for text expansion. These tools can help expand shorthands while maintaining clarity. However, I believe there’s a balance to be struck between efficiency and readability, and it's essential to ensure that any shorthand adopted doesn’t compromise the comprehensibility of the commit messages.
Similarly, the shorthand "msg" for "message" might seem cryptic at first, but it can become second nature with consistent use, just like "rftr." The goal isn't to create "cryptic commits" but rather to streamline the process while retaining clarity. If "rftr" or "msg" risks being too obscure, I’m open to reconsidering their use or finding ways to ensure they remain clear to everyone involved.
I appreciate your perspective and would love to continue the discussion to find the best solution.
Thank you again for your valuable insights!