3 ms·

The idea is pleasing, but when you specifically look at Git, its UX is rather disappointing. I'm not even talking about the CLI (after a while you can get used

The idea is pleasing, but when you specifically look at Git, its UX is rather disappointing. I'm not even talking about the CLI (after a while you can get used to it). I'm talking about resolving conflicts. If I have a sequence of changes A -> B -> C, then I change A and rebase B on top of A resolving any conflicts, then rebasing C on top of B will most of the time mean that Git will most likely ask me to resolve the same conflicts all over again and more. The kind of conflicts is also staggering. Each time I look at the conflicts it generated, I cannot explain how it could come up with that craziness. And all the while it also merged some changes without signalling conflicts, but instead breaking something in significant ways, without notifying me in any way, i.e. silently breaking something potentially important. From what I've read, Pijul should fix at least the problem of needing to resolve the same conflicts multiple times over and over again. However, I feel that version control focused on text breaks, because the merging algorithm doesn't know anything about the semantics of what's represented in text. So yes, I'd say that version control in more areas would be nice, but one based on binary formats understood by version control. One glimpse of that may be KeePassXC, which can merge password databases and has never done it wrong in my experience.

vlovich123 5y ago
Have you tried git rere?
- yakubin 5y ago
  No. That's the first I'm hearing of it. Thanks. I'll try it in the future.
Hackbraten 5y ago
While I agree in that Git’s UX is abysmal for the beginner or casual user, no one should have to endure resolving the same conflicts over and over again. In my opinion, the following configuration should have been the default with Git: git config --global rerere.enabled true git config --global rerere.autoUpdate true The `enabled` part means: transparently record all resolutions in a database, and re-apply them whenever bumping into the same conflict with the same pair of files in the future. The `autoUpdate` part means: every time you finish re-applying a recorded resolution, please `git add` the result automatically for me so I don’t have to look for a "conflict" that’s actually no longer there.
- FreezerburnV 5y ago
  I had no idea these options were a thing. Thank you for pointing them out, adding them to my config immediately and hoping it makes some merges and whatnot easier going forward.
  - pmeunier 5y ago
    Hint: rerere doesn't always work. It's still guesswork, like the rest of merges/rebases/cherry-picking in Git. This is because looking only at the tips of branches doesn't work, and that's the only thing Git can do (with or without diff3 as the merge algorithm).
    - Hackbraten 5y ago
      The rerere database is content-addressed, and rerere will apply a resolution only if the pair of conflicting files is a bit-exact déjà-vu of a conflict it has seen before. I don’t see how that is guesswork. My impression is that rerere is perfectly deterministic, and only repeat things the user has done before. The downside is: once the user has manually created a faulty resolution, then rerere will possibly replay that faulty resolution. That’s how things can go wrong, and I see how one might blame that failure on rerere itself. And I think the blame not entirely unjustified, because rerere could do a much better job in explaining how it interacts with certain scenarios. For example, let’s say I’m aborting a rebase. Will rerere roll back the resolutions it recorded? I honestly don’t know. The manpage vaguely claims that it will, but I’ve been unable to reproduce it. I wish rerere made more transparent how it interacts with `--abort`. Just printing an informational line would already go a long way. I also feel a command like `git rerere log`, which would print the recent activity of the `rerere` database, might help with that.
greyhair 5y ago
The git diff process and conflict process really goes off the rails at times, and I have never figured that out. Modify one line in a file, and add one new line two lines after that modification, and the git diff is two 40 line chunks with some common lines, a bunch of additions, and a bunch of deletions. Really? One new added line, and one delete/add two lines above it. it usually works fine, it really does, but when it messes up, it really messes up big time. As long as it doesn't create a conflict, you just shrug and move on, but when it does create a conflict, holy-moley!
Nullabillity 5y ago
The biggest UX sin of Git is that rebasing is featured so prominently. If you had just done a normal merge commit then Git could have realized the common history, done a three-way merge, and resolved the conflict automatically. But no, people always seem to insist on that linear history is the only concern that matters, explicitly delete the history, and then wonder why Git is so annoying and easy to screw up. Maybe Git should have locked rebase behind a feature flag of some kind. `git pull --rebase` should certainly never have been added.
- GrumpySloth 5y ago
  When I have a chain of commits pending review on Gerrit, and I fixed some flaws in the first commit in chain and need to rebase the dependent commits, merging is not an option. And rightly so: when I look at the master branch, I don't want to see random corrections someone made during review, they're just irrelevant once the reviewed changes are merged. There are many reasons why linear history is important. Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do. A merge would only make sure that I don't need to resolve the same conflict multiple times. It wouldn't result in the conflicts not being generated in the first place, or them being saner. The only difference in conflict resolution between rebasing and merging is that the sides are flipped (what's shown on left in rebase, is on the right in merge, and vice-versa). Which doesn't address the second issue I listed: conflicts are not only repeated, but the conflicts themselves are pretty crazy. In my example, often-times C would never even touch files which were detected as having conflicting changes with A or B. It was pretty absurd that I would have a 3-line change in C, several hundred-line changes in A and B, yet the biggest conflicts would be triggered when rebasing C on top of B, and those would be in files C did not touch. Other times diffs in conflicts would have most of the lines added and removed actually identical, with only a couple in the middle different. Why would git mark them as conflicting, is beyond me. And then there was the issue of git not detecting conflicts, when it should have, instead merging changes in a way that broke source code. None of those issues is better handled by merging than by rebasing. Most of them however have pretty good solutions in a patch-based version control system, as opposed to snapshot-based like git (conflicts in files which weren't changed? not going to happen). An even better solution would be binary formats with domain-specific merge logic, like the one in KeePassXC.
pmeunier 5y ago
> However, I feel that version control focused on text breaks, Pijul doesn't, by the way, the diff algorithm is customisable. I wrote one industrial application of Pijul that uses spaces as breaks, and semantics-aware breaking is totally doable.

vlovich123 5y ago

Have you tried git rere?

yakubin 5y ago
No. That's the first I'm hearing of it. Thanks. I'll try it in the future.

Hackbraten 5y ago

While I agree in that Git’s UX is abysmal for the beginner or casual user, no one should have to endure resolving the same conflicts over and over again. In my opinion, the following configuration should have been the default with Git: git config --global rerere.enabled true git config --global rerere.autoUpdate true The `enabled` part means: transparently record all resolutions in a database, and re-apply them whenever bumping into the same conflict with the same pair of files in the future. The `autoUpdate` part means: every time you finish re-applying a recorded resolution, please `git add` the result automatically for me so I don’t have to look for a "conflict" that’s actually no longer there.

FreezerburnV 5y ago
I had no idea these options were a thing. Thank you for pointing them out, adding them to my config immediately and hoping it makes some merges and whatnot easier going forward.
- pmeunier 5y ago
  Hint: rerere doesn't always work. It's still guesswork, like the rest of merges/rebases/cherry-picking in Git. This is because looking only at the tips of branches doesn't work, and that's the only thing Git can do (with or without diff3 as the merge algorithm).
  - Hackbraten 5y ago
    The rerere database is content-addressed, and rerere will apply a resolution only if the pair of conflicting files is a bit-exact déjà-vu of a conflict it has seen before. I don’t see how that is guesswork. My impression is that rerere is perfectly deterministic, and only repeat things the user has done before. The downside is: once the user has manually created a faulty resolution, then rerere will possibly replay that faulty resolution. That’s how things can go wrong, and I see how one might blame that failure on rerere itself. And I think the blame not entirely unjustified, because rerere could do a much better job in explaining how it interacts with certain scenarios. For example, let’s say I’m aborting a rebase. Will rerere roll back the resolutions it recorded? I honestly don’t know. The manpage vaguely claims that it will, but I’ve been unable to reproduce it. I wish rerere made more transparent how it interacts with `--abort`. Just printing an informational line would already go a long way. I also feel a command like `git rerere log`, which would print the recent activity of the `rerere` database, might help with that.

greyhair 5y ago

The git diff process and conflict process really goes off the rails at times, and I have never figured that out. Modify one line in a file, and add one new line two lines after that modification, and the git diff is two 40 line chunks with some common lines, a bunch of additions, and a bunch of deletions. Really? One new added line, and one delete/add two lines above it. it usually works fine, it really does, but when it messes up, it really messes up big time. As long as it doesn't create a conflict, you just shrug and move on, but when it does create a conflict, holy-moley!

Nullabillity 5y ago

The biggest UX sin of Git is that rebasing is featured so prominently. If you had just done a normal merge commit then Git could have realized the common history, done a three-way merge, and resolved the conflict automatically. But no, people always seem to insist on that linear history is the only concern that matters, explicitly delete the history, and then wonder why Git is so annoying and easy to screw up. Maybe Git should have locked rebase behind a feature flag of some kind. `git pull --rebase` should certainly never have been added.

GrumpySloth 5y ago
When I have a chain of commits pending review on Gerrit, and I fixed some flaws in the first commit in chain and need to rebase the dependent commits, merging is not an option. And rightly so: when I look at the master branch, I don't want to see random corrections someone made during review, they're just irrelevant once the reviewed changes are merged. There are many reasons why linear history is important. Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do. A merge would only make sure that I don't need to resolve the same conflict multiple times. It wouldn't result in the conflicts not being generated in the first place, or them being saner. The only difference in conflict resolution between rebasing and merging is that the sides are flipped (what's shown on left in rebase, is on the right in merge, and vice-versa). Which doesn't address the second issue I listed: conflicts are not only repeated, but the conflicts themselves are pretty crazy. In my example, often-times C would never even touch files which were detected as having conflicting changes with A or B. It was pretty absurd that I would have a 3-line change in C, several hundred-line changes in A and B, yet the biggest conflicts would be triggered when rebasing C on top of B, and those would be in files C did not touch. Other times diffs in conflicts would have most of the lines added and removed actually identical, with only a couple in the middle different. Why would git mark them as conflicting, is beyond me. And then there was the issue of git not detecting conflicts, when it should have, instead merging changes in a way that broke source code. None of those issues is better handled by merging than by rebasing. Most of them however have pretty good solutions in a patch-based version control system, as opposed to snapshot-based like git (conflicts in files which weren't changed? not going to happen). An even better solution would be binary formats with domain-specific merge logic, like the one in KeePassXC.

pmeunier 5y ago

> However, I feel that version control focused on text breaks, Pijul doesn't, by the way, the diff algorithm is customisable. I wrote one industrial application of Pijul that uses spaces as breaks, and semantics-aware breaking is totally doable.