7 ms·

The problem is that source control is optimally a visual activity: the source control tree is a diagram, and the operations one does to it are diagrammatic. Te

The problem is that source control is optimally a visual activity: the source control tree is a diagram, and the operations one does to it are diagrammatic. Text-command-first approaches lead to inferior and hard to understand APIs which are, at best, papered over with a GUI. Managing the source of the project should be a series of trivial visual operations.

quickslowdown 2y ago
I learned the git CLI first, and still prefer it, but I've found VSCode's source control plugin very helpful for teaching newbies. I tell them to avoid the synch button and just manually git fetch/pull, but adding a commit is easier for a newbie to do visually. I also found LazyGit recently and think that's a good middleground for doing things from the CLI.
- irrational 2y ago
  If someone doesn’t use the CLI, they are a newbie? I’ve never needed to learn or use the CLI, the GitHub tools built into JetBrains IDEs and VS Code have always worked fine for me, and I’ve been a professional developer for nearly 30 years.
  - perching_aix 2y ago
    I think the idea is that the people you'd teach version control to are typically the newbies. You can also just be new to git specifically or the git workflow on any given project.
  - eddd-ddde 2y ago
    No, they said that for a git newbie, a gui will be easier.
  - quickslowdown 2y ago
    I never said if you're not using the CLI then you're a noob. I'm talking about people new to git in general.
- johnisgood 2y ago
  Emacs' magit is great too.
nlawalker 2y ago
Amen. The ever-present insistence that the command line is the only way to use git is the modern version of "ed is the standard text editor"[1] https://www.gnu.org/fun/jokes/ed-msg.html https://www.gnu.org/fun/jokes/ed-msg.html
- pixelpoet 2y ago
  Bothers me a lot that you're getting downvoted. Bunch of elitists who insist that cmdline is only way to get things done (everyone has to study cmdline options because who could possibly have multiple 4k screens for some visual options dialog?), probably using GDB in 2025 and having massive Stockholm syndrome about it, ...
  - skeeter2020 2y ago
    I don't consider myself a very core or talented developer, but I do feel quite strongly that git from the cmd line is much easier than a GUI, but overall ridiculously hard regardless. The abstractions and visualizations in graphical interfaces is either too dense & complicated, or more likely hides what's actually happening; there's no way to reduce the inherient complexity. My take: don't play the game. learn your basic required workflow from the command line and use the decent documentation to look up everything else.
    - mjburgess 2y ago
      NB. I did explicitly say a GUI on top of a cli app is a broken approach. Your intuition comes from this -- that the git API is cli-first. Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic. Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.
      - skydhash 2y ago
        The thing that CLI have over GUI is programmability, which for programmers is a valuable property. As for me, any repeatable task, I automate away with various degree of effort and quality. If I find myself needing a particular set of commands and flag, I create an alias, a function, or a shell script for that, like `flac2mp3.sh` instead of hunting down through the shell history. For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.
rectang 2y ago
The following command provides a visualization which is good enough to start from: git log --oneline --graph The more practical problem is that Github, which provides a useful graphic UI to complement the local command line for any project hosted there, is brain dead[1] about showing the source control tree as a tree and doesn't expose anything like `--graph`. If you get tired of typing `git log --oneline --graph`, you can add a `git slog` alias[2] for it by adding the following in `~/.gitconfig`: [alias] slog = log --oneline --graph [1] Gitlab is superior in this aspect, as it actually exposes a graph mode, via "[repo] > Code > Repository Graph". [2] Or if you want to get fancy: https://github.com/rectang/dotfiles/blob/064b22c42846f8a3f185564333e74244586606f0/gitextra#L9 https://github.com/rectang/dotfiles/blob/064b22c42846f8a3f18...
- timhh 2y ago
  `git log --graph` is just a really really bad GUI. Why not use a good GUI instead? Although in fairness it's quite hard to find a good Git GUI because there are so many bad ones. The only good ones I've found all have some kind of flaw: * GitX - the clearest design IMO, but it's one of those "gazillion forks" bits of software like TomatoUSB, and Mac only. Plus it has some annoying bugs. * Git Extensions - I didn't even realise this was a Git GUI until relatively recently because it its terrible name. It's pretty decent, but Windows only. * VSCode 'Git Graph' extension - my current favourite - it integrates into VSCode too which is much better than a standalone app, especially when using Remote SSH. However it is abandonware and although the source is available, the license doesn't let you republish it so it's not "open source" and nobody can take it over. Disappointingly even these don't let you do things that a GUI obviously should let you do, like copy & pasting commits, dragging and dropping to rebase. Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V? But, they're still miles better than `git log --graph`.
  - rectang 2y ago
    `git log --graph` without `--oneline` is pretty hard to follow — that's not what I use, and it's not what I suggested. With `--oneline`, it's not perfect but it's good enough to be useful — and by working within the constraints of the CLI, I didn't have to tell people to install software to get my point across. And I already spoke approvingly of Gitlab's GUI for graph representation! I don't disapprove of GUIs; I use them all the time (particularly Github's). One you grok the data structures that underlie Git, you wind up seeing front ends as interchangeable.
Tijdreiziger 2y ago
Chacon & Straub’s Pro Git, available for free online [1], is an excellent resource and has a lot of visual diagrams. [1] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
- rectang 2y ago
  I love this book. It's what helped me move from an intermediate Git user to an advanced one, and I've subsequently trained a bunch of people at different organizations by going through it. However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.
  - Tijdreiziger 2y ago
    You’re probably right about that. I used a certain interactive online course when I was a beginner, but they’ve added “AI assistance for guided coding help”, so I hesitate to recommend it. FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc https://git-scm.com/doc
- CamperBob2 2y ago
  500 pages (excuse me, 501) to document a source control tool. Something went very wrong here early on. But, lacking a time machine and a handgun, it's clearly unfixable.
  - Tijdreiziger 2y ago
    The first 6-7 chapters should teach you more than most Git users know (myself included, suppose I might be due a re-read!).
  - skydhash 2y ago
    Which you can read easily in a week or two without much effort for something that is currently de facto for software development. The Emacs Manual has ~700 pages.
SketchySeaBeast 2y ago
That's really it. Could I use the CLI? Sure. Do I? Nope. Using a tool like Git Extensions makes it so much easier to visualize what's going on. I have enough on my mind, I don't need to make the branch/merge/commit process harder than it is.
philipwhiuk 2y ago
This is why I've always liked gitk for anything non-trivial.
TheBigSalad 2y ago
I'm shocked nobody has a made a visual GUI to abstract git's weird API. There's sourceTree and whatnot, but it's so bad. So, so bad.
- astura 2y ago
  TortoiseGit?
- wipash 2y ago
  Try Fork, it's still obviously git, but it's the easiest I've found so far: https://git-fork.com/ https://git-fork.com/
- zo1 2y ago
  There are hundreds of them (everyone has an opinion about which is best). And most of them go out of their way to hide the nonsense that they have to jump through to get git to behave as the GUI expects it. Some of the visual git GUI tools do show you the gobbley-gook that they emit to the git CLI and it's shocking, like watching how the sausage is made.
BobbyTables2 2y ago
Also agree. Relied on gitk heavily when first started using git. People used to SVN and such will find git unfamiliar and scary. Once I understood it as a series of revisions where even branches have little meaning, I never used gitk again… The command line is actually very good if one gets in the habit of using something like “git log -oneline —reverse —no-merges origin/main..HEAD” to see where they are.
- Izkata 2y ago
  Mine is basically: git log --oneline --graph --all master~1.. A combination of "--all" and "branchname.." shows all descendant commits, and "--graph" shows their relationships visually.
ghfhghg 2y ago
Honestly this is a big reason why perforce is still my favorite source control solution. Along with p4v
- leprechaun1066 2y ago
  I use perforce for my personal projects. Helix P4V's various ways of visualising streams, diffs and revisions are so nice.
  - ghfhghg 2y ago
    Absolutely. Also graph and timeline view are invaluable for decades old projects when you are trying to find out when and why someone did some odd change.
asungy 2y ago
> source control is optimally a visual activity I'm not sure I entirely agree with this. I could see how this could be the case for newcomers to git, but after learning how git works through visual means, I think the mental model of how one should think of git is pretty simple (pleasantly simple, imo). Any complexity that comes from it may be due to how it is used (especially in a team setting).

quickslowdown 2y ago

I learned the git CLI first, and still prefer it, but I've found VSCode's source control plugin very helpful for teaching newbies. I tell them to avoid the synch button and just manually git fetch/pull, but adding a commit is easier for a newbie to do visually. I also found LazyGit recently and think that's a good middleground for doing things from the CLI.

irrational 2y ago
If someone doesn’t use the CLI, they are a newbie? I’ve never needed to learn or use the CLI, the GitHub tools built into JetBrains IDEs and VS Code have always worked fine for me, and I’ve been a professional developer for nearly 30 years.
- perching_aix 2y ago
  I think the idea is that the people you'd teach version control to are typically the newbies. You can also just be new to git specifically or the git workflow on any given project.
- eddd-ddde 2y ago
  No, they said that for a git newbie, a gui will be easier.
- quickslowdown 2y ago
  I never said if you're not using the CLI then you're a noob. I'm talking about people new to git in general.
johnisgood 2y ago
Emacs' magit is great too.

nlawalker 2y ago

Amen. The ever-present insistence that the command line is the only way to use git is the modern version of "ed is the standard text editor"[1] https://www.gnu.org/fun/jokes/ed-msg.html https://www.gnu.org/fun/jokes/ed-msg.html

pixelpoet 2y ago
Bothers me a lot that you're getting downvoted. Bunch of elitists who insist that cmdline is only way to get things done (everyone has to study cmdline options because who could possibly have multiple 4k screens for some visual options dialog?), probably using GDB in 2025 and having massive Stockholm syndrome about it, ...
- skeeter2020 2y ago
  I don't consider myself a very core or talented developer, but I do feel quite strongly that git from the cmd line is much easier than a GUI, but overall ridiculously hard regardless. The abstractions and visualizations in graphical interfaces is either too dense & complicated, or more likely hides what's actually happening; there's no way to reduce the inherient complexity. My take: don't play the game. learn your basic required workflow from the command line and use the decent documentation to look up everything else.
  - mjburgess 2y ago
    NB. I did explicitly say a GUI on top of a cli app is a broken approach. Your intuition comes from this -- that the git API is cli-first. Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic. Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.
    - skydhash 2y ago
      The thing that CLI have over GUI is programmability, which for programmers is a valuable property. As for me, any repeatable task, I automate away with various degree of effort and quality. If I find myself needing a particular set of commands and flag, I create an alias, a function, or a shell script for that, like `flac2mp3.sh` instead of hunting down through the shell history. For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.

rectang 2y ago

The following command provides a visualization which is good enough to start from: git log --oneline --graph The more practical problem is that Github, which provides a useful graphic UI to complement the local command line for any project hosted there, is brain dead[1] about showing the source control tree as a tree and doesn't expose anything like `--graph`. If you get tired of typing `git log --oneline --graph`, you can add a `git slog` alias[2] for it by adding the following in `~/.gitconfig`: [alias] slog = log --oneline --graph [1] Gitlab is superior in this aspect, as it actually exposes a graph mode, via "[repo] > Code > Repository Graph". [2] Or if you want to get fancy: https://github.com/rectang/dotfiles/blob/064b22c42846f8a3f185564333e74244586606f0/gitextra#L9 https://github.com/rectang/dotfiles/blob/064b22c42846f8a3f18...

timhh 2y ago
`git log --graph` is just a really really bad GUI. Why not use a good GUI instead? Although in fairness it's quite hard to find a good Git GUI because there are so many bad ones. The only good ones I've found all have some kind of flaw: * GitX - the clearest design IMO, but it's one of those "gazillion forks" bits of software like TomatoUSB, and Mac only. Plus it has some annoying bugs. * Git Extensions - I didn't even realise this was a Git GUI until relatively recently because it its terrible name. It's pretty decent, but Windows only. * VSCode 'Git Graph' extension - my current favourite - it integrates into VSCode too which is much better than a standalone app, especially when using Remote SSH. However it is abandonware and although the source is available, the license doesn't let you republish it so it's not "open source" and nobody can take it over. Disappointingly even these don't let you do things that a GUI obviously should let you do, like copy & pasting commits, dragging and dropping to rebase. Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V? But, they're still miles better than `git log --graph`.
- rectang 2y ago
  `git log --graph` without `--oneline` is pretty hard to follow — that's not what I use, and it's not what I suggested. With `--oneline`, it's not perfect but it's good enough to be useful — and by working within the constraints of the CLI, I didn't have to tell people to install software to get my point across. And I already spoke approvingly of Gitlab's GUI for graph representation! I don't disapprove of GUIs; I use them all the time (particularly Github's). One you grok the data structures that underlie Git, you wind up seeing front ends as interchangeable.

Tijdreiziger 2y ago

Chacon & Straub’s Pro Git, available for free online [1], is an excellent resource and has a lot of visual diagrams. [1] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

rectang 2y ago
I love this book. It's what helped me move from an intermediate Git user to an advanced one, and I've subsequently trained a bunch of people at different organizations by going through it. However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.
- Tijdreiziger 2y ago
  You’re probably right about that. I used a certain interactive online course when I was a beginner, but they’ve added “AI assistance for guided coding help”, so I hesitate to recommend it. FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc https://git-scm.com/doc
CamperBob2 2y ago
500 pages (excuse me, 501) to document a source control tool. Something went very wrong here early on. But, lacking a time machine and a handgun, it's clearly unfixable.
- Tijdreiziger 2y ago
  The first 6-7 chapters should teach you more than most Git users know (myself included, suppose I might be due a re-read!).
- skydhash 2y ago
  Which you can read easily in a week or two without much effort for something that is currently de facto for software development. The Emacs Manual has ~700 pages.

SketchySeaBeast 2y ago

That's really it. Could I use the CLI? Sure. Do I? Nope. Using a tool like Git Extensions makes it so much easier to visualize what's going on. I have enough on my mind, I don't need to make the branch/merge/commit process harder than it is.

philipwhiuk 2y ago

This is why I've always liked gitk for anything non-trivial.

TheBigSalad 2y ago

I'm shocked nobody has a made a visual GUI to abstract git's weird API. There's sourceTree and whatnot, but it's so bad. So, so bad.

astura 2y ago
TortoiseGit?
wipash 2y ago
Try Fork, it's still obviously git, but it's the easiest I've found so far: https://git-fork.com/ https://git-fork.com/
zo1 2y ago
There are hundreds of them (everyone has an opinion about which is best). And most of them go out of their way to hide the nonsense that they have to jump through to get git to behave as the GUI expects it. Some of the visual git GUI tools do show you the gobbley-gook that they emit to the git CLI and it's shocking, like watching how the sausage is made.

BobbyTables2 2y ago

Also agree. Relied on gitk heavily when first started using git. People used to SVN and such will find git unfamiliar and scary. Once I understood it as a series of revisions where even branches have little meaning, I never used gitk again… The command line is actually very good if one gets in the habit of using something like “git log -oneline —reverse —no-merges origin/main..HEAD” to see where they are.

Izkata 2y ago
Mine is basically: git log --oneline --graph --all master~1.. A combination of "--all" and "branchname.." shows all descendant commits, and "--graph" shows their relationships visually.

ghfhghg 2y ago

Honestly this is a big reason why perforce is still my favorite source control solution. Along with p4v

leprechaun1066 2y ago
I use perforce for my personal projects. Helix P4V's various ways of visualising streams, diffs and revisions are so nice.
- ghfhghg 2y ago
  Absolutely. Also graph and timeline view are invaluable for decades old projects when you are trying to find out when and why someone did some odd change.

asungy 2y ago

> source control is optimally a visual activity I'm not sure I entirely agree with this. I could see how this could be the case for newcomers to git, but after learning how git works through visual means, I think the mental model of how one should think of git is pretty simple (pleasantly simple, imo). Any complexity that comes from it may be due to how it is used (especially in a team setting).