Hacker News Reader

Comment by outsomnia | Hacker News Reader

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.

View on HN

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.

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.

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.

Rebase is best done before you share commits with anyone.

I routinely do an interactive one before PRs to clean things up.

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.

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.

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

> 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.

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

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.

Reply on news.ycombinator.com