7 ms·

>I will award honorary negative points for any client which dares to treat git rebase -i as if it were a fundamental primitive. If you think that a git rebase

by goku12 4y ago

>I will award honorary negative points for any client which dares to treat git rebase -i as if it were a fundamental primitive. If you think that a git rebase is overcomplicated, rather than a fundamental primitive, then you missed an important part of the tool. And phrasing it this way is an insult to anyone who really tried to understand the tool - kind of like the nerd badge in schools. Git rebase is fundamental to Git in many ways. It is also easy in many ways. At the minimum, it makes it easy to make mistakes while experimenting much less of a hassle, since the commit chain can be cleaned up later. However, the point here is that git rebase is more similar to what the kernel developers and git developers intended to do with the tool, compared to the commit-merge workflow. There are two aspects here: 1. The tool developers want every commit to be feature-complete and that it won't cause broken builds at least in the master branch. This is impossible to achieve in the regular commit-merge workflow.You need to add the interactive rebases to achieve the goal. 2. Git hides something behind the snapshot model it claims to be based on. The commits themselves are snapshots. But the way changes are propagated between commits (like stashing, commit amending, merging, cherry-picking, rebasing, squashing, splitting, etc) depend on plain old text diffs/patches. It takes a while for beginners to realize this. The kernel devs were using emailed patches and tools like quilt patch manager for nearly a decade before they created git. You can still see the influence of diff, diff3, merge and quilt in the design of git. Knowing this makes you much better at predicting the outcome of these operations. Blaming the tool without trying these techniques is very uncharitable indeed. I've been learning Pijul these days. All those complicated operations are condensed into a small set of commands in pijul. For one, it concentrates on patches only. I feel that part of Git's complexity is its mixing up of snapshot and patch model into a single program. Git didn't have the luxury of these diff alogrithms back then.

arxanas 4y ago
Rebasing is a fundamental primitive, but not Git's implementation of interactive rebasing. I very much subscribe to a "patch-stack" workflow, but have a great deal of difficulty doing advanced things in Git, because `git rebase`/`git rebase -i` do not support enough workflows. Here's some features I've implemented which improve on `git rebase` in general: https://github.com/arxanas/git-branchless/wiki/Command:-git-move#description https://github.com/arxanas/git-branchless/wiki/Command:-git-...
- treis 4y ago
  Really the fundamentals of git are nodes (commits) and how they connect to each other. Everything else is abstractions on that. Wonder if anyone has made a git client that lets you manipulate it at that level. Tree looking graph that allows you to drag connections to where you want them.
  - btschaegg 4y ago
    > Wonder if anyone has made a git client that lets you manipulate it at that level. I believe you're describing GitUp [1]. I can't really say much about it, though, as I've never used it myself (because it's OSX only). [1]: https://gitup.co/ https://gitup.co/
    - treis 4y ago
      Yep that's what I was thinking of. Will have to give it a try.
    - password4321 4y ago
      I Ctrl+F'd for GitUp based on the title, it deserves mention here. It's all-in on Mac, unfortunately. https://github.com/git-up/GitUp https://github.com/git-up/GitUp > GitUp is built as a thin layer on top of a [Mac-only] reusable generic Git toolkit called "GitUpKit".
- pama 4y ago
  Is there any workflow in particular that you are missing in an Emacs/magit combo? I’ve found it easy to add a couple extra lines of lisp to fetch upstreams regularly or to “sync” worktrees in various remotes. The most complicated things I’ve encountered have been conflict resolutions, however, the tools did their best to help.
dmix 4y ago
> I've been learning Pijul these days. I looked this up and Pijul is a "distributed version control system" being written in Rust: https://pijul.org/ https://pijul.org/
- goku12 4y ago
  There are some advantages of Pijul over Git - Worries only about patches, not about snapshots too - Only a few commands to learn. No complex switches - Combines many git approaches in one. For example: - pijul record (its commit) is an interactive code selection at the same time. - Merges and rebases are all the same (due to the way commits are linked)
- funnym0nk3y 4y ago
  There seems to be some stagnation in pijul. I don't know if that's normal in this kind of project or if it's a indication of the future.
  - goku12 4y ago
    The author has a habit of taking his work offline for months. Hopefully, that's what's going on now. They are so close to 1.0 with their work. I seriously doubt that project stagnated entirely.
  - pmeunier 4y ago
    I'm one of the main authors. No stagnation, the future is bright but I've been founding a small company recently, not related to Pijul. I've shown an MVP to customers three months ago, now I'm close to 1.0 there. I promise I'll move back to Pijul soon. Another issue is the Nest (our hosting service), I've been working on a new Nest that can benefit from being open source, unlike the current one. Another indication that it's doing alright: I'll give a talk about it at BOB 2023 (bobkonf.de), and an invited talk in April at Collège de France.
    - funnym0nk3y 4y ago
      First of all congratulations to shipping the first MVP! And I'm glad to hear that Pijul is very alive! No need to promise anything, I was just wondering. I can't wait until Pijul escapes the nice and grows in popularity.
rileymat2 4y ago
> since the commit chain can be cleaned up later. This seems to be one of the major divisions in SCM users, some see it as a clean up for seeing a understandable 'history', others see it as a falsification.
- arxanas 4y ago
  For example, Git is somewhat ambivalent on the topic, but Fossil SCM is notably very much against rebasing/rewriting history.
- avgcorrection 4y ago
  If you made one commit after this sequence of events 1. Worked 2. Grabbed a coffee 3. Worked again You are falsifying history. One commit or more per butt-in-seat mini session.[1] Anything else is borderline fraudulent. [1] Or per balls-of-feet in front of your standing desk, if that is how you roll.
  - rileymat2 4y ago
    I'd imagine the human psychology of this debate is quite a bit more complicated.
  - MereInterest 4y ago
    Falsifying history isn't wrong in itself. Falsifying a shared history is, because it breaks other copies of the repo. So long as a branch exists only in a single repo, then the history of that branch can be rewritten without issue. But a shared branch should never be rewritten, because you'd need to copy the alterations into all copies of the repo. I take issue with tools that prioritize rebasing, because they usually make this distinction between rebasing a local branch and rebasing a shared branch. For example, GitHub's "Squash and Merge" or "Rebase and Merge" options break the shared history between the remote copy of the repo and my local copy. After such an operation, I cannot merge from main into my development branch, and must instead rebase my development branch onto main.
    - atq2119 4y ago
rhaway84773 4y ago
Git is many tools. For the purpose of this discussion it’s at least the following 2 tools: 1. A source code control system which allows you to manage the history and branches of your code. 2. A source code collaboration system that allows you to share code with others. git rebase is excellent for (1). It could also be considered fundamental to it. I know I certainly use it a ton for this purpose and would find myself lost without it. Unfortunately git rebase completely breaks (2) and if all git was is (2) it would certainly be considered an anti-feature, if not a bug.
- FridgeSeal 4y ago
  > Unfortunately git rebase completely breaks (2) I’m not sure I follow the logic? What is it about rebase that makes sharing difficult? Isn’t rebase just a merge strategy? And if you have code in a branch, and you share that, it doesn’t matter about the merge strategy? Or am I missing knowledge/misunderstanding something?
  - rhaway84773 4y ago
    Rebase is a lot more than a merge strategy. Merging is only one of the things it can do. Rebase -i allows you to rewrite history, and if you rewrite history of shared code, it leads to all sorts of issues with git.
    - FridgeSeal 4y ago
      Well, TIL, thanks for that. I’ve only ever used rebase in the very plain and not interactive mode of “please just apply my changes back on top of the incoming upstream changes” which does none of the history rewriting haha.
      - pmeunier 4y ago
        Another use of rebase is cherry-picking commits, which is also plagued with all sorts of issues. These aren't "bugs", since the issue is that commits aren't really suitable for doing this: patches (like in Pijul or Darcs) do solve this.
MereInterest 4y ago
> The tool developers want every commit to be feature-complete and that it won't cause broken builds at least in the master branch. This is impossible to achieve in the regular commit-merge workflow.You need to add the interactive rebases to achieve the goal. Why is this impossible to do with a commit-merge workflow? If I do work on a development branch, then merge it into the main branch, only the merge commit appears in the main branch, and that merge commit has the final feature-complete commit. The main branch then has an unbroken sequence of feature-complete commits. The only two complications are (1) avoiding fast-forward merges with the --no-ff flag and (2) viewing the history using the --first-parent flag. The first ensures that you always have a merge commit, even in cases where the history could be accurately represented without it, and the second avoids display of the development commits.
- noahtallen 4y ago
  I think the idea is that in a branch after a rebase, you have “main” with your new branch commits on top. This is exactly what it’d be like after merging to main, so you can test the branch with a high degree of confidence it’ll work correctly after merging.
  - MereInterest 4y ago
    Yes, but that only says that rebasing is no worse than merging with respect to testing the branch ahead of time. With respect to identifying when a bug was introduced, or the intended effect of a change, rebasing is worse because it cannot distinguish between a bug introduced during a feature implementation and a bug introduced during the rebase. The history that would be needed to distinguish between those cases has been thrown away.
    - rgoulter 4y ago
      Even then, it's worth distinguishing between: - Work in progress: My change request has been open for some time; I will rebase it against the master branch. - Accepting changes into master branch: `git merge` or `rebase + commit` or `rebase + squash + commit`. I don't think there's any practical downside to rebasing WIP branches.
OJFord 4y ago
Yes. The easiest thing in the (git) world to understand is surely the cherry-pick. Why on Earth do people make such a meal out of rebasing? It's just cherry-picking a bunch of stuff somewhere! Honestly, try explaining rebasing and merging to someone unfamiliar with git - I think the concept of merging is (not hard but) way harder. Yet for some reason people who are .. well, who use git in their jobs decide rebasing is difficult and unnecessary. I don't get it. And to 'rebasing as a concept is fine but the UI is annoying', really? I'm sure it could be better, but big deal? I use it multiple times a day and however 'could be better' it is, it's absolutely fine. If it was such a big deal, surely someone would have done it and it would be popular. Know your tools, or learn them!
LAC-Tech 4y ago
I contracted with one team that git rebased everything. It was awful and I hated it. I think the fundamental issue is that - of all the things I want to be neat and well organized in a codebase, the commit history does not even rank. I just cant bring myself to care.
- ses1984 4y ago
  Do you think maybe being a contractor factored into it? You don't have to live with the codebase after your contract is up.
  - LAC-Tech 4y ago
    [dead]
thayne 4y ago
My biggest problem with git rebase -i is that it has to be interactive (without some serious scripting), and sometimes that isn't really necessary. For example, the rewording example in the blog. Having to go through a whole interactive rebase because I forgot to link to a bug number in one of the commits is rather annoying. It's also a little annoying that i can't do an autosquash without an interactive revase.
- goku12 4y ago
  > My biggest problem with git rebase -i is that it has to be interactive The way I see it, it's a feature rather than a problem. For once, the name (interactive) agrees with its purpose. Interactive rebases are meant to be manual editors for git history - sort of like how commits are meant to be manual operations. Automatic commits miss the purpose of all the flexibility built into the tool. > Having to go through a whole interactive rebase because I forgot to link to a bug number in one of the commits is rather annoying. I don't get this. Rebases are cheap if you do it frequently. My rebases typically consists of maximum 2 ops at a time. It's not much more complicated that commits themselves. > It's also a little annoying that i can't do an autosquash without an interactive revase. I have never personally seen a use for autosquashes. Others may have the same experience and may be why there is no autosquash. However, it wouldn't be too hard to include if there is a good demand.
  - thayne 4y ago
    I'm not saying git rebase -i shouldn't be interactive. I'm saying that there are workflows that that don't necessarily need to be interactive, where git rebase -i is the only way to do it (ok, maybe you could build something with lower level plumbing commands, but you would have to duplicate quite a bit of logic that is in git rebase).

by goku12 4y ago

arxanas 4y ago

Rebasing is a fundamental primitive, but not Git's implementation of interactive rebasing. I very much subscribe to a "patch-stack" workflow, but have a great deal of difficulty doing advanced things in Git, because `git rebase`/`git rebase -i` do not support enough workflows. Here's some features I've implemented which improve on `git rebase` in general: https://github.com/arxanas/git-branchless/wiki/Command:-git-move#description https://github.com/arxanas/git-branchless/wiki/Command:-git-...

treis 4y ago
Really the fundamentals of git are nodes (commits) and how they connect to each other. Everything else is abstractions on that. Wonder if anyone has made a git client that lets you manipulate it at that level. Tree looking graph that allows you to drag connections to where you want them.
- btschaegg 4y ago
  > Wonder if anyone has made a git client that lets you manipulate it at that level. I believe you're describing GitUp [1]. I can't really say much about it, though, as I've never used it myself (because it's OSX only). [1]: https://gitup.co/ https://gitup.co/
  - treis 4y ago
    Yep that's what I was thinking of. Will have to give it a try.
  - password4321 4y ago
    I Ctrl+F'd for GitUp based on the title, it deserves mention here. It's all-in on Mac, unfortunately. https://github.com/git-up/GitUp https://github.com/git-up/GitUp > GitUp is built as a thin layer on top of a [Mac-only] reusable generic Git toolkit called "GitUpKit".
pama 4y ago
Is there any workflow in particular that you are missing in an Emacs/magit combo? I’ve found it easy to add a couple extra lines of lisp to fetch upstreams regularly or to “sync” worktrees in various remotes. The most complicated things I’ve encountered have been conflict resolutions, however, the tools did their best to help.

dmix 4y ago

> I've been learning Pijul these days. I looked this up and Pijul is a "distributed version control system" being written in Rust: https://pijul.org/ https://pijul.org/

goku12 4y ago
There are some advantages of Pijul over Git - Worries only about patches, not about snapshots too - Only a few commands to learn. No complex switches - Combines many git approaches in one. For example: - pijul record (its commit) is an interactive code selection at the same time. - Merges and rebases are all the same (due to the way commits are linked)
funnym0nk3y 4y ago
There seems to be some stagnation in pijul. I don't know if that's normal in this kind of project or if it's a indication of the future.
- goku12 4y ago
  The author has a habit of taking his work offline for months. Hopefully, that's what's going on now. They are so close to 1.0 with their work. I seriously doubt that project stagnated entirely.
- pmeunier 4y ago
  I'm one of the main authors. No stagnation, the future is bright but I've been founding a small company recently, not related to Pijul. I've shown an MVP to customers three months ago, now I'm close to 1.0 there. I promise I'll move back to Pijul soon. Another issue is the Nest (our hosting service), I've been working on a new Nest that can benefit from being open source, unlike the current one. Another indication that it's doing alright: I'll give a talk about it at BOB 2023 (bobkonf.de), and an invited talk in April at Collège de France.
  - funnym0nk3y 4y ago
    First of all congratulations to shipping the first MVP! And I'm glad to hear that Pijul is very alive! No need to promise anything, I was just wondering. I can't wait until Pijul escapes the nice and grows in popularity.

rileymat2 4y ago

> since the commit chain can be cleaned up later. This seems to be one of the major divisions in SCM users, some see it as a clean up for seeing a understandable 'history', others see it as a falsification.

arxanas 4y ago
For example, Git is somewhat ambivalent on the topic, but Fossil SCM is notably very much against rebasing/rewriting history.
avgcorrection 4y ago
If you made one commit after this sequence of events 1. Worked 2. Grabbed a coffee 3. Worked again You are falsifying history. One commit or more per butt-in-seat mini session.[1] Anything else is borderline fraudulent. [1] Or per balls-of-feet in front of your standing desk, if that is how you roll.
- rileymat2 4y ago
  I'd imagine the human psychology of this debate is quite a bit more complicated.
- MereInterest 4y ago
  Falsifying history isn't wrong in itself. Falsifying a shared history is, because it breaks other copies of the repo. So long as a branch exists only in a single repo, then the history of that branch can be rewritten without issue. But a shared branch should never be rewritten, because you'd need to copy the alterations into all copies of the repo. I take issue with tools that prioritize rebasing, because they usually make this distinction between rebasing a local branch and rebasing a shared branch. For example, GitHub's "Squash and Merge" or "Rebase and Merge" options break the shared history between the remote copy of the repo and my local copy. After such an operation, I cannot merge from main into my development branch, and must instead rebase my development branch onto main.
  - atq2119 4y ago

rhaway84773 4y ago

Git is many tools. For the purpose of this discussion it’s at least the following 2 tools: 1. A source code control system which allows you to manage the history and branches of your code. 2. A source code collaboration system that allows you to share code with others. git rebase is excellent for (1). It could also be considered fundamental to it. I know I certainly use it a ton for this purpose and would find myself lost without it. Unfortunately git rebase completely breaks (2) and if all git was is (2) it would certainly be considered an anti-feature, if not a bug.

FridgeSeal 4y ago
> Unfortunately git rebase completely breaks (2) I’m not sure I follow the logic? What is it about rebase that makes sharing difficult? Isn’t rebase just a merge strategy? And if you have code in a branch, and you share that, it doesn’t matter about the merge strategy? Or am I missing knowledge/misunderstanding something?
- rhaway84773 4y ago
  Rebase is a lot more than a merge strategy. Merging is only one of the things it can do. Rebase -i allows you to rewrite history, and if you rewrite history of shared code, it leads to all sorts of issues with git.
  - FridgeSeal 4y ago
    Well, TIL, thanks for that. I’ve only ever used rebase in the very plain and not interactive mode of “please just apply my changes back on top of the incoming upstream changes” which does none of the history rewriting haha.
    - pmeunier 4y ago
      Another use of rebase is cherry-picking commits, which is also plagued with all sorts of issues. These aren't "bugs", since the issue is that commits aren't really suitable for doing this: patches (like in Pijul or Darcs) do solve this.

MereInterest 4y ago

> The tool developers want every commit to be feature-complete and that it won't cause broken builds at least in the master branch. This is impossible to achieve in the regular commit-merge workflow.You need to add the interactive rebases to achieve the goal. Why is this impossible to do with a commit-merge workflow? If I do work on a development branch, then merge it into the main branch, only the merge commit appears in the main branch, and that merge commit has the final feature-complete commit. The main branch then has an unbroken sequence of feature-complete commits. The only two complications are (1) avoiding fast-forward merges with the --no-ff flag and (2) viewing the history using the --first-parent flag. The first ensures that you always have a merge commit, even in cases where the history could be accurately represented without it, and the second avoids display of the development commits.

noahtallen 4y ago
I think the idea is that in a branch after a rebase, you have “main” with your new branch commits on top. This is exactly what it’d be like after merging to main, so you can test the branch with a high degree of confidence it’ll work correctly after merging.
- MereInterest 4y ago
  Yes, but that only says that rebasing is no worse than merging with respect to testing the branch ahead of time. With respect to identifying when a bug was introduced, or the intended effect of a change, rebasing is worse because it cannot distinguish between a bug introduced during a feature implementation and a bug introduced during the rebase. The history that would be needed to distinguish between those cases has been thrown away.
  - rgoulter 4y ago
    Even then, it's worth distinguishing between: - Work in progress: My change request has been open for some time; I will rebase it against the master branch. - Accepting changes into master branch: `git merge` or `rebase + commit` or `rebase + squash + commit`. I don't think there's any practical downside to rebasing WIP branches.

OJFord 4y ago

Yes. The easiest thing in the (git) world to understand is surely the cherry-pick. Why on Earth do people make such a meal out of rebasing? It's just cherry-picking a bunch of stuff somewhere! Honestly, try explaining rebasing and merging to someone unfamiliar with git - I think the concept of merging is (not hard but) way harder. Yet for some reason people who are .. well, who use git in their jobs decide rebasing is difficult and unnecessary. I don't get it. And to 'rebasing as a concept is fine but the UI is annoying', really? I'm sure it could be better, but big deal? I use it multiple times a day and however 'could be better' it is, it's absolutely fine. If it was such a big deal, surely someone would have done it and it would be popular. Know your tools, or learn them!

LAC-Tech 4y ago

I contracted with one team that git rebased everything. It was awful and I hated it. I think the fundamental issue is that - of all the things I want to be neat and well organized in a codebase, the commit history does not even rank. I just cant bring myself to care.

ses1984 4y ago
Do you think maybe being a contractor factored into it? You don't have to live with the codebase after your contract is up.
- LAC-Tech 4y ago
  [dead]

thayne 4y ago

My biggest problem with git rebase -i is that it has to be interactive (without some serious scripting), and sometimes that isn't really necessary. For example, the rewording example in the blog. Having to go through a whole interactive rebase because I forgot to link to a bug number in one of the commits is rather annoying. It's also a little annoying that i can't do an autosquash without an interactive revase.

goku12 4y ago
> My biggest problem with git rebase -i is that it has to be interactive The way I see it, it's a feature rather than a problem. For once, the name (interactive) agrees with its purpose. Interactive rebases are meant to be manual editors for git history - sort of like how commits are meant to be manual operations. Automatic commits miss the purpose of all the flexibility built into the tool. > Having to go through a whole interactive rebase because I forgot to link to a bug number in one of the commits is rather annoying. I don't get this. Rebases are cheap if you do it frequently. My rebases typically consists of maximum 2 ops at a time. It's not much more complicated that commits themselves. > It's also a little annoying that i can't do an autosquash without an interactive revase. I have never personally seen a use for autosquashes. Others may have the same experience and may be why there is no autosquash. However, it wouldn't be too hard to include if there is a good demand.
- thayne 4y ago
  I'm not saying git rebase -i shouldn't be interactive. I'm saying that there are workflows that that don't necessarily need to be interactive, where git rebase -i is the only way to do it (ok, maybe you could build something with lower level plumbing commands, but you would have to duplicate quite a bit of logic that is in git rebase).