3 ms·

Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree wit

Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree with pull and don't know what fetch is. With history if you make a vcs mistake, or realize iteratively after pushing that corrections are needed, your worthless threshing around trying to fix it becomes part of your project log forever, instead of just pushing the corrected tree with just the one corrected patch.

Macha 6y ago
The objects are still there even with a rebase flow, it's not as if github does a gc every push?
- outsomnia 6y ago
  It's not about the object database, it's about what you see with git log. History flow will show all the meandering around forever, but rebase will remove it and just put the most recent version of the commit on top of the tree. Ie, your log looks like you pushed just the perfect patches each time, every time, and the junk is gone.
thrwyoilarticle 6y ago
I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. I see that as a fundamental difference in how the problem space is viewed and that they're stuck with a Github-first point-of-view. To me, even with merge commits, the history should be a statement of intent and treated as a first-class citizen, or even the primary output. Pushing a branch with threshing is like sending an email with visible backspaces.
- larzang 6y ago
  Completely agree, a change is an atomic change and should be contained in a single commit, I don't need to know the sub-steps it took to arrive at the final solution when I'm trying to blame or log the reason it changed 6 months from now. It also encourages bad commit messages which further confuse change history and motivation when you're creating separate commits just to fix formatting and such in your real change.
  - recursive 6y ago
    I have been using git for years, and have never rebased once. I'm kind of scared to try, perhaps irrationally. Rebasing seems to change commit relationships in a way that seems like it may be difficult to untangle if it later differs with someone else's clone. I would also like the ability to see a nicely curated set of changes. This mostly exists in the diff tabs of a pull request. If this were to be a first-class feature in git, it seems appropriate to be in some layer other than commits, but alas, that doesn't exist.
    - outsomnia 6y ago
      Rebasing one tree on another is a pretty specific thing, you may not need to do it very often. But casually manipulating the order of, or combining or filtering, patches near the top of the tree is something else. There are tools for this, eg https://github.com/stacked-git/stgit https://github.com/stacked-git/stgit
    - WalterSear 6y ago
      Rebase is best done before you share commits with anyone. I routinely do an interactive one before PRs to clean things up.
      - recursive 6y ago
        Is there a reliable way to know whether any of the involved commits have been pushed anywhere? I would probably usually know off the top of my head, but not always.
        rakoo 6y ago
        Check your local branch and the associated remote branch in your git log. If the remote branch is an ancestor of your local branch, you have some commits that haven't been pushed yet and you can "play" with them. If the remote branch and the local branch point to the same, you can't rebase without potentially impacting someone else. If the remote branch and the local branch have diverged, it's already too late.
- chriswarbo 6y ago
  > I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. If it's rebased then you're not reading the history; you're reading an artificial modification of what actually happened, performed by someone (possibly past-you) who thinks they know more about what you're trying to do. I don't rebase precisely because I want to read the history to see what happened.

Macha 6y ago

The objects are still there even with a rebase flow, it's not as if github does a gc every push?

outsomnia 6y ago
It's not about the object database, it's about what you see with git log. History flow will show all the meandering around forever, but rebase will remove it and just put the most recent version of the commit on top of the tree. Ie, your log looks like you pushed just the perfect patches each time, every time, and the junk is gone.

thrwyoilarticle 6y ago

I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. I see that as a fundamental difference in how the problem space is viewed and that they're stuck with a Github-first point-of-view. To me, even with merge commits, the history should be a statement of intent and treated as a first-class citizen, or even the primary output. Pushing a branch with threshing is like sending an email with visible backspaces.

larzang 6y ago
Completely agree, a change is an atomic change and should be contained in a single commit, I don't need to know the sub-steps it took to arrive at the final solution when I'm trying to blame or log the reason it changed 6 months from now. It also encourages bad commit messages which further confuse change history and motivation when you're creating separate commits just to fix formatting and such in your real change.
- recursive 6y ago
  I have been using git for years, and have never rebased once. I'm kind of scared to try, perhaps irrationally. Rebasing seems to change commit relationships in a way that seems like it may be difficult to untangle if it later differs with someone else's clone. I would also like the ability to see a nicely curated set of changes. This mostly exists in the diff tabs of a pull request. If this were to be a first-class feature in git, it seems appropriate to be in some layer other than commits, but alas, that doesn't exist.
  - outsomnia 6y ago
    Rebasing one tree on another is a pretty specific thing, you may not need to do it very often. But casually manipulating the order of, or combining or filtering, patches near the top of the tree is something else. There are tools for this, eg https://github.com/stacked-git/stgit https://github.com/stacked-git/stgit
  - WalterSear 6y ago
    Rebase is best done before you share commits with anyone. I routinely do an interactive one before PRs to clean things up.
    - recursive 6y ago
      Is there a reliable way to know whether any of the involved commits have been pushed anywhere? I would probably usually know off the top of my head, but not always.
      - rakoo 6y ago
        Check your local branch and the associated remote branch in your git log. If the remote branch is an ancestor of your local branch, you have some commits that haven't been pushed yet and you can "play" with them. If the remote branch and the local branch point to the same, you can't rebase without potentially impacting someone else. If the remote branch and the local branch have diverged, it's already too late.
chriswarbo 6y ago
> I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. If it's rebased then you're not reading the history; you're reading an artificial modification of what actually happened, performed by someone (possibly past-you) who thinks they know more about what you're trying to do. I don't rebase precisely because I want to read the history to see what happened.