Git

2632 readers

25 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

Follow programming.dev rules
Be excellent to each other, no hostility towards users for any reason
No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago

MODERATORS

[email protected]

Article argues that git is intrinsically confusing--if you could redesign git from scratch, what would you change? (dl.acm.org)

submitted 5 months ago by testeronious to c/[email protected]

28 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 7 points 5 months ago (1 children)

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.

[–] [email protected] 5 points 5 months ago (2 children)

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.

[–] [email protected] 3 points 5 months ago (1 children)

Do you ever use git log --graph ...?

[–] [email protected] 1 points 5 months ago

Yeah, I mostly use plain git log but on occasion

[–] [email protected] 2 points 5 months ago (1 children)

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.

[–] [email protected] 3 points 5 months ago (2 children)

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.

[–] [email protected] 2 points 5 months ago

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.

[–] [email protected] 1 points 5 months ago (1 children)

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.

[–] [email protected] 1 points 5 months ago

Like you say, there are always gonna be particular cases where gui/cli is better but for the general case I think it has to do with if your workflow is more terminal or gui oriented in general. I think that many of the tradeoffs in gui/cli git aren't really unique to git so I think sticking with your general preference in that are makes sense.

Since I'm a vim user (shocking, I know) I actually use git through the fugitive plugin a lot, but it's a fairly thin wrapper around the cli interface so most things are pretty much just the same as using the cli except that you can call them as vim commands instead (:Git push instead of git push and so on)