Comment by bjackman
7 days ago
You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?
7 days ago
You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?
What do you mean by "stack" MRs?
Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master.
Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history.
This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff.
If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
You can "chain" them and there's some native support for this in Gitlab, but I can't say I've ever tried using it. If I really need a feature branch, I just create a separate branch and target my MR's to that until the whole thing is ready to land in main. Again, it seems less natural to me than how Gerrit does it.