I just need a GUI or some sort of visual reference. I have trouble picturing what exactly is going on with each variant of the command. I’ve been able to fuddle through it every time I do some programming, and when I used Android Studio there were some GUI tools to use but otherwise I always get so confused. I think using IDEs would help in other projects but that’s a thing that keeps me from doing programming projects on the regular.
It’s free the same way that Sublime Text is: They’ll ask for a payment once a month, but you can say you’re “evaluating it” and use it for free. If you like it enough, you can pay for it. I have.
Yea my take with git for a while is that it is a naturally GUI oriented app/program much like text editors (who uses ed any more?), however much you’re a CLI only person.
Because it’s for managing code, and the moment you get used to or want syntax highlighting and want to inspect or view diffs/patches, then you’re in text-editor-like-GUI territory.
Beyond that, there’s viewing and searching logs/history, viewing and managing branches and remotes and generally navigating the history of a repo. Graphical interfaces help with all of that.
A quick example that struck me was viewing the diff between two distant (ie, not adjacent) commits. With a decent GUI, it can be two clicks (with a modifier key). A really nice way of revising the history of a repo especially when there are multiple branches.
There are diff plugins that have syntax highlighting, I use delta for example.
For viewing and searching logs, I prefer the terminal because that’s usually where I am anyway so alt-tabbing to a gui window means more context switching which isn’t a big deal but is enough for me to want to stay in the terminal.
You can just diff two commits on the cli with git diff commit1 commit2 but I guess that what you mean is that you might not have any specific reference two either of the commits so you have to browse through the log to find the commit message that describes the commit, which I’ll grant you is easier in a gui because you have two variables that you have to copy and paste if you’re in the terminal.
You can just diff two commits on the cli with git diff commit1 commit2 but I guess that what you mean is that you might not have any specific reference two either of the commits so you have to browse through the log to find the commit message that describes the commit, which I’ll grant you is easier in a gui because you have two variables that you have to copy and paste if you’re in the terminal.
Yea, this is what I’m talking about. When all of the visual affordances coalesce into a pretty simple flow.
And to be clear, I’d suspect many like myself end up using both, where there’ll always be some shortcoming in any given GUI that only the CLI can fill functionality/power wise. But defaulting to a GUI (or even a good TUI or editor plugin) for everyday usage, like I said, makes sense.
The original workflow, which is still in use today, is git-blame followed by git-show: look up candidate commits, then examine their history individually. This can be accelerated with a GUI; e.g. GitHub and GitLab support blame-style views.
I just need a GUI or some sort of visual reference. I have trouble picturing what exactly is going on with each variant of the command. I’ve been able to fuddle through it every time I do some programming, and when I used Android Studio there were some GUI tools to use but otherwise I always get so confused. I think using IDEs would help in other projects but that’s a thing that keeps me from doing programming projects on the regular.
Get Sourcetree
Nah, sourcetree has annoying bugs that never get fixed.
Use Fork, it’s a better sourcetree.
It’s free the same way that Sublime Text is: They’ll ask for a payment once a month, but you can say you’re “evaluating it” and use it for free. If you like it enough, you can pay for it. I have.
Cool thanks, I never heard of that one before, I’ll try it out
I’ve been using TortoiseGit since the beginning. Nothing ever came close for me.
I in the log view I have overview, filters, and all actions at hand.
I had to switch to linux sometimes and the horror of not having Tortoise there almost killed me
Yea my take with git for a while is that it is a naturally GUI oriented app/program much like text editors (who uses
ed
any more?), however much you’re a CLI only person.I don’t get that at all, to me using a GUI just gets in the way while on the CLI I can do whatever I want in a usually straightforward way.
Because it’s for managing code, and the moment you get used to or want syntax highlighting and want to inspect or view diffs/patches, then you’re in text-editor-like-GUI territory.
Beyond that, there’s viewing and searching logs/history, viewing and managing branches and remotes and generally navigating the history of a repo. Graphical interfaces help with all of that.
A quick example that struck me was viewing the diff between two distant (ie, not adjacent) commits. With a decent GUI, it can be two clicks (with a modifier key). A really nice way of revising the history of a repo especially when there are multiple branches.
There are diff plugins that have syntax highlighting, I use delta for example.
For viewing and searching logs, I prefer the terminal because that’s usually where I am anyway so alt-tabbing to a gui window means more context switching which isn’t a big deal but is enough for me to want to stay in the terminal.
You can just diff two commits on the cli with
git diff commit1 commit2
but I guess that what you mean is that you might not have any specific reference two either of the commits so you have to browse through the log to find the commit message that describes the commit, which I’ll grant you is easier in a gui because you have two variables that you have to copy and paste if you’re in the terminal.Yea, this is what I’m talking about. When all of the visual affordances coalesce into a pretty simple flow.
And to be clear, I’d suspect many like myself end up using both, where there’ll always be some shortcoming in any given GUI that only the CLI can fill functionality/power wise. But defaulting to a GUI (or even a good TUI or editor plugin) for everyday usage, like I said, makes sense.
The original workflow, which is still in use today, is
git-blame
followed bygit-show
: look up candidate commits, then examine their history individually. This can be accelerated with a GUI; e.g. GitHub and GitLab support blame-style views.Do you ever use
git log --graph ...
?