[masklinn]

Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches".

This is combined with most of the "historical record" really being worthless garbage: does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not. Does it need to be enshrined in the project's commit history? Absolutely not.

[marssaxman]

I've yet to find a situation in which I cared even a little bit about the prettiness of a git history. I am having trouble thinking of more than a couple situations, ever, where I cared about the contents of a git history, at all!

I imagine that people must be doing something involving git history which I simply don't have reason to do, or this "make your history pretty by rebasing" meme wouldn't keep floating around, but I really can't imagine what that activity might be.

[u801e]

> I've yet to find a situation in which I cared even a little bit about the prettiness of a git history. I am having trouble thinking of more than a couple situations, ever, where I cared about the contents of a git history, at all!

For me, it's the ability to use git blame and determine which commit was responsible for a line of code and read the commit message about why it was added.

If you don't keep a clean commit history, you end up with a commit message like "fixing some issues based on comments" which affects at least 30% of the lines of code in the file. If I'm looking at that file 6 months after the fact, that commit message gives me no information about why those lines were added/changed.

With a clean history, you can use the same command and see the exact reason why a line of code was added through the commit message that added/changed it.

[caoilte]

Blame is occasionally useful, but for me more than half the time the file gets moved somewhere else or the indentation changes as part of some other change so you lose all context about the original commit.

The code is the thing for me. And the less of it, the better.

[gknoy]

The argument made to me by a coworker (for why we should squish + rebase all PRs before merging) was that it makes it easier to use `git bisect` -- which is basically a binary search for Where a Bug was Added.

In practice, I've never done this. I think it's that I work on a smaller codebase, or that I am 1/3 to 1/2 of the developers, and so it nearly always has seemed easier to read the code + tests, and poke at values in a debugger, than to use binary bug search. If I were on a larger team, or a larger project, `git bisect` might be more useful.

[Touche]

What's the issue with merge commits and git bisect?

[daigoba66]

I think, based reading comments and articles from various sources, it's all because of GitHub pull requests. A lot of people seem to rather a pull request be represented as a single commit.

But I'm in your camp: I work with teams using git (and GitHub as a central repository), and a non-linear history has literally never been an issue. Even ugly graphs 7-10 histories wide aren't an issue. We also don't do pull requests (because we would we?).

We don't have a hard time with code reviews just using GitHub's commit history or even Gitk. In fact merge-commits often sometimes useful as markers of when the developer integrated his/her changes.

Admittedly, I'll occasionally do a rebase of upstream changes before I push if I know the change I made was small an isolated - but I certainly don't encourage other developers to do it.

[Touche]

I sort of feel the same way. The whole "prettiness" thing seems like a bit of a fetishism more than about productivity. Sort of like how people fetishize "inbox zero" (but in that case I do see the productivity gain).

I want my git history to be like my server logs, verbose. I can use tooling to reduce the noise and find what I need.

[Karunamon]

does it matter that you had to implement 12 fixups at various points

If you want to come back later during a git bisect and find out exactly when that bug that just took down your production application was introduced, then yes, absolutely. I'd rather look through 12 small commits than one monster one for that use case.

Look at it this way - a bisect cuts the search space in half with each progression, so you can double the number of commits being searched with the relatively minor cost of adding one more call to bisect when bughunting.

If you're tagging your milestones appropriately and otherwise practicing good repo hygiene, having n number of extra commits for any value of n is a feature, not a bug.

[Touche]

> Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches".

I'm not following this at all... what is it you need from this tool and why?

> Does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not.

Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. And having many small commits rather than 1 massive one makes it much easier to revert bad commits.

[HolyHaddock]

> Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made.

This is interesting - even places I've worked that have cared about commit messages have been pretty happy with the entirely content-free "Fixes from code review."

Do you summarise code review discussions in the commit messages?

[Touche]

Yes, I do, I try to treat each commit like something that can be read in isolation. But nevertheless, the merge commit will have (if using GitHub) a reference to the pull request where you can see the discussion, which is valuable imo.

[HolyHaddock]

Have you had any feedback from colleagues that have found that useful?

[camwest]

Check out http://gitup.co