Comment by feoren | Hacker News Reader

Comment by feoren | Hacker News Reader

Parent Full thread

The fact that rebase would ever be preferred over merge just shows how bad Git really is under the covers. It's insane that everyone is re-writing their development history to avoid issues with their source control system. There's no reason that should be necessary at all. Manually intervening and re-writing history should be completely antithetical to a good source control system.

And squashing should never be preferred by anyone if the tooling was actually any good. For PRs? You should be able to define a group of commits and look at it as a whole, not just operate on a single commit. For clutter? You should be able to "zoom" in and out, or collapse/expand branches in your UI. For disk space? If the size of each commit was O(size of change + small constant), then squishing wouldn't help, because you'd just be cutting out a few bytes per commit -- assuming you're not thrashing back and forth with your changes. The fact that squashing saves so much space just shows how inefficiently Git is storing things.

We're all suffering that Mercurial lost the war. Of course, even Mercurial isn't perfect. Why did we stop innovating on source control systems a decade ago?

> Manually intervening and re-writing history should be completely antithetical to a good source control system.

The way I use git, it's not "history" until it's in main. Up until that point, branches are mutable sequences of patches that may or may not ever get merged in.

These patches bear little resemblance to the actual sequence in which I developed the code: as often as not, I'll amend a commit rather than creating a new one, because the point of the version control system for me isn't to faithfully log what I did, it's to represent my change as a discrete sequence of steps to get from main to main+feature.

Viewed that way, rebase is obviously the preferred way to integrate main->feature branch. Main has changed under me in some way that causes a conflict, so I need to reevaluate my sequence of patches in light of the new information.

When it comes to integrating feature->main, I don't have a strong opinion, except that squash is terrible because I specifically designed the commits to make sense as distinct steps.

I cannot grasp that at all.

To rebase I take your patches, apply them, then I apply my patches, fixing any trip ups. You "got in" first, so I get to do the work.

It seems simple to me - far more than hoping merges do what we both meant.

Conceptually, it's patches all the way down - anything else is to me suspect ... might be me not being big brained enough :-)

In both cases we're just "hoping" that the result is what we want. Merging is acknowledging the parallel development and explicitly dealing with it; rebasing is pretending it never happened and applying my patches on top of a codebase that I have never seen before. In my experience, rebasing is much more likely to fail in weird and dangerous ways. But I'll admit Git's merging leaves a lot to be desired too -- that's part of what I'm complaining about, and what attracts people to rebase.

Then I think that the complexity is kind of inherent.

Firstly it's only a codebase I have never seen before because I am not keeping up with the changes. Ideally i will pause during rebase carefully read the commits which will include long thoughtful messages laying out important implications, and my tooling will make clear where the conflicts lie, and how test coverage is affected.

We won't ever just grep for <<<<<< and try and remember which HEAD means - is that mine or yours?

I am making changes against an evolving codebase. Either I am talking with people editing that codebase and we are in sympathy or we are hoping a VCS will solve our political and organisational problems.

I honestly think having time to argue about the best way to solve a problem amoung a team is the best solution - let the team talk argue and decide and they will barely need a VCS. If you cannot "spare the time we must deliver" you got other problems

Edit: Look honestly it's all patches. That's the atomic level. And to my mind, having you gather the freshest version of the codebase then apply your chnage son top is the sanest cleanest approach.

The same merge conflict resolution applies - I agree. (basically line conflicts). But what's the option? Anything else gets weirder faster (seen some trying to understand conflicts in functions, etc)

I've been keeping an eye on the Pijul[1] VCS which goes all-in on the whole "theory of patches" thing. I don't expect Git will be going anywhere for a long time, bjt it's interesting to think about what could be next.

[1]https://pijul.org/

> The fact that rebase would ever be preferred over merge just shows how bad Git really is under the covers. It's insane that everyone is re-writing their development history to avoid issues with their source control system.

It's local history that one rewrites, so there's nothing "insane" about it. What your comment does is expose your lack of understanding of this matter.

> We're all suffering that Mercurial lost the war. Of course, even Mercurial isn't perfect. Why did we stop innovating on source control systems a decade ago?

Mercurial supports rebasing and history rewriting just fine.

> It's local history that one rewrites

I don't understand this. You do not back up your code to any shared repository while still working on a feature? What if it takes 2+ weeks? You have 2 weeks of code replicated only locally on your laptop? Or what do you mean by local?

Yes, local is the wrong word. Or rather, it's imprecise. A better word is unshared. But even that is imprecise, because you might consider pushing a set of commits to the Internet as sharing. Maybe an even better word is collaborate. I don't rewrite history of source code that I am collaborating with someone else on. For example, the history on master never gets re-written. But that feature branch I pushed to get review before being merged? Absolutely. I'll rewrite its history without a second thought before it gets merged.

It doesn't matter what source control system you hand me. It could be your ideally perfect system. I would still rewrite history that I'm not collaborating with others on. I try treat source history (as much as is practical) as a sequence of logical changes to the code. I treat it like I treat the code. I try to optimize for making it intelligible and understandable to other humans (including myself).

You can look at any of my projects on GitHub for examples.

You can push your local work to a private remote branch. (By private, I don't mean that other people can't see it, I just mean some convention which means other developers will ignore it in normal circumstances.)

If a person commits a lot, they can end with all kinds of little commits which are just fixing typos or syntax errors, exploring half-baked ideas, can't be bothered writing a commit message right now, etc. What's the point of keeping all that stuff long-term?

Then, when it is ready to be reviewed, you rewrite that real history into something more logical - e.g. first commit creates an interface, second commit implements it, third makes other parts of the code call it, etc - and then submit that for review as a PR - that "fake" history is likely to be much more useful to others (and to one's own future self) than the real development history was

The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. However this is a defect of your version control system.

back when I used hg small commits were not a problem as the branch name remained after the merge and so mostly we were able to treat branch names as the squashed whiae still having acces to the typo commit if needed.

> The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing.

I don’t think the real issue is Git’s features. Even if Git had whatever additional features you wish it had, it still doesn’t change the fact that a history of typos and stupid mistakes isn’t very useful to anybody (especially in the long-run), and hence there is little or no value in preserving it; while a faked history which breaks the change down into logical steps does have some real long-term value, in terms of helping anyone who needs to review and understand the change in the future

I'm not the person you asked, but I think they meant: changes that are not shared with others. You can back up your own stuff as you please, but once you share it with someone else, it's best to treat that bit of repo history as immutable from that point onward (because they may have made their own copies, shared it with other people, etc).

So I think what people are saying (and I largely agree with them) is that it's fine to rewrite history as long as you never share the ugly mess that existed before the rewrite with others.

A typical example of this is having un-shared ("local" - but could be backed up) streams of "tweak a comment, fix a semicolon, xxx" changesets that aren't really going to be useful to other people. Before you share with others, you squash them down to a single (or few) "implement feature X" kind of changes, often with linear history.

Having that less-branchy and less-noisy linear history available is useful in the future when you want to examine the history of the repo. Future people don't need to know that you fixed a comment, added a semicolon, etc. They want to know the big coherent logical changes that were applied to the repo.

Squasing/rebasing/fixing history before you share it allows you to have your cake and eat it too, more or less.

----

EDIT: Here's a decent email from Torvalds on the subject (not that I agree w/him about everything, but in this case): https://www.mail-archive.com/dri-devel@lists.sourceforge.net...

There's an easy way around this, and that's to namespace in some way branches that are free to be overwritten, ie WIP work not yet merged into the canonical branches. Works just fine.

If the project is too large for this, you can also fork off the repo itself and then merge in your changes to the main canonical version when you're ready.

I'm not a fan of changing history at all, but:

> to any shared repository while still working on a feature? What if it takes 2+ weeks?

A lot of projects don't want our partially implemented changes, if only one person is working on them, just the first ready-for-others result and subsequent smaller fix updates.

> Or what do you mean by local?

This is key: remember that git is distributed, so backups of your really local repository should be as easy as pushing to a remote copy. If you aren't doing that (or even if you are) keeping an automatic off-machine backup of your working directories is a good idea in case of drive failure.

If you are working on a feature with a team, perhaps a team-local shared repository is a valid answer.

"Local" probably wasn't quite the word he meant. "Personal" is maybe a better word. In other words, only you are working on it. As soon as you share a branch with other people and they start adding commits - that's when you should start avoiding "rewriting history" (though if you coordinate well even then it's fine).

And to answer your actual questions. Yes, you either:

1. Push it to a shared repo but with a name that makes clear it is a branch belonging to you (e.g. `<yourname>/branch`), or

2. Back it up with your standard laptop backup (the one you have set up that backs up non Git stuff too).

Local in the sense that every developer has a full history, and can edit their own history after the fact before pushing changes.

Basically it's the equivalent of bringing patches up to date before upstreaming them. Upstream isn't going to apply a patch that no longer applies cleanly.

Local == not published (on the trunk or whatever you call the main branch).

Local != not pushed to a remote. You can totally push to a per-developer remote, or to branches under a per-developer namespace.

> It's local history that one rewrites, so there's nothing "insane" about it.

Squashing PRs on remote is quite common.

You could also do without the disparaging comments.

> You could also do without the disparaging comments.

You're right.

Doing the extra work to rebase makes git bisect a lot more tenable, and it simplifies the view of history. You don't have to make this tradeoff, but some might want to.

I agree. Mercurial at Meta was THE BEST version control experience I ever had. In 2023, git is worse than mercurial. Stack sets are superior.

Yes. The absence of staging area and the single path of development controlled by diff approvals and landing were major improvements.

But Meta's "hg" wasn't really FOSS hg for a long time and looks nothing like it today. It started as hg but was hacked to become what is now sort of Sapling (+ Mononoke + Eden + Buck + Phabricator + Sandcastle + Landcastle) integrated together.

The lore was that the git people didn't want to help improve monorepo performance, but the hg people were somewhat more interested so that was the reason behind hg. Then later, Microsoft got git people to upstream changes to accomplish similar performance improvements.

IMO, efficient monorepo dev cannot happen without an SCM-integrated synthetic FS. Also, efficient dev cannot happen without dependencies-aware testing and build caching. It further helps if dev tools are tightly integrated together and documented. Meta didn't do documentation well and didn't name things all that well either. Most internal tools also lacked man pages and generally depend on in-group knowledge hoarding rather than self-discovery and principle of least surprise.

Every now and then, some critical tool (to your workflow) group would come along, break their tools, and leave them broken for weeks with a flimsy excuse like "Oh yeah, our news people are rewriting it in Rust" rather than reverting to a working build.

I dunno…leveraging retrospect is often useful.

Extremely useful almost every time. Why wouldn’t we re-write our personal history just before merging into the main permanent history?

I'm not a proponent of it, but some people would say: including all the messy history is a more honest representation of what actually happened.

By that school of thought, a repo should be recording what happened, not what you want to look like happened.

I haven't found it to be terribly useful though. IME, it adds noise for future code archeologists.

In very rare cases, having the messy long history can be slightly more useful for bisecting to find precisely where bugs were introduced, simply because it's more fine-grained.

> including all the messy history is a more honest representation of what actually happened

I don’t think anyone needs to see the hundred incantations of `git commit -a -m fuckfuckfuck` I do before I make a PR.

To those who say “you should make meaningful commit messages” I say “yeah that’s what you see in the single commit when I make the PR”. If you say “you should just not commit until your local work is PR worthy”, I would say you’re not using git effectively.

> I'm not a proponent of it, but some people would say: including all the messy history is a more honest representation of what actually happened.

By that logic you should leave typos in, because, you know, it's "more honest". Or you should not edit yourself in any way, because it's "more honest".

The reality is that not editing our communications, or our commit history, is a lack of respect to others, especially when that lack of editing imposes a higher cognitive burden on others (e.g., having to sift through more hay to find needles).

I think those proponents would indeed say to include the typos. And then also include the change where you fixed the typos, and so on.

I didn't mean to imply any moral or dogmatic concept of "honesty" here. It only means there is less guessing about what events actually transpired.

But as you say, I agree it most often just adds noise, in my experiences.

> But as you say, I agree it most often just adds noise, in my experiences.

But critically, that noise is a lack of respect towards others.

As with all things, context matters. It would depend on what those others want, what the team culture is, etc. I could imagine a group of these hypothetical "maximum honesty" people working together happily, and respectfully, in their way.

> Why wouldn’t we re-write our personal history just before merging into the main permanent history?

Mainly because it's more work. But it's work worth doing. It's also enjoyable.

> It's insane that everyone is re-writing their development history to avoid issues with their source control system

people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing. I would have the same problem on any VCS

> And squashing should never be preferred by anyone if the tooling was actually any good. For PRs? You should be able to define a group of commits and look at it as a whole, not just operate on a single commit. For clutter?

once again responsible commits are supposed to be small, isolated, single change commits. so in a large feature a good developer would have tons of commits this makes the PR easier to understand and review... and when the features finally merged, you don't necessarily need those commits you just need the feature.

I think your issue might just be with understanding how version control is supposed to work.

> I think your issue might just be with understanding how version control is supposed to work.

This has nothing to do with how it's "supposed to" work, and all to do with the standards and constraints we're putting on ourselves here. No god has made any commandments about how thou shalt organize your commits.

> I would have the same problem on any VCS ... commits are supposed to be small, isolated, single change commits

It sounds to me like you've got some self-imposed issues. Nobody told you every commit has to be a "single change", unless you're very loose with what you mean by that. Sure, a commit should be a group of related functionality, such that you either want all of it or none of it. But it's perfectly fine for one commit to involve 20+ files. In fact one of the (many) things people hated about CVS was that you couldn't bundle changes like this! And if you're that concerned about commits being single changes, then you should never squash! It's hypocritical to say every commit should be tiny, but then squash them!

> this makes the PR easier to understand and review

I already addressed this. The problem is the 1:1 mapping between commits and PRs. There's no reason for that.

> people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system.

Corporate policy often is to push at the end of the day, so in the event you spill some coffee over your laptop, all you'll lose is a day of lost work and a day to set up a new laptop.

> people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing.

Its a good ideal but not realistic.

Why isn’t it realistic? I’m not trying to be glib. With “git add -p” and “git checkout -p” I find it fairly straightforward to do. I think usage of “git commit -a” or “git commit .” is the source of a lot of messy commits, but is often easily avoidable. Good commit hygiene is just as important as good tests, good method names, etc.

Reply on news.ycombinator.com