Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
I often find it useful to arrange things so that each commit on master's first-parent is a discrete change. It allows git log --first-parent --oneline to be used as a concise, automatically-generat...
#2: Post edited
I often find it useful to arrange things so that each commit on master's first-parent is a discrete change. It allows `git log --first-parent --oneline` to be used as a concise, automatically-generated changelog. There are various ways this can get screwed up. The one I'm most aware of arises from rhombus topologies, where master was merged into a topic branch, perhaps to resolve merge conflicts ahead of submitting a PR: ``` A---B---D <----master \ \ E---F---G <---topic ``` Here, when merging topic back into master, you get a fast-forward merge by default, and the resulting parents are backwards. On the other hand, if you avoid fast-forward merges, you get useless merge bubbles instead. That's not ideal, either: ``` A---B---C <----master \ / \ / d e ``` I would like to set things up so that, by default, parent swapping doesn't happen and merge-bubbles are avoided. I'd like this policy to "travel with the repo", so my teammates don't have to worry about whether they're doing the right thing. Is this possible? As I understand it, git has hooks for controlling its behavior, but I don't know if this is a thing they can do.
#1: Initial revision
How do I customize merge behavior for a shared git repo?
I often find it useful to arrange things so that each commit on master's first-parent is a discrete change. It allows `git log --first-parent --oneline` to be used as a concise, automatically-generated changelog. There are various ways this can get screwed up. The one I'm most aware of arises from rhombus topologies, where master was merged into a topic branch, perhaps to resolve merge conflicts ahead of submitting a PR: ``` A---B---D <----master \ \ E---F---G <---topic ``` Here, when merging topic back into master, you get a fast-forward merge by default, and the resulting parents are backwards. On the other hand, if you avoid fast-forward merges, you get useless merge bubbles instead. That's not ideal, either: ``` A---B---C <----master \ / \ / d e ``` I would like to set things up so that, by default, parent swapping doesn't happen and merge-bubbles are avoided. I'd like this policy to "travel with the repo", so my teammates don't have to worry about whether they're doing the right thing. Is this possible? As I understand it, git has hooks for controlling its behavior, but I don't know if this is a thing they can do.