4 ms·

> Churn from other dev's stuff gets in your merge/rebase work Wouldn't other people' work only cause issues if they are changing the same files, in which case

by ht85 6y ago

> Churn from other dev's stuff gets in your merge/rebase work Wouldn't other people' work only cause issues if they are changing the same files, in which case conflicts would happen even if the work is spread in multiple repos?

grey-area 6y ago
yes, this isn't really an objection.
lallysingh 6y ago
Good point. I've gotten hit by this in monorepos but I probably just tried to merge instead of rebase. Both are crazy painful on large source bases. It still takes forever! I should replace that with 'most commits in history are irrelevant to you, so you have to dig smarter to understand what's been going on with your components'
- nendroid 6y ago
  Invest in using a gui merge tool. It makes this process 10x easier. Also your complaint is unrelated to monorepos vs. multiple repos. Additionally rebase or merge won't make the conflict issue go away. I recommend companies stop using rebase as it produces an in accurate history of what's going on in your git history.
  - lallysingh 6y ago
    I'm a magit-er now. In multiple repos, the history for one repo is limited to that repo, which is usually more topical for people working on it. If I've got changes on an old version of the repo, and try to merge against a new one, I find conflicts in the changes others have made to the same repo -- I have the 'before' version, they have the 'after'. I frankly don't investigate too much when it hits. As for history, I love rebase for two reasons: (1) I can squash mistakes in my history so they're gone forever. (2) In reconciliation I'm watching my changes filter through the history of the repo. When I understand what's up, this is great. When I don't, it's a catastrophe of me re-applying changes that haven't actually been applied yet, then conflicting with their application later. Ugh.
GuB-42 6y ago
Here is the problem: 1- You finished your work, so you pull from the central repository, and merge your your branch to the master 2- You do your merge work, test it a bit and commit 3- Now, you push and oops, another team did the same, you are now left with to heads 4- You merge or rebase the two heads. Probably a simple task, but you may still need to run some tests again. And if you are lucky, you are done, otherwise, back to step 3 Also, if you are rebasing before push, you should be able to keep a clean history. However, if you are merging, and there are good reasons for a "merge only" policy, you are going to have a mess of merge commits every time the previous situation happens. That's something you can work around with good management. But the more freedom you give individual teams to push to the common branches, the more that situation will arise, the more you try to control access, the more chance you will have for teams to go in different directions, making the merges infrequent but tricky.
- user5994461 6y ago
  The CI should run tests and take care of merging to master, only after the tests passed. This avoids most problems.
- cs-szazz 6y ago
  When you say "But the more freedom you give individual teams to push to the common branches", what do you mean? I've typically only seen CI merge to master, and disable pushing.
jayd16 6y ago
I think it can still happen though. Imagine you're in a branch for large project P. You want to merge to trunk but there are conflicts. The upstream library project L was changed in your branch but not in merged down by the submitter. Even if P simply relies on a binary of L that is already in the artifact store, you still have to deal with merging this code down when normally you wouldn't. In fact, the much bigger issue is that you now must deal with the double edged sword of updating the entire org when a shared dependency must be updated. Perhaps you even completed that task in your project branch. Now you get to deal with merging into every project in the org that was touched.
pletnes 6y ago
Github (might depend on settings) refuse to merge if your branch is out of date. Rebasing on master re-triggers CI/CD. Might cause lots of waiting for this case...

by ht85 6y ago

grey-area 6y ago

yes, this isn't really an objection.

lallysingh 6y ago

Good point. I've gotten hit by this in monorepos but I probably just tried to merge instead of rebase. Both are crazy painful on large source bases. It still takes forever! I should replace that with 'most commits in history are irrelevant to you, so you have to dig smarter to understand what's been going on with your components'

nendroid 6y ago
Invest in using a gui merge tool. It makes this process 10x easier. Also your complaint is unrelated to monorepos vs. multiple repos. Additionally rebase or merge won't make the conflict issue go away. I recommend companies stop using rebase as it produces an in accurate history of what's going on in your git history.
- lallysingh 6y ago
  I'm a magit-er now. In multiple repos, the history for one repo is limited to that repo, which is usually more topical for people working on it. If I've got changes on an old version of the repo, and try to merge against a new one, I find conflicts in the changes others have made to the same repo -- I have the 'before' version, they have the 'after'. I frankly don't investigate too much when it hits. As for history, I love rebase for two reasons: (1) I can squash mistakes in my history so they're gone forever. (2) In reconciliation I'm watching my changes filter through the history of the repo. When I understand what's up, this is great. When I don't, it's a catastrophe of me re-applying changes that haven't actually been applied yet, then conflicting with their application later. Ugh.

GuB-42 6y ago

Here is the problem: 1- You finished your work, so you pull from the central repository, and merge your your branch to the master 2- You do your merge work, test it a bit and commit 3- Now, you push and oops, another team did the same, you are now left with to heads 4- You merge or rebase the two heads. Probably a simple task, but you may still need to run some tests again. And if you are lucky, you are done, otherwise, back to step 3 Also, if you are rebasing before push, you should be able to keep a clean history. However, if you are merging, and there are good reasons for a "merge only" policy, you are going to have a mess of merge commits every time the previous situation happens. That's something you can work around with good management. But the more freedom you give individual teams to push to the common branches, the more that situation will arise, the more you try to control access, the more chance you will have for teams to go in different directions, making the merges infrequent but tricky.

user5994461 6y ago
The CI should run tests and take care of merging to master, only after the tests passed. This avoids most problems.
cs-szazz 6y ago
When you say "But the more freedom you give individual teams to push to the common branches", what do you mean? I've typically only seen CI merge to master, and disable pushing.

jayd16 6y ago

I think it can still happen though. Imagine you're in a branch for large project P. You want to merge to trunk but there are conflicts. The upstream library project L was changed in your branch but not in merged down by the submitter. Even if P simply relies on a binary of L that is already in the artifact store, you still have to deal with merging this code down when normally you wouldn't. In fact, the much bigger issue is that you now must deal with the double edged sword of updating the entire org when a shared dependency must be updated. Perhaps you even completed that task in your project branch. Now you get to deal with merging into every project in the org that was touched.

pletnes 6y ago

Github (might depend on settings) refuse to merge if your branch is out of date. Rebasing on master re-triggers CI/CD. Might cause lots of waiting for this case...