Conversation
bereket-WMDE
left a comment
There was a problem hiding this comment.
Hi @guergana
I'd suggest you squash the two commits together and submit the pull request again. The reason is to two folds:
- to keep a clean git history
- after working on a feature branch (experimenting and fixing bugs through multiple commits), there should just be one commit at the end for review. all the commit changes you've made before are just for you.
squash commits: git rebase -i HEAD~n : where n is the number of commits you want to squash.
I'm open to suggestions, counter-points and feedbacks
|
I'd be happy with the commits as they are. I'm also a fan of a clean commit history, but in this case I'd argue that each of the commits provide value on their own. Introducing |
|
I agree with Jakob, I think they are separate tasks, but could also squash. Don't have a strong opinion about this. |
|
It's up for a vote ofc. think of this scenario. you're working on a feature for a couple of days and this is your commit history final working commit do we really want this ? |
|
@bereket-WMDE with the example history you provided it's a no-brainer that the commits should be squashed. It becomes a different story if the individual commits are actually meaningful on their own. Contrived example: Imagine you weren't part of our pairing session and you got used to running TL;DR do I think that we sometimes want multiple commits in one PR? Yes! Do we need two commits in this case? Yyy... maybe? No big deal either way IMO. |
No description provided.