3 ms·
The author makes the argument that 'first parent' being the original branch is a mere convention. And he's right. If someone does the merge while checked out o
by kevin_b_er 5y ago
The author makes the argument that 'first parent' being the original branch is a mere convention.
And he's right. If someone does the merge while checked out on the feature branch, then commits it _as_ the master branch, then the first-parent concept breaks.
- thrashh 5y agoBut that problem is easy to fix with 0 disadvantages: Don’t do that. Don’t do it for the same reason that you have a convention of useful commit messages.
- ianlevesque 5y agoI masquerade as proficient in this field and I'm pretty sure I've done that just by accident with git a few times. Assuming any developer on your team is much better than monkeys on typewriters when it comes to git will lead to disappointment.
- exclipy 5y agoMake a precommit hook that enforces this. Done.
- Groxx 5y agoThis only enforces it where you have the hook installed. And it cannot be pre-installed on people who have newly cloned the repo. Which makes it nearly useless. Not totally - the people who know about it benefit - but it's extremely far from safe. The only way to really enforce this is to add this kind of thing to your "main" remote repo that everyone pushes to.
- xmodem 5y agoI've probably done it a bunch of times on my side projects too, but in any environment where code review is enforce you should probably be enforcing using the tooling to do the merge too, and not giving individual developers permission to push to the main branch.
- TomSwirly 5y ago"Don't do that" is not a good solution to errors which are hard to spot and easy to make!
- joshka 5y agoThe other part is - merging is software development, write a commit message better than "Merge branch 'foo' into main" e.g. Add new feature foo to main menu ...