4 ms·

> 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 (

• rectang 4y ago
  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
• stormbrew 4y ago
  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 https://github.com/apple/swift/commits/main
  • rectang 4y ago
    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.
  • iggldiggl 4y ago
    > 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.