4 ms·

> I want the 'merge' function completely deprecated. I simply don't trust it anymore. Merge is perfectly fine and it is the only way to synchronize repositorie

by GuB-42 4y ago

> I want the 'merge' function completely deprecated. I simply don't trust it anymore. Merge is perfectly fine and it is the only way to synchronize repositories without changing the history, which is very important for a decentralized system. It certainly has the potential to make a mess if used improperly, but so do rebase, cherry-pick, and basically every other command. > If you use merge to sync two branches continously, you completely lose track of what changes were done on the branch and which where done on the mainline. If you do things correctly, that is by making sure that when you merge changes from a feature branch into the mainline, the mainline is always the first parent, you shouldn't have any problem. Git is designed this way, so normally, you have to go out of your way to mess things up. If did it like that and you don't want to see the other branch commits, git-log has the --first-parent option.

benatkin 4y ago
Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push your non-main branch, you review the diff in the PR.
- couchand 4y ago
  Then you don't actually need merge? Am I missing something? If you always rebase the branch, the commits can be applied directly.
  - xxpor 4y ago
    if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.
    - couchand 4y ago
      Totally on board (except the forbidden -a switch). The last command is: cp .git/refs/heads/feature .git/refs/heads/main No merge needed.
      - xxpor 4y ago
        Touching files in .git (outside of like, .git/config) directly gives me the heebee jeebees
        couchand 4y ago
        Fair point, and I would not advocate that specific workflow! My point was just to illustrate that we can live without merge.
      - a_t48 4y ago
        git reset --hard main feature
    - micw 4y ago
      Rather than switching to "main" and pull it, you can just stay in "feature" and do a fetch followed by "rebase origin/main". Then pull "main" before you merge the feature. I'd also use "merge --no-ff" to force an empty commit that visualizes where a feature begins and ends.
  - benatkin 4y ago
    You're missing the merge commits. `git log` is a key feature and merges belong there, at least in my workflow.
cerved 4y ago
way easier to mess up a rebase
- couchand 4y ago
  way easier to tell that you've messed up a rebase
  - cerved 4y ago
    it's actually way easier to accidentally mess up a rebase, especially if rearranging commits. I can recommend git diff @{1} post rebase I alias it to d-
    - couchand 4y ago
      I'm not sure if you misread my comment, but my point was that it's far too easy to accidentally introduce bugs in merge commits that go unnoticed for a long time. I've never seen a rebase gone awry introduce production bugs, but I've known multiple gnarly bugs caused by errant merges. YMMV.
      - cerved 4y ago
        as always, different circumstances can generate different results. In a merge, you solve conflicts once. Whereas in a rebase, those conflicts will turn into incremental conflicts. If the branch history is "tidy", with discrete, purposeful commits, this can be easier. Especially if incrementally rebasing. The main difference is one rewrites history and the other does not. A rebase is by nature destructive and as such can introduce subtle changes in the process, especially if commits are reordered / modified in the process
        couchand 4y ago
        It's not really destructive, though! That's not really the main difference. The main difference is that a merge sticks around in your repo forever, a commit that people assume has no real code changes in it but actually sometimes it does. A rebase is done once, and then your git history doesn't have to deal with it ever again. Yes, you raise a fair point that if you've dug yourself into a deep pit already with long-lived branches and overlapping work, it might be slightly easier to extract yourself from the pit with a merge. But then you're leaving that fetid pit in your repository forever.

by GuB-42 4y ago

benatkin 4y ago

Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push your non-main branch, you review the diff in the PR.

couchand 4y ago
Then you don't actually need merge? Am I missing something? If you always rebase the branch, the commits can be applied directly.
- xxpor 4y ago
  if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.
  - couchand 4y ago
    Totally on board (except the forbidden -a switch). The last command is: cp .git/refs/heads/feature .git/refs/heads/main No merge needed.
    - xxpor 4y ago
      Touching files in .git (outside of like, .git/config) directly gives me the heebee jeebees
      - couchand 4y ago
        Fair point, and I would not advocate that specific workflow! My point was just to illustrate that we can live without merge.
    - a_t48 4y ago
      git reset --hard main feature
  - micw 4y ago
    Rather than switching to "main" and pull it, you can just stay in "feature" and do a fetch followed by "rebase origin/main". Then pull "main" before you merge the feature. I'd also use "merge --no-ff" to force an empty commit that visualizes where a feature begins and ends.
- benatkin 4y ago
  You're missing the merge commits. `git log` is a key feature and merges belong there, at least in my workflow.

cerved 4y ago

way easier to mess up a rebase

couchand 4y ago
way easier to tell that you've messed up a rebase
- cerved 4y ago
  it's actually way easier to accidentally mess up a rebase, especially if rearranging commits. I can recommend git diff @{1} post rebase I alias it to d-
  - couchand 4y ago
    I'm not sure if you misread my comment, but my point was that it's far too easy to accidentally introduce bugs in merge commits that go unnoticed for a long time. I've never seen a rebase gone awry introduce production bugs, but I've known multiple gnarly bugs caused by errant merges. YMMV.
    - cerved 4y ago
      as always, different circumstances can generate different results. In a merge, you solve conflicts once. Whereas in a rebase, those conflicts will turn into incremental conflicts. If the branch history is "tidy", with discrete, purposeful commits, this can be easier. Especially if incrementally rebasing. The main difference is one rewrites history and the other does not. A rebase is by nature destructive and as such can introduce subtle changes in the process, especially if commits are reordered / modified in the process
      - couchand 4y ago
        It's not really destructive, though! That's not really the main difference. The main difference is that a merge sticks around in your repo forever, a commit that people assume has no real code changes in it but actually sometimes it does. A rebase is done once, and then your git history doesn't have to deal with it ever again. Yes, you raise a fair point that if you've dug yourself into a deep pit already with long-lived branches and overlapping work, it might be slightly easier to extract yourself from the pit with a merge. But then you're leaving that fetid pit in your repository forever.