4 ms·

> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave

> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. I think that only happens when you work on code as text files (i.e character streams) instead of code (i.e structured content with meaning). Like you have commit A and commit B that is in conflict, you should be glad because that's a rough signal that the intent of A and B differs. Your goal should be to think about how to compose A and B so that both intent survives (unless one supersedes the other). Which means you should be at least familiar with A and B. The issue I found with people that fears conflict is that they often don't understand either A or B (or both). So they are a bad candidate to actually do the operation. It's not a matter of git's cli interface, it's a matter of codebase comprehension and how well you're familiar with the changes in question.

thfuran 3mo ago
Git is the one treating code like a text file instead of code.
- UnfitFootprint 3mo ago
  I pull out difftastic when it’s all too hard for this. Diffs based off tree sitter
  - NateEag 3mo ago
    Don't forget mergiraf, for tree-sitter-based conflict resolution: https://mergiraf.org/ https://mergiraf.org/
    - klibertp 3mo ago
      I absolutely love the images on the landing page. "Inappropriate use of blame, push and pull to resolve a conflict" is pure genius. Even the name had a lot of thought put into it (didn't know about "Giraffe language" before). Beautiful! :)
      - NateEag 3mo ago
        The documentation is truly a thing of beauty. As someone who learned a lot from Non-Violent Communication, discovering mergiraf went something like > ...oh, cool - I've wanted this for years, great that someone buckled down and wrote it. > > Why 'mergiraf,' though? > > [Sees NVC link on the site] > > ...OH. Conflict resolution through understanding. That's absolutely brilliant, at so many levels.
- skydhash 3mo ago
  Git store whole files. The diff and the merge algorithm works by line by default, but that's because line is a rough unit of code (statement, expression, and definition happens mostly within one line).
bulatb 3mo ago
I can fully understand a conflict, know it's coming, and fear it anyway because I'll have to deal with Git's behavior to fix it.
- seba_dos1 3mo ago
  Such as? When you merge a commit in that changed a file that has been already changed since the common ancestor, Git runs a tool of your choice on this file. If the tool fails, it marks the file as needing a merge and doesn't let you commit it until you unmark it to confirm that you have merged it manually. In case of octopus merges, it will just abort early. That's basically its whole behavior when it comes to conflicts.
  - bulatb 3mo ago
    Such as moving down a fixup during interactive rebase when it's going to conflict with parents, or I've added more commits mid-rebase, or the rebase started in a tool and now I need to think about the tool's command and understand how many times the rebase point is view is backwards to interpret which is "ours" and which is "theirs" and whether it's the tool, my editor, or my own experience I should ignore because it's going to mislead me. None of that word salad should matter, but it does. Git will ruin everything with glee and there is always an excuse for why that's fine and it's the user's fault.
    - seba_dos1 3mo ago
      There's nothing "backwards" in "rebase point of view". It's just automated cherry-picking - it's like applying patches, it's as forwards as it gets. People who think it's "backwards" usually just have holes in their mental model of the repository. And yes, I find tools doing what you're asking them to do to be rather fine. In fact, Git makes it easy to notice when you're adding commits mid-rebase, which is something I often do intentionally, as it tells you what the HEAD is (and even shows a detailed state of the in-progress rebase) while authoring the commit message.
      - 3mo ago

thfuran 3mo ago

Git is the one treating code like a text file instead of code.

UnfitFootprint 3mo ago
I pull out difftastic when it’s all too hard for this. Diffs based off tree sitter
- NateEag 3mo ago
  Don't forget mergiraf, for tree-sitter-based conflict resolution: https://mergiraf.org/ https://mergiraf.org/
  - klibertp 3mo ago
    I absolutely love the images on the landing page. "Inappropriate use of blame, push and pull to resolve a conflict" is pure genius. Even the name had a lot of thought put into it (didn't know about "Giraffe language" before). Beautiful! :)
    - NateEag 3mo ago
      The documentation is truly a thing of beauty. As someone who learned a lot from Non-Violent Communication, discovering mergiraf went something like > ...oh, cool - I've wanted this for years, great that someone buckled down and wrote it. > > Why 'mergiraf,' though? > > [Sees NVC link on the site] > > ...OH. Conflict resolution through understanding. That's absolutely brilliant, at so many levels.
skydhash 3mo ago
Git store whole files. The diff and the merge algorithm works by line by default, but that's because line is a rough unit of code (statement, expression, and definition happens mostly within one line).

bulatb 3mo ago

I can fully understand a conflict, know it's coming, and fear it anyway because I'll have to deal with Git's behavior to fix it.

seba_dos1 3mo ago
Such as? When you merge a commit in that changed a file that has been already changed since the common ancestor, Git runs a tool of your choice on this file. If the tool fails, it marks the file as needing a merge and doesn't let you commit it until you unmark it to confirm that you have merged it manually. In case of octopus merges, it will just abort early. That's basically its whole behavior when it comes to conflicts.
- bulatb 3mo ago
  Such as moving down a fixup during interactive rebase when it's going to conflict with parents, or I've added more commits mid-rebase, or the rebase started in a tool and now I need to think about the tool's command and understand how many times the rebase point is view is backwards to interpret which is "ours" and which is "theirs" and whether it's the tool, my editor, or my own experience I should ignore because it's going to mislead me. None of that word salad should matter, but it does. Git will ruin everything with glee and there is always an excuse for why that's fine and it's the user's fault.
  - seba_dos1 3mo ago
    There's nothing "backwards" in "rebase point of view". It's just automated cherry-picking - it's like applying patches, it's as forwards as it gets. People who think it's "backwards" usually just have holes in their mental model of the repository. And yes, I find tools doing what you're asking them to do to be rather fine. In fact, Git makes it easy to notice when you're adding commits mid-rebase, which is something I often do intentionally, as it tells you what the HEAD is (and even shows a detailed state of the in-progress rebase) while authoring the commit message.
    - 3mo ago