Hacker News Reader

Comment by Ygg2 | Hacker News Reader

Because clean history is easier to bisect. It's easier to visually track problems, (aha so you changed thing A in branch br12 and thing B in branch br13 as opposed to wait so person A branched into br12, then person C branched into br23, then it got merged with br74, which was merged with person D on branch br84..).

Less entagled workflow is easier to untangle and consequently understand even if it hides some stuff.

Also it's visual clutter. If your history looks like train map, your project is probably a train wreck.

View on HN

This is an artificial problem. Git has almost all the data needed to present a squashed view - all it's missing is an idea of what commit a branch pointed to throughout history, so that it can merge together commits in in the "bubbles" for presentational purposes.

It would be better to fix this, so you get nice diffs, blame etc., than deal with all the other issues rebase causes.

I'm not convinced on the bisect issue either. If your app is trivial, sure, but if the features are more complex, the squashed commits will be too chunky to narrow down as usefully as a fuller history can.

I'm not convinced on the bisect issue either. I've personally done a bisect spanning 10000 changesets with 50 concurrent branches at the widest point. Found the problem right away.

We follow a similar branching model. Master is kept clean. We do all development on feature branches and merge when complete. History is fully preserved. History is a mess but it works well overall.

I would argue that you want to resolve conflicts in a rebase instead of a merge. This allows you to see where the branches diverge and fix it right away, closer to the offending commits, Preventing more work from piling up around the conflict making it harder to piece what's going on.

It can mean that you fix conflicts closer to the point where they first happened, or it can mean that you have to fix the conflict in a bunch of different ways as it propagates through each successive commit. I find myself trying to outsmart the conflicts: "Ok, I know I changed such-and-such in such-and-such a way here in a few commits, so if I fix this conflict like this, then hopefully I won't have to fix that commit later..."

Again rebase is there to cleanup your work, to simplify your workflow so someone not necessarily something looking the code can make sense of it.

git bisect might work ok (I haven't used it extensively) but the more important is if you made a mistake and call someone to help, to ease that person's work by presenting a trimmed though more understandable tree. You should strive to keep the branching as simple as possible, but not simpler than that (to paraphrase an infinitely more smarter man).

>Because clean history is easier to bisect.

While this is often true, `git rebase` changes your commits. Your history is now a lie. I've been in the situation where a `git rebase` ended up breaking commits. It's possible to merge broken history with `git rebase`. Only a `git merge --no-commit` will give you the opportunity to tweak the merge commit so that the resulting merge isn't broken.

Time is relative and history is only what has been observed. You only rebase code that has not been seen by others, so the code that was rebased was never history at all, as far as anybody else is concerned.

I don't think anybody ever recommends rebasing public code. There is a reason for that --force flag on git-push advises the user to use with care.

I mean, I could configure my development setup to automatically commit my persistent undo files so that every single keystroke I make is preserved for prosperity... but I don't do that of course. I could also configure my setup so that every time I write out a file it commits, preserving that history forever... but I don't of course. Why should a bunch of temporary local commits be preserved forever?

Using the terminology "rewriting history" to describe rebasing local commits is misleading. "deciding what history will be" is more accurate.

I'm not saying to never rebase. Rebasing has its merits. It's not always the best tool for the job.

>I don't think anybody ever recommends rebasing public code.

This very article says it's acceptable to rebase a public feature branch.

> This very article says it's acceptable to rebase a public feature branch.

  # optional: feel free to rebase within your feature branch at will.
  #           ok to rebase after pushing if your team can handle it!

It says that rebasing a feature branch is fine if it hasn't been pushed (ie, if it is not public). If it has been, then it is only okay to rebase it if everybody else on your team okays it, which is just common sense. If nobody cares then... nobody cares.

The problem with the article is that it's wording is imprecise.

I could just as easily say, if you are constantly using bisect on your master branch, then your project is probably a train wreck.

Yes, you could say that if you wanted to set up a straw man that is shockingly close to "we don't need to use version control because our code never has problems".

There is no reason not to enjoy the benefits of modern version control just because some code you inherited is utter shit.

On the other hand, being familiar with modern version control is a good idea, if only just in case you inherit code that will be shit.

On the other other hand, regressions occur and go unnoticed even on the best of projects.

Reply on news.ycombinator.com