4 ms·

> arguably I shouldn't have all these long-lived branches in the first place This is the problem here. If you have multiple long-lived branches, there's no te

> arguably I shouldn't have all these long-lived branches in the first place This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync. Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution.

pqdbr 4y ago
How do you constantly rebase on top of main if more than one person is working on the feature branch?
- couchand 4y ago
  recursion
  - simiones 4y ago
    What does that mean in the context of git?
    - couchand 4y ago
      There is nothing special about the main branch! This is the recipe to collaborate in git: - Pick a shared branch to work on. - Work. - If you complete within a day, push to shared branch. - If you need to hold onto it longer, make a new branch, switch to it. - (Possibly recurse.) - Complete work, rebase new branch on shared branch, push. And of course feel free to replace branch with remote/branch. It is distributed, after all, nothing special about any particular server. A worked example, to make it more concrete: - Pick the shared branch main. - Work on a feature for more than a day, so: - Create a feature branch feature/e2ee, switch to it. - Recurse, since you'll be doing database updates and I'm adding the UI. - Pick the shared branch feature/e2ee. - I create a branch git.sr.ht/~couch/new-twitter/feature/e2ee - You work and push to feature/e2ee. - I complete my work, rebase the branch, and push to feature/e2ee. - We are satisfied that we've completed the feature, rebase and push to main.
      - simiones 4y ago
        That doesn't really solve much: if both you and I rebase our personal feature branches onto master at different places, when we both try to push to the shared feature branch, we'll have a REALLY bad time - especially if we actually had to do conflict resolution.
MaxBarraclough 4y ago
> If you have multiple long-lived branches, there's no technical > solution to preventing rot -- you must actively keep them in sync. Rebasing isn't an alternative to this, it's just a different way of manually keeping in sync. > Regularly merging in main is the opposite of the proper solution. > Constantly rebasing on top of main is the proper solution. Why? You've given no justification for your preference.
- couchand 4y ago
  > Rebasing isn't an alternative to this, it's just a different way of manually keeping in sync. I never said it was, I said it was the right way to keep them in sync. > Why? You've given no justification for your preference. I don't need to, the GGGGP said it perfectly: https://news.ycombinator.com/item?id=33705026 https://news.ycombinator.com/item?id=33705026
  - jacobsenscott 4y ago
    A rebase and a merge result in the same code. A rebase is more error prone though. Just because someone "feels" a merge isn't as safe doesn't make it so.
    - couchand 4y ago
      > A rebase and a merge result in the same code. If done correctly, that's true, but it's beside the point. The reason to prefer one over the other is the failure mode. > A rebase is more error prone though. On what metric? In my experience, a merge is far, far more likely to silently introduce a production bug. I've never seen a rebase fail that way.
      - simiones 4y ago
        Doesn't rebase use the exact same automatic merge algorithm as a merge? They are equally as likely to introduce a production bug. Especially if adding a tool like rerere into the mix to do even more auto-magic merging when you hit the differences between rebase and merge.
Beltalowda 4y ago
> This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync. Well, merge actually works much smoother and rebase gives a lot more grief, so the problem is with rebase. > Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution. The "proper" solution is the one that allows me to get stuff done. The only thing that matters is how the main branch ends up looking in the end, and what I do before that isn't really all that important. Another problem with rebase is when multiple people are working on the branch; it requires careful coordination if you don't want to lose work. Overall, just merge in main is usually the best strategy here.
- couchand 4y ago
  Always surprising when folks are confused about how to collaborate on git branches... I'd expect the recursive solution to be more obvious! > The "proper" solution is the one that allows me to get stuff done. Yeah, but the stuff that needs to get done doesn't end with your commit, it starts there. Merge commits are prone to introduce unexpected and uncaught bugs: rebases just don't.
  - Beltalowda 4y ago
    > Merge commits are prone to introduce unexpected and uncaught bugs: rebases just don't. How so? If I make an error with a rebase then I risk losing my changes. You can fetch it from the local reflog, but that's not so easy. With a merge I have a merge commit which records what was merged.
    - couchand 4y ago
      We're talking past each other. You're describing issues that come up during the git workflow. I'm talking about production bugs.
      - Beltalowda 4y ago
        You're being quite cryptic in this entire thread and I to be honest I have no idea what you're talking about any more.

pqdbr 4y ago

How do you constantly rebase on top of main if more than one person is working on the feature branch?

couchand 4y ago
recursion
- simiones 4y ago
  What does that mean in the context of git?
  - couchand 4y ago
    There is nothing special about the main branch! This is the recipe to collaborate in git: - Pick a shared branch to work on. - Work. - If you complete within a day, push to shared branch. - If you need to hold onto it longer, make a new branch, switch to it. - (Possibly recurse.) - Complete work, rebase new branch on shared branch, push. And of course feel free to replace branch with remote/branch. It is distributed, after all, nothing special about any particular server. A worked example, to make it more concrete: - Pick the shared branch main. - Work on a feature for more than a day, so: - Create a feature branch feature/e2ee, switch to it. - Recurse, since you'll be doing database updates and I'm adding the UI. - Pick the shared branch feature/e2ee. - I create a branch git.sr.ht/~couch/new-twitter/feature/e2ee - You work and push to feature/e2ee. - I complete my work, rebase the branch, and push to feature/e2ee. - We are satisfied that we've completed the feature, rebase and push to main.
    - simiones 4y ago
      That doesn't really solve much: if both you and I rebase our personal feature branches onto master at different places, when we both try to push to the shared feature branch, we'll have a REALLY bad time - especially if we actually had to do conflict resolution.

MaxBarraclough 4y ago

> If you have multiple long-lived branches, there's no technical > solution to preventing rot -- you must actively keep them in sync. Rebasing isn't an alternative to this, it's just a different way of manually keeping in sync. > Regularly merging in main is the opposite of the proper solution. > Constantly rebasing on top of main is the proper solution. Why? You've given no justification for your preference.

couchand 4y ago
> Rebasing isn't an alternative to this, it's just a different way of manually keeping in sync. I never said it was, I said it was the right way to keep them in sync. > Why? You've given no justification for your preference. I don't need to, the GGGGP said it perfectly: https://news.ycombinator.com/item?id=33705026 https://news.ycombinator.com/item?id=33705026
- jacobsenscott 4y ago
  A rebase and a merge result in the same code. A rebase is more error prone though. Just because someone "feels" a merge isn't as safe doesn't make it so.
  - couchand 4y ago
    > A rebase and a merge result in the same code. If done correctly, that's true, but it's beside the point. The reason to prefer one over the other is the failure mode. > A rebase is more error prone though. On what metric? In my experience, a merge is far, far more likely to silently introduce a production bug. I've never seen a rebase fail that way.
    - simiones 4y ago
      Doesn't rebase use the exact same automatic merge algorithm as a merge? They are equally as likely to introduce a production bug. Especially if adding a tool like rerere into the mix to do even more auto-magic merging when you hit the differences between rebase and merge.

Beltalowda 4y ago

> This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync. Well, merge actually works much smoother and rebase gives a lot more grief, so the problem is with rebase. > Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution. The "proper" solution is the one that allows me to get stuff done. The only thing that matters is how the main branch ends up looking in the end, and what I do before that isn't really all that important. Another problem with rebase is when multiple people are working on the branch; it requires careful coordination if you don't want to lose work. Overall, just merge in main is usually the best strategy here.

couchand 4y ago
Always surprising when folks are confused about how to collaborate on git branches... I'd expect the recursive solution to be more obvious! > The "proper" solution is the one that allows me to get stuff done. Yeah, but the stuff that needs to get done doesn't end with your commit, it starts there. Merge commits are prone to introduce unexpected and uncaught bugs: rebases just don't.
- Beltalowda 4y ago
  > Merge commits are prone to introduce unexpected and uncaught bugs: rebases just don't. How so? If I make an error with a rebase then I risk losing my changes. You can fetch it from the local reflog, but that's not so easy. With a merge I have a merge commit which records what was merged.
  - couchand 4y ago
    We're talking past each other. You're describing issues that come up during the git workflow. I'm talking about production bugs.
    - Beltalowda 4y ago
      You're being quite cryptic in this entire thread and I to be honest I have no idea what you're talking about any more.