> intent(auth): users need social login, starting with Google before GitHub and Apple
Your 'intent' is 'users need social login'? That does not make sense.
Your intent is 'Getting more users by lowering barriers to sign up', a business goal. That business goal might have hierarchical children – for example, Jira epics – such as 'offer social sign-in', or 'declutter landing page.'
Also, the commit mentions 'Google before GitHub', but how can a commit (a snapshot of the repository) know the future? What if your product manager decides Google is fine enough and GitHub/Apple aren't needed?
I wish our profession would stop trying to reinvent issue tracking in git every week.
teeray
It continually amazes me how averse people are to just explaining why a commit exists in the body of the commit. Is all this tagging actually easier to read than written prose? You don’t even have to write it anymore if the sight of your editor opening upon `git commit` causes some instinctual revulsion.
show comments
agateau
Would be curious to know if it works better than writing the Why as human-friendly paragraphs in the body of the commit message.
show comments
keybored
> an open standard for capturing the WHY in git history
Agentic coding keeps reinventing coding.
That was my first thought.
> And then it hit me - the commit body has always been there. Completely underutilised.
Wait. What? This is the standard?
> Here is an example of how a Contextual Commit looks:
The format is key-value stuff. You can already use trailers for that. The syntax here doesn’t work with that stuff.
If you have already readh the “conventional commits” (pronounce with a sneer) specification you have already seen them. They’re called footers because they also didn’t know about trailers.
> No new tools. No infrastructure. Just better commits.
> intent(auth): users need social login, starting with Google before GitHub and Apple
Your 'intent' is 'users need social login'? That does not make sense.
Your intent is 'Getting more users by lowering barriers to sign up', a business goal. That business goal might have hierarchical children – for example, Jira epics – such as 'offer social sign-in', or 'declutter landing page.'
Also, the commit mentions 'Google before GitHub', but how can a commit (a snapshot of the repository) know the future? What if your product manager decides Google is fine enough and GitHub/Apple aren't needed?
I wish our profession would stop trying to reinvent issue tracking in git every week.
It continually amazes me how averse people are to just explaining why a commit exists in the body of the commit. Is all this tagging actually easier to read than written prose? You don’t even have to write it anymore if the sight of your editor opening upon `git commit` causes some instinctual revulsion.
Would be curious to know if it works better than writing the Why as human-friendly paragraphs in the body of the commit message.
> an open standard for capturing the WHY in git history
Agentic coding keeps reinventing coding.
That was my first thought.
> And then it hit me - the commit body has always been there. Completely underutilised.
Wait. What? This is the standard?
> Here is an example of how a Contextual Commit looks:
The format is key-value stuff. You can already use trailers for that. The syntax here doesn’t work with that stuff.
If you have already readh the “conventional commits” (pronounce with a sneer) specification you have already seen them. They’re called footers because they also didn’t know about trailers.
> No new tools. No infrastructure. Just better commits.
Okay, let’s cut right to the point..