-1

I use stacked branches as I develop main <- feature1 <- feature2 ..., as well as stacked prs with feature2 pr'd against feature1 and so on. My company uses squash merge when going into main i.e. in github ( actually gitlab ) when you merge your pr it squashes all the commits into one and merges that. So when I try to merge main back into feature2 it's a total mess of conflicts becacuse feature2 has e.g. 5 commits from feature1 but main has only 1 commit with all the same changes.

After scouring the web what I've seen is that there is a very cumbersome almost unusable way of dealing with this using rebase and moving branch heads etc. There is also a new feature called update-refs which "handles" some of that mess for you.

My question is, 1) is there no other way to handle this situation that can be a bit more automatic or less painful. 2) if rebase --update-refs is the only way can someone list out some commands that would facilitate this. Here are some of the issues:

  1. is there a command that will make it crystal clear what branches are stacked upon each other, which is the top which is the bottom and what are the commits in between that I have contributed and might need to move down.
  2. if there is a conflict between feature 1 and feature 2 how can I avoid resolving that conflict for every bloody commit between feature 1 and feature 5
  3. is there a way to programatically walk up the chain of branches to find the most upstream branch and the most downstream branch so I can say "git checkout most downStreamBranch; git rebase --update-refs mostDownStreamBranch;
  4. if someone is doing this routine, can you share in detail your routine?

If this ? looks familiar it's cuz I just asked it a couple days ago and they closed it saying it was dupe of a very basic question about how to merge branches. I couldn't get it re opened so I'm trying again. thanks.

Raif
  • 8,641
  • 13
  • 45
  • 56
  • 1
    Yes, you indeed [asked this](https://stackoverflow.com/questions/76267475/squashed-prs-are-causing-major-conflicts-in-my-stacked-branches) a little while ago and this is not a new question, just a rehash of the original question + asking whether the tips you got on that original question are what you *really* need to do (because you don’t like them). I don’t think I need to comment on this beyond that (to express myself clearly). – Guildenstern May 18 '23 at 14:15
  • Hey, I appreciated your response and wanted to discuss it with you, but they closed it. I'm sorry. My understanding is that question is gone and there will be no further activity on it. So I tried again. So, belatedly thanks for the tip, and I probably will use --update-refs I just want to make sure there aren't other alternatives – Raif May 18 '23 at 16:36
  • Relevant tool: [git-assembler](https://www.thregr.org/~wavexx/software/git-assembler/) (never tried) – Guildenstern May 18 '23 at 16:43
  • Wow, that's quite a lib. font was kind of making me crazy, but looks like there's some interesting stuff there including the underlying idea of basically a make file for git. Thx – Raif May 18 '23 at 17:30
  • Our company recently started using [Graphite](https://graphite.dev/) with squash merge and Graphite can automatically resolve the conflicts for stacked branches. It's an extremely opinionated tool, only supports Github and it's still in its early stage. It should work fine if you are the only person working on the stack. As soon as other people start making changes (even if they're also using Graphite), you will be hit with different weird issues. I can't really recommend it at this stage, but it's indeed a tool that can resolve those conflicts – Yihao Gao Aug 15 '23 at 08:46

1 Answers1

1

My company uses squash merge

Yup. Well, if you don't want those conflicts, don't do that. It's a very bad policy. And what you are describing is one of the main reasons it's bad: if a branch (or a branch and its sub-branches) is long-lived and so gets merged in multiple times, merge conflicts are virtually inevitable. (If you don't understand why, read my https://www.biteinteractive.com/understanding-git-merge/.)

So, you need to either stop making stacked branches or else persuade your "company" to use real merges.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • Taxation with out representation is also bad. What do you do? You could rebel, throw the tea in the harbor etc, but that's a pretty big action. Before you get there you must find ways to avoid paying those taxes, or to be more represented ... whatever, what I mean is, I can quit, or I can fight and probably be fired, or I can find ways to deal with the current state of affairs. Sorry about the analogy, too much coffee. – Raif May 18 '23 at 14:18
  • 1
    Well the third option is to shrug and live with the merge conflicts. – matt May 18 '23 at 15:53
  • 1
    Although it's implied by this answer, to be clear, the problem isn't using squash merge, and the problem isn't stacked branches. The problem is the combination of stacked branches and squash merging. – TTT May 18 '23 at 16:35
  • I"m curious how people work if the they don't do stacked branches. Given you are on a team not doing solo work. But perhaps this isn't the correct venue for that discussion. – Raif May 18 '23 at 16:38
  • 1
    @Raif I rarely do stacked branches. Most of my workflows use rebase of feature branches, so we have the same conceptual problem as squash merge. So I rarely ever stack branches. If I find myself needing to work on something that depends on something else with a pending PR, I'll try to wait until that PR gets completed and work on something else. If I can't wait, then I just `rebase --onto` after the PR is completed. (This may be the makings of a second answer...) – TTT May 18 '23 at 16:41
  • 1
    I do stacked branches all the time. But our merges are true merges. _Hence the duplicate I linked you to on the previous question_ which describes our workflow. – matt May 18 '23 at 16:57
  • Well, I guess the distinguishing factor is that I do, and am forced to do squashed merges. As is clear, this creates a problem that I am trying to solve and looking for feedback on. – Raif May 18 '23 at 17:20
  • 1
    You're getting that feedback. – matt May 18 '23 at 17:29
  • See also https://git-scm.com/docs/gitfaq#Documentation/gitfaq.txt-Whatkindsofproblemscanoccurwhenmerginglong-livedbrancheswithsquashmerges – matt Jun 10 '23 at 14:27