Hacker News Reader

Comment by eikenberry | Hacker News Reader

But the PRs aren't part of your git repository? IMO a git repository should be self contained and not require a hosted provide to give context. It lets you manage your work with superior local tooling and without a browser running. Basically I take the exact opposite approach where my PRs are always just a short summary of the commit messages and provides a place for me to put the github specific things like the "Fixes #..". But I make sure my commits are a clean artifact of the changeset by themselves (ie. I do any squashing, etc, on them outside of the PR).

View on HN

GitHub (by default) uses the name of the PR as the merge commit message and also includes the commit message of each commit in the log. Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use.

I can't speak for everybody, but if GitHub goes down completely and I only had access to my git logs, I'd struggle to recreate ~20% of the information scattered across issues and PRs. This issue is external to merging preferences, but it's definitely not solved by squash-merges and descriptive merge messages.

> Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use.

The frustrating thing about this is that this "omg minor commits on a merged branch clutter up the log!" is entirely a UI problem created by github's naive view of history where it shows things in a bafflingly obtuse linear order instead of letting you do something like `--first-parent` like the command line client lets you do.

Git itself has more than enough tools to give you that 'squashed' view without actually squashing anything, github just has no interest in providing it to you for whatever reason.

Also yes to the sibling comment that if you want to make something happen with a commit use `--allow-empty` and not "bump number" or "add random whitespace". Please.

It would also help if people were better about keeping a clean commit history for PRs. Ideally, a new commit should only get pushed to a branch per change relevant for reviewers. If the CI is causing the error, people should work on a temporary branch and resolve it there first before cherry picking things over into the PR branch (after rebasing the intermediate commits on the temp branch).

Rebasing is a really nice tool, though I think the UI is really lacking. A simple GUI for interactive rebasing would help a lot. Most clients I've used (which isn't a ton since I generally prefer the CLI) don't even have an option for rebasing at all.

Love the sub-branch idea. I'm going to use that.

GitKracken and Fork both have an excellent rebase UI.

> github's naive view of history where it shows things in a bafflingly obtuse linear

This hits home, it pretty much describes how I visualize logs in my head (compared to the visualizations I see that are more 2-D, branching off and merging together, etc.). I have a hard time working with some of the more advanced features because of this, and it'll probably always be an uphill battle to shift my thinking from linear to not-so-linear ...

The obtuse part about github's linear view isn't that it's linear, it's that it's interleaved by time in ways that form a chaotic view even for a linear one. Like, picking a random large project for an example, take a look at swift's history on github[1].

Because there's a bunch of PRs that were being operated on in parallel, and some probably that are even kind of old, the view you wind up with is likely a large streak of "PR merged" commits and then all the commits from those PRs jumbled together in an incoherent mess. Likely you'd have to scroll a few pages to even find some of those PR's commits (Note: git-log also has this as its default order, but you have some choices like --topo-order).

That said, I really really recommend you look at git's native --first-parent output, as I mentioned. That is likely the linear history you really want and it's right there in the client. It's the exact same thing as you get from a squashing strategy, except the history isn't gone it's just hidden.

I agree that the interactive tree views are chaotic and incoherent in their own ways. I don't use them either. I use --first-parent usually to find what I want and then I might dig in deeper if I need to.

But leaving that history there underneath means tools like git bisect can actually work, or if you need to narrow down onto a small change you actually can.

[1] https://github.com/apple/swift/commits/main

> The obtuse part about github's linear view isn't that it's linear, it's that it's interleaved by time in ways that form a chaotic view even for a linear one. Like, picking a random large project for an example, take a look at swift's history on github[1].

> Because there's a bunch of PRs that were being operated on in parallel, and some probably that are even kind of old, the view you wind up with is likely a large streak of "PR merged" commits and then all the commits from those PRs jumbled together in an incoherent mess.

Oh yes, I've just run into this problem myself: I had to backport a large set of commits. While they're of course roughly chronological, they're not strictly so, and so the result in Github's UI is a giant mess.

I sometimes hack author dates just so that commits show up in the right order in the stupid Github linear view.

It doesn't always work (on a big project like Swift it would be a lost cause), but because I care a lot about presenting my work as a sequence of commits optimized for reviewability, I try.

Try this:

    git log --oneline --graph

Seeing the --graph output really helps in understanding the branch history. The lack of a view similar to --graph on Github drives me bananas.

I don't like typing "git log --oneline --graph" all the time, so in my profile I have a `git slog` alias which is similar but adds date and author, plus truncates each line at 100 columns so it doesn't wrap:

    slog = log --pretty=tformat:'%C(bold blue)%h %C(bold red)%ad %C(bold blue)%aN%C(auto)%d %<|(100,trunc)%s%C(reset)' --date=short --graph

My terminal has a light background. If you prefer a dark background, I suggest changing "bold blue" to "bold green" and "bold red" to "bold yellow":

    slog = log --pretty=tformat:'%C(bold green)%h %C(bold yellow)%ad %C(bold green)%aN%C(auto)%d %<|(100,trunc)%s%C(reset)' --date=short --graph

Wait, can people really not just go into their CI systems and click a “build again” button? People actually insert ‘dummy’ commits to trigger builds?

I’ve been using Concourse to run my CI for years and years and just sort of assumed that “build again” was such basic functionality that every other CI system would also have it.

> Having whitespace-altering "Dummy commit to trigger CI, ugh!"

`git commit --allow-empty` may be sufficient for that "there is a new commit" trigger in many cases. If so, that may be preferable to whitespace changes as those clutter up the blame.

As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship with that initial empty commit (which I feel is preferable to an orphan branch and then a merge with unrelated histories ... though those tell slightly different stories in the log).

> As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship with that initial empty commit (which I feel is preferable to an orphan branch and then a merge with unrelated histories ... though those tell slightly different stories in the log).

Oh cool, I thought I was literally the only person on the planet to do this lol. I'd do it for branchpoints too except git rebase by default acts very poorly with empty commits in the edited history (deletes them). I wish this was normalized (ie. there was a flag to `git init` to add a commit message for a root commit).

Starting a repo with an empty commit is a cool idea. My first commit has been "Add empty README" since forever, but I like your way better and I'm going to start doing that.

Yep, `--allow-empty` is my preferred solution. It's unfortunately not up to me how other people choose to do this

I do 99% of my coding at work. At work we have Gitlab, Confluence and Jira and these all already contains mountains of context for all of our work. Pretending this context doesn't exist and storing it all in a Git repository isn't helpful.

I also do my coding at work, with Gitlab/Github, Confluence and Jira. And yet, due to various leadership decisions and technical migrations over the years, we have lost huge piles of records due to migrating work trackers, document stores, and VCS hosts (e.g. Unknown -> Jira -> Pivotal Tracker -> Jira). Due to these crappy migrations, we don't have old merge requests, old wiki documents, and even some old repositories. Sure, it's possible to find those in old archives sitting in an S3 bucket if I were to take a couple days, but they're not 'at my fingertips'.

What is at my fingertips though? All the git commits of every repository that we still have. Which means that the only thing that's actually endured has been the commits. So, on behalf of folks 5-20 years from now who'll be scrutinizing your work, please put the context into the repo directly since it's the only thing that'll stick around.

I'm speaking of coding in a larger context then... Where it can exist outside of the limits of a single company and a single team. In those sort of cases no, it doesn't really matter where you keep the history. It is a business decision and it is up to the business to decide to switch providers and absorb the loss.

I'm speaking of code that others will read. Maybe it is free software, maybe it is proprietary but shared by a larger team, maybe you are writing for customers... any way about it, if the code is to be maintained and read again over time the development history should be captured by a revision management tool like git.

Reply on news.ycombinator.com