this post was submitted on 04 Apr 2024
1100 points (98.1% liked)
Programmer Humor
19623 readers
2719 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Your notation does not make sense. You're representing a multi-dimensional thing in one dimension. Of course it's a mess if you do that.
Your example is also missing a crucial fact required when reasoning about merges: The merge base.
Typically a branch is "branched off" from some commit M. D's and A's parent would be M (though there could be any amount of commits between A and M). Since A is "on the main branch", you can conclude that D is part of a "patch branch". It's quite clear if you don't omit this fact.
I also don't understand why your example would have multiple merges.
Here's my example of a main branch with a patch branch; in 2D because merges can't properly be represented in one dimension:
If you use a feature branch workflow and your main branch is merged into, you typically want to use first-parent bisects. They're much faster too.
You're right, I'm not representing the merge correctly. I was thinking of having multiple merges because for a long running patch branch you might merge main into the patch branch several times before merging the patch branch into main.
I'm so used to rebasing I forgot there's tools that correctly show all the branching and merges and things.
Idk, I just like rebase's behavior over merge.
The thing is, you can get your cake and eat it too. Rebase your feature branches while in development and then merge them to the main branch when they're done.
👏 Super duper this is the way. No notes!