In my experience these assertions are untrue. Also the tickets are often the over arching context and will have nothing to do with the code. My product owner doesn't care if I had to try three different algorithms till I got it right; but my colleagues and my future self sure would love to see that and all the stack overflow links during a git bisect!

Not only that but the ticket is a full feature. Maybe it took 5 commits to get there: "Fix bad indenting", "Extract base logic to command object", "Update I18N entries", "Add missing tests for current behavior", "Add the feature asked for".

From what I see you just agree with my comment. Those 5 commits you described as example are the way I would do it.

The way it is described in article would make you do it in one commit and add information that would be in the ticket.

Also, the ticket and the commits can provide answers to the same questions without being redundant. The answers are just at a different level of abstraction and for different readers. Tickets usually describe product-level decisions, while commits describe implementation-specific details. E.g. a ticket may discuss alternative user flows, while a related commit explains why a specific algorithm, module, or default configuration value was used.

What makes you say that? The Focused rule from the article is also meant to persuade you to split the work into similarly concise and focused commits.

Focused and complete are opposite. You can have focused commits or complete commits.

Tying the ticketing system and the repository together is a good idea and definitely worth implementing, but there's a fine balance in deciding what context should be kept in the ticket and what in the code repository. If you put too much into to the ticket and too little into the commits, then git blame loses it's value, for example.

Yes just be reasonable, whatever it means in context of change/team/project.