I don't think you're arguing against the point being made.
Logical change 1, implement Hello World:
puts "Hello, World!"
Logical change 2, make it a method:
def hello_world
puts "Hello, World"
end
Logical change 3, take an argument for the greeting:
def hello_world(greeting)
puts "#{greeting}, World"
end
Logical change 4, take an argument for the recipient:
def hello_world(greeting, recipient)
puts "#{greeting}, #{recipient}"
end
Logical change 5, improve the method name by showing the intent:
def greet_recipient(greeting, recipient)
puts "#{greeting}, #{recipient}"
end
Logical change 6, defaults…:
def greet_recipient(greeting="Hello", recipient)
puts "#{greeting}, #{recipient}"
end
And so on. These could each be their own feature or part of a feature etc. What they are, though, is logically atomic. If you want to add a default recipient later, or next, that is its own logical commit. If you roll it back, each rollback will lead you to a logical difference, not some typo fix, e.g.
def greet_recipient(greeting="Hell", recipient)
puts "#{greeting}, #{recipient}"
end
plus the missing "o"
def greet_recipient(greeting="Hello", recipient)
puts "#{greeting}, #{recipient}"
end
Are one
logical commit, for which I'd use a fixup or `git commit --amend` or whatever. What one considers
logically atomic may differ from person to person, language to language, feature to feature… but they can be differentiated from things like typos quite easily.
Personally, I make numerous commits in a feature branch, (transparently, too, my typos included - I'm not proud:) and before requesting review I'll clean up using rebase into as few logical commits as possible, and upon acceptance either squash it all to one or leave it as is, depending on the team's culture/needs.