Mercurial was not better. Features like rebase /squash are not native to mercurial (even though they since added extensions for this) and the tool had a very rigid view of the commit history. I had all my projects on Mercurial for several years after using SVN, because it felt more similar to SVN and I had no mental concept of why you'd ever want something so crazy as "rebase" - commit histories looked the way I always remembered them looking with SVN, with tons of tiny commits like "fix comma", "fix syntax", and no steady concept of a commit hash linked to a complete, working change, because that was something I had never seen before. Basically I just didn't get it.

Today my workflow is based on git + gerrit code review (which is heavily based around git), or in other areas github pull requests, and there is no such thing as a series of little commits that all hodge-podge together to form a particular change to the code, we tailor changes to be perfect, we push -f to keep each commit in the series to be a full and CI-tested story of a change, then we squash-merge them. My use with git is 100% all day things that were impossible with Mercurial back when I used it, if there are extensions for these things now, they are afterthoughts, git understood these concepts from the beginning.

▲

jamwil 5 hours ago | parent | next [-]

As a native son of git, I’m curious what the idiomatic way to maintain a patched fork was without rebase? Would you simply have your “patched” branch and merge in upstream changes as they arrive?

	▲	zzzeek 4 hours ago \| parent [-]
		as I recall, you didn't! you just had branches full of dozens of commits for every little bit of the change. yes you'd have to merge continuously to stay up to date.

▲

btreecat 5 hours ago | parent | prev [-]

hg sees history as useful metadata, and therefore you shouldn't dress it up artificially.

git allows for folks to be Pinky's out with their commit history for warm an fuzzies.

If you think editing history is a grand idea that should be used regularly (like with rebase) then I already know you likely haven't been responsible for large mature code base. Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.

▲

plorkyeran 16 minutes ago | parent | next [-]

When using systems without history editing I simply make an order of magnitude fewer commits. With git I basically commit every few minutes and then edit later, and with not-git I simply don't commit until it's "ready". Either way all of those intermediate states aren't getting published or saved forever.

▲

snuxoll 3 hours ago | parent | prev | next [-]

There's a huge divide between abusing rebase in horrible ways to modify published history, and using it to clean up a patch series you've been working on.

Oops, I made a mistake two commits ago, I'd really like to get some dumb print statements I added out before I send this off to get merged is perfectly valid, I just did it yesterday. A quick `git commit --fixup` followed by `git rebase -i --autosquash HEAD^3` and I had some dumb debugging code I left in stripped out.

Then, there's other perfectly valid uses of rebase, like a simple `git rebase main` in an active development branch to reparent my commits on the current HEAD instead of having my log messed up with a dozen merge commits as I try to keep the branch both current and ready to merge.

So, yes, I do think editing history is a grand idea that should be used regularly. It lets me make all the stupid "trying this" and "stupid bug" commits I want, without polluting the global history.

Or, are you telling me you've also never ended up working on two separate tasks in a branch, thinking they would be hard to separate into isolated changes, and they ended up being more discrete than you expected so you could submit them as two separate changes with a little help from `git cherry-pick` and `git rebase` too?

Editing history isn't evil. Editing history such that pulls from your repository break? That's a different story entirely.

▲

btreecat an hour ago | parent [-]

Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them. What's it matter if you have an extra commit to remove a file before merge? Perfectly valid, and doesn't hide anything.

Caring more about a "visually pleasing log" when you can care about an information rich log doesn't jive with me. Logs aren't supposed to be "clean"

If I want features in two branches, I make two branches. Cherry pick also is bad for most people, most of the time.

	▲	snuxoll an hour ago \| parent [-]
		I care about having a commit log that's useful and easy to scan through, it's not about it being "visually pleasing". Having a dozen "oopsie" commits in the log doesn't make my life any easier down the road, all it does is increase noise in the history. Again, once something hits `main` or a release/maintenance branch then history gets left the hell alone. But there really is no context to be gained from me fixing stupid things like typos, stripping out printf() debug statements, etc. being in the commit logs before a change gets merged.

▲

zzzeek 4 hours ago | parent | prev [-]

you might want to check on what you "know" then....

▲

btreecat 3 hours ago | parent [-]

[flagged]

▲

throw-the-towel 2 hours ago | parent | next [-]

Nice technical argument you've got here.

	▲	btreecat an hour ago \| parent [-]
		What's your excuse then?

▲

zzzeek an hour ago | parent | prev [-]

just so you know, this line

> Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.

see that's a common story from a legacy way of working, back when everyone wrote perl / php scripts and shoved it all into a repo.

The way that people years from now understand what someone else did is that when that someone else does the thing, it's presented for code review. That is, your patch does not go in at all if nobody else knows how it works. You present each change as a logical series of commits, without lots of noise like "fixed typo" or "oops forgot this test", just the way people present patches on the LKML (this is why Linus "got it" before anyone else did), and then other people review it, which is where it's established, "this change makes sense, I understand why and how you did it, and it has good tests".

When you work on a project that is truly long term, you yourself need these records to understand what you did 10 or 15 years ago. So there's no issue that short term history was modified, this is actually essential, because what you're doing is editing the story of how a change came about and presenting it for review. Having it be a long series of small commits that sometimes reverse each other is not going to help anyone understand a particular feature or change, it's noise.

	▲	btreecat an hour ago \| parent [-]
		I'm not sure what XP you're speaking from, I see modern day companies with all faults of orgs past because the tooling isn't saving anyone from the human tendencies. If your problem with commit history is that folks have too many useless commits and you can't personally be bothered to focus on the meat of the PR, that'sa probablem with the commit author and PR reviewer. Not a fundamental need to prune logs.