What about the revert type?

[Mouvedia]

There's no mention of it.

cf https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#revert

[damianopetrungaro]

Thank you for opening the issue @Mouvedia . Good one ;)

I would like to specify that we do not stick to the angular convention we are just inspired by it.

Anyway we miss the revert type. IMHO is fine to use the Git default one Revert "feat: Add birthdate to user model" because it doesn't add any overhead during the reverting phase and is explicit because it wrap a conventional commit message.

Let's see what @conventional-commits/committee think about it.

[Mouvedia]

@damianopetrungaro would the commit "feat(user): Add birthdate" be the revert of the commit "feat(user): Remove birthdate"?

Should the type always match the reverted commit's type? Should the message be identical?

[damianopetrungaro]

@Mouvedia IMHO it makes sense to be Revert "feat: Add birthdate to user model" or revert: Add birthdate to user model because Remove birthday is not a feature itself, it may be part of a fix (but this means it's not reverted).

[Mouvedia]

Personally I use the revert type for commits which stated purpose is to revert. For example if the original commit has some valuable artifacts, I end up with a partial revert.

e.g. revert: a6c8e75

[damianopetrungaro]

Yup, I got it, I said my opinion but before adding it to the specs I want also other people from the committee

[hutson]

My two cents would be to simply document what git already does. As noted by @damianopetrungaro using git revert and keeping it's auto-generated message is easy. Doing anything else just adds friction and a greater chance of not adhering to the convention.

because Remove birthday is not a feature itself, it may be part of a fix (but this means it's not reverted).

In my experience a revert is always a fix. Even if it the commit technically adds a feature, it's only because the removal of that feature was unintended (it essentially introduced a bug).

However we really should document how to handle revert commits.

[Mouvedia]

@hbetts that doesn't cover my current usage of the revert type which is a partial revert using git commit. The intent is a revert but granular: https://stackoverflow.com/q/45267653

[damianopetrungaro]

So @hbetts we have to face how to make it standardized also for processes that are not a simply git revert.

What do you think about it?

[hutson]

partial revert

Thank you @Mouvedia for the link. I was failing to see that you are reverting only part of a commit and not the entire commit.

So @hbetts we have to face how to make it standardized also for processes that are not a simply git revert.

So this may come down to semantics for me.

As an example, I have a commit that I introduced a long time ago. Turns out, that commit, which may have introduced a feature, also changed a line of code that, unintentionally, broke existing behavior.

I could do a partial revert. I could end up with a commit, of type revert, that removes the modification to that line of code.

However, isn't that also a fix?

[damianopetrungaro]

yeah, you're right, this is a fix anyway.

However, isn't that also a fix?

[Mouvedia]

Most of the time, it's the other way around: you revert the commit in the spirit on its initial message but leave out some artifacts that are worth keeping. Don't throw the baby out with the bathwater.

If it's not considered a revert, you won't use the revert type obviously.

[damianopetrungaro]

But the point is that when you revert a feature (or a fix) you are creating a fix for it.

@hbetts what about other commit types like docs/chore? They aren't types that should trigger a version update, but anyhow you are reverting a commit.

So they will be just docs(api): remove users from documented resources for example.

[Mouvedia]

IMHO the short hash of the original commit should be mandatory. Since you allow custom types Ill continue to use the revert type. I was just enquiring as to why it was omitted.

[damianopetrungaro]

@Mouvedia but revert not being part of the specs we may just enforce the usage in the FAQ section.

[damianopetrungaro]

@Mouvedia any other idea on this?

[Mouvedia]

@damianopetrungaro this list should be 'build', 'ci', 'chore', 'docs', 'perf', 'refactor', 'revert', 'style', 'test'.

cf https://github.com/marionebl/commitlint/blob/master/%40commitlint/config-conventional/index.js#L19

[vmx]

This discussion reads like there is an agreement that if you git revert a commit, the commit message should just be what Git is doing:

Revert "<the original header>"

This reverts commit <commit hash>.

<Put additional information here>

If it's a partial revert, you would use one of the existing types as it's probably a "fix", but it could e.g. also be "docs". You probably re-word the header anyway.

[stevemao]

conventional-changelog currently implements revert exactly the same way as the angular docs.

Revert

If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

[damianopetrungaro]

@stevemao @hutson @vmx any other feedback on this?

[hutson]

@hbetts what about other commit types like docs/chore?

If I introduce documentation that is inaccurate, I tend to revert the commit, use the docs type, along with a description that I'm correcting inaccurate information. Same thing as chore.

Again, this is just how I approach reverts. They may be some benefit to using, in-part, or in-whole, the git revert commit message that I am not aware of. Not to mention, others may find using revert commits to be useful in their own management of their projects, or useful in their tooling.

conventional-changelog currently implements revert exactly the same way as the angular docs. - @stevemao

That's a good point. We already follow the Angular convention. Are there sufficient benefits in changing?

[stevemao]

Revert "<the original header>" is default so you don't need to change anything. The angular way you'd have to modify the header slightly: revert: <the original header>

[damianopetrungaro]

We are inspired by the Angular convention, we are not following it.

That's a good point. We already follow the Angular convention. Are there sufficient benefits in changing?

And in this way we'll be consistnet with all the other commit types

That's a good point. We already follow the Angular convention. Are there sufficient benefits in changing?

[hutson]

We are inspired by the Angular convention, we are not following it.

:wink:

@damianopetrungaro do you feel we should be inspired in a different direction than the standard Angular convention? :smiley:

[bcoe]

👋 my two cents,revert: currently fits within the scope of the existing specification, and it seems fair to put the responsibility for how this is interpreted in the hands of the upstream tooling authors. I'd advocate that we document it in the FAQ like @damianopetrungaro suggests.

[Mouvedia]

I am fine with it but it needs to allow partial reverts as well.

[bcoe]

@Mouvedia I think from conventionalcommits.org's point of view, it only cares about the prefix revert: , the tooling author would be able to decide the meaning of everything after the : , which might be a partial revert or full revert.

[Mouvedia]

In light of TCR's emergence, the revert type may become as essential as fix and feat.

[damianopetrungaro]

@bcoe @Mouvedia @hutson do we want to add it in the specs?

[Mouvedia]

If it allows partial reverts and has the requirement to include the SHA(s) of the guilty commit(s) in the message, yes we should.

[damianopetrungaro]

IMHO sth like that may work:

3dd7c21 revert: typo and html anchor links for pt-br (#159) [Benjamin E. Coe]
b5cfe31 revert(lang): add russian translation for v1.0.0-beta.3 [Damiano Petrungaro]
32d6831 revert(lang): typo in features word in russian docs [Damiano Petrungaro]
c1ffdb4 feat: Enable translation on the website [Damiano Petrungaro]
477028b feat(it): Add beta.4 [Damiano Petrungaro]
3bbc7de feat(it): Add beta.3 [Damiano Petrungaro]
6729804 fix: Add parse-commit-message to the specs [Damiano Petrungaro]
89f040c docs: add Git Commit Template plugin to the tool section (#164) [Benjamin E. Coe]
3daaa7e feat(lang): Add zh-TW translation for version v1.0.0-beta.4 (#163) [Benjamin E. Coe]
3dd7c2a fix: typo and html anchor links for pt-br (#159) [Benjamin E. Coe]
b5cfe3a feat(lang): add russian translation for v1.0.0-beta.3 [Damiano Petrungaro]
32d6830 fix(lang): typo in features word in russian docs [Damiano Petrungaro]
23a4585 fix(security): address security vulnerability in node-sass (#158) [GitHub]
4480927 feat(lang): add brazilian portuguese (pt-br) language (#157) [Benjamin E. Coe]
584fd57 feat: Add Korean translation [Damiano Petrungaro]
ca2f1f5 feat(lang): add Chinese translation for 1.0.0-beta.4 (#155) [Steve Mao]
e89f89f feat: add french translation for 1.0.0-beta.4 (#153) [Benjamin E. Coe]