4 ms·

Yeah, I've got strong git skillz and could handle the email workflow, but I prefer to work with branches rather than a bunch of loose patch files. There are a

Yeah, I've got strong git skillz and could handle the email workflow, but I prefer to work with branches rather than a bunch of loose patch files. There are a couple things I strongly dislike about Github though. Number one: the default commit history display with commits force-linearized by date, which is just messed up and wrong when actual Git history can only be properly modeled with a topological view revealing branch lines of development. Give me `git log --graph`!

pabs3 6y ago
There are lots of graphical history viewers, I use gitk mostly and git-big-picture to get a graphical overview graph without individual commits. The gitg GUI from GNOME is fairly good too, and of course there are better tools for proprietary operating systems.
- rectang 6y ago
  For local development, I'm actually content with what I get from the Git command line interface: I use a slightly customized variant of `git log --oneline --graph`. The problem is that I am often browsing the history of repositories hosted on Github via the Github web interface, along with other interactions such as searching through issues and PR history. Cloning a repo to my local machine and firing up gitk is a pretty inconvenient interruption of the web browsing experience.
0x0 6y ago
Gitlab has a great graph view
jlokier 6y ago
The GitHub linear view that shows no graph is a real problem on my team, because at least one team member has no idea when they are creating a complex, unbisectable graph with their merge commits and no-message submodule updates. To them the timeline is just a linear sequence of what everyone has been working on recently, mixed together. They do understand feature branches, but then they randomly merge their branches in progress and the result is still a mess somehow. To me, seeing the `git log --graph`, it's a difficult to understand mess with redundant micro-branches and micro-merges. Randomly unrelated file changes and even file deletions also occur - `git commit` might as well mean "copy my working directory into the repo". As a result, the main branch quality varies and cannot be trusted from one day to the next. The difference between us is I actually look at the repo history, I look at my commits before I commit them. They appear to commit things without even knowing what's going in, and don't look afterwards, as it's a surprise to them when I complain about things like a file deletion. GitHub's commit history view is part of the problem, because its presented as if it's the main, primary way to look at the history. It's not the problem, but it makes things worse. Better visualisation tools would help, but for now everyone has their own "pet way" of using Git, I lack the social capital to convince anyone to do better, and the gravity of GitHub as "the way" makes it difficult to get anyone to care about any alternative way of viewing the repo. "It's what everyone uses". GitHub issues similarly suck as a project management tool; guess what we're using.
- WorldMaker 6y ago
  The GitHub "network graph" is most known for exploring fork activity, but even in a single repo scenario with no forks you can still use it as a cudgel to show some idea of the complex graph if you need to stick with GitHub provided visualization tools. (It doesn't help that several UX redesigns have done nothing but bury the network graph, but it's still around.) You might think about investing in a copy of a client that puts the graph up front for that developer, such as GitKraken. Though I've actually had good success with a tool that is free and already out of the box in most git installs: gitk. gitk is ugly, but it gets the idea across and is easier to teach most developers to use than trying to get them to remember to add the --graph flag to git log. (Though adding a good alias for `git log --graph` or some further relative like `git log --graph --oneline` and encouraging them to use the alias instead is also another option.)
rakoo 6y ago
> I prefer to work with branches rather than a bunch of loose patch files The two are not mutually exclusive. You can have branches locally with the changes you're interested in and create patches from master to the tip of your branch. Same as a maintainer: you can apply patches in a different branch, check everything is alright and then merge it Patches only live in the mailing list and are not supposed to be manually handled on your machine
ClumsyPilot 6y ago
This, a thousand times this. I fail to understand how such an established and well funded project can lack somethong so basic, so core to the entire system. <rant> Every time I see people doing a dance and paising billion dollar companies like netflix, uber or deliveroo, I check them out, realise that they lack most essential functionality: Deliveroo didn't have Search(!) For restaraunts for like a year Netflix will sell you a 4K plan, but if your system has 4K screen but does not satisfy their '4K requirements' it won't tell you that you aren't gonna get 4K or what you are missing. Uber outright used to lie about time to arrive, in London all taxis were always 4 minutes away. So I I often wonder, we pulled resources and finance in billions across the world, and this is the best we can do?

pabs3 6y ago

There are lots of graphical history viewers, I use gitk mostly and git-big-picture to get a graphical overview graph without individual commits. The gitg GUI from GNOME is fairly good too, and of course there are better tools for proprietary operating systems.

rectang 6y ago
For local development, I'm actually content with what I get from the Git command line interface: I use a slightly customized variant of `git log --oneline --graph`. The problem is that I am often browsing the history of repositories hosted on Github via the Github web interface, along with other interactions such as searching through issues and PR history. Cloning a repo to my local machine and firing up gitk is a pretty inconvenient interruption of the web browsing experience.

0x0 6y ago

Gitlab has a great graph view

jlokier 6y ago

The GitHub linear view that shows no graph is a real problem on my team, because at least one team member has no idea when they are creating a complex, unbisectable graph with their merge commits and no-message submodule updates. To them the timeline is just a linear sequence of what everyone has been working on recently, mixed together. They do understand feature branches, but then they randomly merge their branches in progress and the result is still a mess somehow. To me, seeing the `git log --graph`, it's a difficult to understand mess with redundant micro-branches and micro-merges. Randomly unrelated file changes and even file deletions also occur - `git commit` might as well mean "copy my working directory into the repo". As a result, the main branch quality varies and cannot be trusted from one day to the next. The difference between us is I actually look at the repo history, I look at my commits before I commit them. They appear to commit things without even knowing what's going in, and don't look afterwards, as it's a surprise to them when I complain about things like a file deletion. GitHub's commit history view is part of the problem, because its presented as if it's the main, primary way to look at the history. It's not the problem, but it makes things worse. Better visualisation tools would help, but for now everyone has their own "pet way" of using Git, I lack the social capital to convince anyone to do better, and the gravity of GitHub as "the way" makes it difficult to get anyone to care about any alternative way of viewing the repo. "It's what everyone uses". GitHub issues similarly suck as a project management tool; guess what we're using.

WorldMaker 6y ago
The GitHub "network graph" is most known for exploring fork activity, but even in a single repo scenario with no forks you can still use it as a cudgel to show some idea of the complex graph if you need to stick with GitHub provided visualization tools. (It doesn't help that several UX redesigns have done nothing but bury the network graph, but it's still around.) You might think about investing in a copy of a client that puts the graph up front for that developer, such as GitKraken. Though I've actually had good success with a tool that is free and already out of the box in most git installs: gitk. gitk is ugly, but it gets the idea across and is easier to teach most developers to use than trying to get them to remember to add the --graph flag to git log. (Though adding a good alias for `git log --graph` or some further relative like `git log --graph --oneline` and encouraging them to use the alias instead is also another option.)

rakoo 6y ago

> I prefer to work with branches rather than a bunch of loose patch files The two are not mutually exclusive. You can have branches locally with the changes you're interested in and create patches from master to the tip of your branch. Same as a maintainer: you can apply patches in a different branch, check everything is alright and then merge it Patches only live in the mailing list and are not supposed to be manually handled on your machine

ClumsyPilot 6y ago

This, a thousand times this. I fail to understand how such an established and well funded project can lack somethong so basic, so core to the entire system. <rant> Every time I see people doing a dance and paising billion dollar companies like netflix, uber or deliveroo, I check them out, realise that they lack most essential functionality: Deliveroo didn't have Search(!) For restaraunts for like a year Netflix will sell you a 4K plan, but if your system has 4K screen but does not satisfy their '4K requirements' it won't tell you that you aren't gonna get 4K or what you are missing. Uber outright used to lie about time to arrive, in London all taxis were always 4 minutes away. So I I often wonder, we pulled resources and finance in billions across the world, and this is the best we can do?