8 ms·

Reinventing the Git Interface (2014)

86 points by macmac 10y ago

Ajedi32 10y ago
I'm sure this has been posted before, but regardless it's still extremely relevant. It's been almost 3 years now since this article was written, and I've still yet to see a git UI which is anywhere near as good as the one proposed here in terms of functionality and UX. If a GUI like this is ever implemented, I might finally be able to use something besides the CLI for my git client.
- inetknght 10y ago
  Git has `git log --gra.....` actually no nevermind that's far too obscure and useless. Just use `tig`. TUIs are generally more useful than GUIs in my experience anyway.
  - Ajedi32 10y ago
    > Git has `git log --gra.....` I have an alias `git lg` which does basically that. The only problem is that once I run that command and have that nice, pretty DAG, I can't manipulate any of those commits directly; I'm stuck manipulating the commit graph indirectly by typing out commands and copy-pasting commit hashes into the terminal. A decent GUI like the one described in this article would fix that.
    - hdhzy 10y ago
      Ha, I also use that alias. Simple operations can be done directly in gitk (moving branches etc.) but a real solution that'd make `git lg` editable would be an incredible boon.
- js2 10y ago
  > I'm sure this has been posted before Original discussion (41 points, 12 comments): https://news.ycombinator.com/item?id=7906511 https://news.ycombinator.com/item?id=7906511
- gregmac 10y ago
  GitKraken [1] has quite a few features that are very similar to what is shown in the article: * Switching branches with dirty working copy does an auto stash/pop (also stashes are shown visually in the timeline attached to the branch) * You can do a commit by editing the placeholder text in the timeline (though there's still a distinction between working copy and staged) * You can shift+click multiple commits and squash merge them * You can cherry pick by right-clicking, but not drag-and-drop * You can merge or rebase by dragging branches to each other (just found that out, I usually right-click) * It's a UI, so there's a visual DAG tree (and it's fairly nice looking) I have no affiliation with the company, I've just been using it for the past several months. [1] https://www.gitkraken.com/features https://www.gitkraken.com/features
david-given 10y ago
Sadly, 2014.
- lucb1e 10y ago
  Yet no less relevant for it.
gibbitz 10y ago
meh. I'm starting to hate using GUIs reaching out for the mouse is almost as irritating as clicking it. Since my hands are already on the keyboard, I may as well type... Maybe that's why this is unimplemented. Maybe I'm not alone.
- Ajedi32 10y ago
  The way I see it, the git DAG is fundamentally a graphical data structure, so it makes perfect sense to be able to manipulate it using a graphical interface. The only problem is there aren't really any UIs that take full advantage of git's nature as a DAG yet (at least, AFAIK). While I've yet to find a git GUI which approaches the same level of functionality the git CLI possesses, I think something like the UI proposed here might be good enough to finally get me to switch.
- ursus_bonum 10y ago
  This. By the time you get good enough at Git to make a reasonable GUI, you don't need/want it anymore.
- hosh 10y ago
  I do feel this way. I use mosh+tmux+emacs and do everything on the command line. My MBP is a very egregious machine that lets me use it as a very social, very smart terminal connecting into a cloud server. If my team adopts this tool, I probably would opt-out. However, my thinking and feeling about this has also been shifting in the past year. I've been slowly accepting more leadership functions where I work. My sense of myself as the heroic developer is eroding. I, as a single person, do not scale as well as a team. I'm learning about neurodiversity, how to be inclusive, what its advantages are. I'm learning about architecture in a different way -- understanding it as the empty space where best practices will naturally arise. So a lot of things are shifting in that, a year ago, I would not only feel this way about the tool, I would dismiss it as well. Now, I'm thinking of how this would benefit the team. Being the person on my team called in to perform git black magic, I've watched different people struggle with git. Having used git a lot, many of the basic git operations are practiced to the point of effortlessness. I don't really think much about the basics, and as such, I can compose those basics in higher-level operations. Many of the people on my team have not gotten to that point yet. By simplifying unnecessary concepts, someone would be able to use that version control to express higher level things. This proposed design covers many of the pain points. This includes writing it as a web backend (gitup will not work for our team and our tooling). I think it also enables collaboration I'd like my team to have (auto syncing branches for the whole team? hell yeah), but right now, is not doing so because git is too hard to use. I'm thinking of "empty space" here: I think this tooling shapes the empty space such that, the "best practice" is also "least effort", so people will naturally do the right things when it comes to version control and sharing code. For that, I'd support its use. Maybe not enough for me to give it up on my own workflow, but even that might change. I hope the author will develop this tool. The design is thoughtful and brilliant. Our team can sure use it.
rwbt 10y ago
That's why I switched to Fossil and now spend more time writing code than trying to deal with Git CLI weirdness.
- 2muchcoffeeman 10y ago
  How is fossil? I've really wanted to use that.
  - jaccarmac 10y ago
    Not OP, but I really like fossil. There are some rough edges, but the simple workflow is at least as simple as Git's and comes with QoL like the web interface.
  - rwbt 10y ago
    If you're a small team or solo developer, fossil just works. Highly recommended.
telekid 10y ago
magit[0] solves many of the issues identified here. It's the first tool I've used that makes git feel like a paint brush rather than a camera. [0] https://magit.vc/ https://magit.vc/
- jwr 10y ago
  I've been waiting for someone to mention magit. It is the only UI I know of that is more than just a git shell. Real thought went into it and it shows. It is faster and more convenient than the command line, which says a lot.
  - cygned 10y ago
    It's still not as fast as vim-fugitive for example. I know magit does more in nicer ways but the delay when staging, for example, is noticeable and can be annoying over time.
    - dota_fanatic 10y ago
      I'm not sure I follow. I hit s on my file in the Magit buffer and it's staged instantly; what delay are you referring to?
      - cygned 10y ago
        On my machine it takes like 400ms until it's staged. When working in vim, staging really instant.
- agumonkey 10y ago
  I stopped following magit closely after the big rewrite, but magit is goldmine, so lean and so mean.
marcrosoft 10y ago
I use CLI for almost everything except git after discovering gitup.
donatj 10y ago
> Everything is a commit. Treat working copy and staging area as commits, allow regular commit operations to be applied to them That… silly. No. That doesn't make any sense at all.
- ygra 10y ago
  To you, mayhaps. You'd be surprised in how many different ways people use tools.
- Ajedi32 10y ago
  Why not? A commit is essentially just a snapshot of the state of files in the repository, so IMO it makes perfect sense to treat the staging area and working copy the same as commits.
  - LyndsySimon 10y ago
    For one, I try to keep my commits as "atomic units of functionality", not just state snapshots. I often have three or four commits' worth of changes in my working copy, and sort through them carefully when one is complete to create a commit of only that small piece of functionality.
    - infogulch 10y ago
      Right... now your working copy is just a commit named WIP that sits at the top of the branch and is updated (--amend style) in real time. Wait! let me finish: So now you decide you want to move a part of the delta from WIP into a real commit. So split it and move some of the delta from WIP into the split and rename the split. It's the same workflow!
      - JadeNB 10y ago
        But surely "your workflow can be re-implemented in this different interface" is merely an argument that the different interface has not lost power, rather than necessarily that it is as good as (or even better than) the existing interface?
milesrout 10y ago
This is the first time I've read a complaint/discussion/review/whatever of git's UI and thought 'wow yeah I actually agree this would be useful'. I would still use the command line, a lot, but the times that I open `gitk --all --date-order` and a terminal side by side and refresh the gitk whenever I do a command to see what happens? THOSE are the times I would use this.
Djabx 10y ago
Hi, Have you given a try to: http://gitup.co/ http://gitup.co/ There not everything you wanted, but maybe...
- macmac 10y ago
  gitup looks neat, but unfortunately macOS only.
  - donarb 10y ago
    It is Mac only, but it is open source (Obj-C). Some enterprising developer could port it to Windows or Linux. https://github.com/git-up/GitUp https://github.com/git-up/GitUp
falsedan 10y ago
> You may have noticed that Git warns you a lot. Rebase is dangerous, headless state is dangerous, don’t do push -f, are you sure, think twice, you’re not supposed to do that, stuff like that Hmmm… > Remove warnings as Git repo is immutable and cannot lose data Ok this is a great response! There's also this wishlist/proposals for git log[0], which are extremely exciting to think about; it's from 2012, so even older than the article… [0]: https://gist.github.com/datagrok/4221767 https://gist.github.com/datagrok/4221767
- xyzzyz 10y ago
  It's not completely true, you can easily lose data in Git by accident. Here's an example. Suppose we have a single "master" branch, pointing to commit A. You create a new "feature" branch, making commits B, and then C. You realize that B and C are actually unrelated, so you want each of them to have separate branches. You git rebase --interactive onto master, picking only commit C. This way feature branch has commit C with parent A. Now, you git checkout commit B, which should put you into detached HEAD state, from which you plan to create a second feature branch. Alas, something has triggered git gc in the meantime, and commit B has been garbage collected, as it was no longer pointed to by anything. Something like this happened to me, breaking the whole Chromium repo for half an hour. Definitely not fun.
  - dota_fanatic 10y ago
    > You git rebase --interactive onto master, picking only commit C. So during an interactive rebase you drop one commit, and pick the other, then are upset at git for dropping your commit? It did exactly what you asked of it. This would have easily been avoided if you had branched off your feature branch into a new one and did the interactive rebase there. Your old feature branch is still present, which you could rebase interactively, or drop HEAD so you only have the other commit, or whatever other thing to meet its needs.
    - xyzzyz 10y ago
      Sure, I know now exactly what happened, and what I should have done in order to avoid it. My point here is that "Git repo is immutable and cannot lose data" is a lie, and people who believe it (like I did at the time -- hey, if anything breaks on rebase, I can always git reflog and reset to good state, right?) will have a bad time at some point down the line, so it's better to stop this lie from spreading.
hosh 10y ago
This is a great UX rethink along actual user needs. It's unusual to see someone with more-than-superficial knowledge of git that also has enough product sense to come up with something like this. My team has varying levels of git skill, including product owners and testers. I am usually called in to do the git black magic -- and I only know a fraction of what is available on git. My git magic doesn't scale. Further, because we are using our dev environment in a VM, a remote client is harder to work with. Making this web-based would work out very well for us. (And power users can still use the command line tool instead). I hope this comes to fruition. My team can sure use it.
ilovecomputers 10y ago
Now I'm wishing GitUp had this selection tool. Sadly you can only do operations one commit/branch at a time.
sbzoom 10y ago
Just stop using Git. Jeez. I don't get it. It is a fundamentally broken tool. Why do people insist on using it? I have been confused about this for years. Just use something else. ANYTHING else. I understand the usefulness (and popularity) of GitHub. It is a great tool for collaboration. Its just too bad that it uses git as the underlying vcs. I wish there was a decent competitor to GitHub with a different vcs so we could see if people would make the switch. Oh well. Maybe someday.
- ahuth 10y ago
  What's fundamentally wrong with it? I haven't used anything else, and therefore don't have great context. Haven't felt like anything about it is horrible, though.
- dijit 10y ago
  Usually when giving out criticism it is wise to be specific. In this case, git can be awkward to use, but the underlying architecture is sound and it's a welcome change to centralised version control systems (CVS/SVN/Perforce). Not saying you're wrong of course, but as far as I currently understand it's objectively better on all fronts except UX for DVCS. Perforce is undoubtedly better but it relies on a constant connection to a server.
  - hinkley 10y ago
    Don't play coy. The ergonomic shortcomings of git 'porcelain' are discussed here and elsewhere so often that if you don't know what people are talking about you either have a vested interest in deflecting, or you have actually been living under a rock. If the latter, save yourself, don't read the newspaper. It's too late for the rest of us.
  - sbzoom 10y ago
    Most people moved from something like CVS/SVN/Perforce to Git. There are also a lot of people who started using Git at their first job. And most of these developers think of it as the same thing as GitHub. As others have said on this thread, you could try Mercurial. It is pretty nice. More user friendly than Git. But it does not do branching well. The original design did not include "named" branches, it was added later. Because of this it feels like it. The usual way that people work in Mercurial is to make a clone - which is a whole copy. If you were working in SVN you would probably make a branch first (on the server), and then check out that branch. When you are done with your branch, you get up to date with trunk, then merge it in. And, this is the important part, your merge is treated as one commit. Pretty normal stuff. Mercurial though threads all your local commits into the log. So even though you make one merge, you can't find that merge in the log. All the commits are shown stuffed in there by date. And everyone is sad. Now, you can change that if you use named branches instead of cloning. But it has other problems. The biggest one is you get "multiple heads." If I make a branch and you make a branch and we both commit, they both get stored in the index. But they get stored as different heads. So when I do a "pull" I get this strange warning about multiple heads - the "trunk" and your branch. I'm actually still not sure how to unwind it actually. I'm not enough of an expert. So I try to user Bazaar wherever I go. It doesn't always happen - it is hard to change people's minds or have a company that is flexible enough to try different solutions. And, because Git is so popular, there is an integration with just about everything. For a 3-rd party candidate like Bazaar IDE integration is half-baked. So is Jira integration. Actually, just about all integrations. I'm considering becoming a committer on like 10 different Bazaar-related projects. :) Check this out: https://duckrowing.com/2014/04/25/git-vs-mercurial-vs-bazaar-vs-etc/ https://duckrowing.com/2014/04/25/git-vs-mercurial-vs-bazaar... Yes GitHub is popular. But out there in the non-Opensource world, Git is WAY behind SVN. Which is totally fine. Use what works. If you have a centralized development organization, and everyone sits near each other and talks all the time, why do you need distributed VCS? And if everyone at the company knows how to use a tool and there aren't constant mistakes - just use it. It gets easy to not be able to see the forest for the trees when you spend 6 hours trying to figure out how to rewind a busted git repo.
ursus_bonum 10y ago
This is such a classic example of not thinking things through. The graphical manipulation stuff sounds cool until you think about what happens when it causes merge conflicts. I mean the graph stuff is still cool but it does very little for the hard problems. The automatic committing for WIP and "magic" pushing/fetching sounds cool until someone switches branches and accidentally commits 3.1TB of junk files they left lying around and it automatically syncs to EVERYONE else on the project. People complain now that Git is "too complex" just wait until it's automagically doing shit like that.
- notgood 10y ago
  Strongly disagree, the software should always list/show the files being commited in a little pop-up, if you see it is comitting a lot of files or something very big you should be able to press a "cancel" button; you know, like a regular OS file-copying dialog works.
  - ursus_bonum 10y ago
    That's fine but the article doesn't mention any popups. It just makes it sound like all of this will happen in the background without bothering the user.
  - stouset 10y ago
    Having worked with people who use these types of magic GUI tools that "hide the complexity" of $VCS, this shit happens all the time. When they exist, popups are clicked through and ignored just as they are in every other computing context. And in the end, these tools are just a shorthand for "I don't have the time, desire, and/or motivation to understand how to operate the tools I rely on for work." Not to argue that that perspective is bad or wrong, it just is what it is. And when someone doesn't understand a tool that operates an inherently complex system, it will inevitably lead to misuse.
- alexeiz 10y ago
  This is spot on. I have observed this very thing happen with co-workers who abuse git aliases to "avoid git complexity." They have an alias for, say, "add everything, commit and push" and they end up committing all kinds of random files to the repository. Or with another alias, they manage to merge random branches into their working branch and they don't understand how that happened. Another example is the VS Code "git sync" button. I'm never quite sure what's going to happen if I press it. Will my branch get merged with upstream? Or rebased? Am I going to end up with the working tree in the unpredictable state? This is where the Python guideline "explicit is better than implicit" applies to git perfectly. Git already does a substantial amount of work under the hood with porcelain commands. There is no benefit of stripping git off the fundamental concepts like branches, remotes and staging. It doesn't simplify the conceptual understanding of git, but only obscures the git behavior.
glandium 10y ago
> This brings very important addition to the table — ability to explicitly checkout STAGED version. Git’s index won’t allow you that. Of course it will. In fact, that's very much what `git checkout` does if you don't give a revision but give a path, e.g. `git checkout .`. (but then you lose any unstaged changes)
rjmunro 10y ago
I recently discovered the magical incantation: gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' ) which show's all the git commits in the repository, even those that are not on any branches any more. It's perfect if you need to find an old commit to undo a rebase, or if you accidentally deleted a branch. It really should be a button in GUIs called "show all commits" or something". I even posted a bug in gitx suggesting they add the feature: https://github.com/gitx/gitx/issues/78 https://github.com/gitx/gitx/issues/78 Source: http://stackoverflow.com/a/91795/3408 http://stackoverflow.com/a/91795/3408
- mdns33 10y ago
  have u heard about tig? try it
xenadu02 10y ago
>You may think auto-sync will completely ruin your familiar “commit now, restructure later” workflow. It will not. As you’re working in your branch, you can still reorganise, restructure, reorder and rename commits in your branch. These changes will be incrementally synced to all other peoples’ machines as you go. They’ll initially see your mess, but then they’ll see all the changes you’re doing to make your branch look pretty. All happening without any manual button clicking/remotes selections/any other decisions from them. As this branch is yours, it’s a perfectly safe and does not require any human intervention. One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge. No more "2 down / 5 up" commits because of a rebase; instead you'd see "3 new (2 rebased)".
- jcranmer 10y ago
  > One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge. This is ripe for flaming, but this is how mercurial handles rebasing under changeset evolution, and it's pretty much the biggest area where hg gets something right that git got wrong. Basically, it keeps around the old changeset of the rebase and adds a new kind of edge to indicate the update of the rebase, as well as keeping the obsolete changesets from being seen by most users while maintaining them internally. This means that normal rebase operations can see the old and new versions of a changeset as if they were regular changesets. Combined with phases, it's also easy to set up your repositories so that you can never accidentally rebase your master branch.
aequitas 10y ago
Some of the points mentioned are covered by the Ungit tool: https://github.com/FredrikNoren/ungit https://github.com/FredrikNoren/ungit In terms of how your intended changes are visualized in the DAG model. I stopped using this tool after getting a beter understanding of Git core and how the commands manipulate the database. But I do still think the changes suggested in the post are valuable. I'm not inline with the whole GUI idea. But I like the concept of 'everything is a commit' and reducing the 'delta algebra' to their basic forms. As my biggest struggle with Git is always to make the translation of my intended change to the database into an abstract Git command.
shabbyrobe 10y ago
This is especially funny considering the huge discussion recently about rewriting curl and then the entire world in Rust, but imagine you lived in a world where the magical "better tool" already existed and all you had to do was discover it. Leaving fantasy-land aside for a moment, this morning you woke up in the real world. In the real world, that tool does already exist, and it's called Mercurial. If you try command-line Mercurial for long enough to get past the initial "oh no Windows/macOS/Linux got updates and moved all my icons" muscle-memory-refresh phase (and especially if you last long enough to get into revsets and templates), you'll find it extraordinarily difficult to go back to using command-line git. Your power grows with Mercurial as you learn more about it because you aren't constantly fighting the complete absence of idioms and opaque "man-page" style of documentation that puts a slab of inscrutable text front and centre and neglects to provide simple examples for common problems (apparently we have a perfectly good Stack Overflow for that). The git boosters will respond to this by saying, as they always do, "yes, but the real power of git is in the model of the information under the hood. The CLI is just an interface, if you don't like it you should spend months studying the internals and build your own workflow on top of git". Again, back in the real world, who has time for that? Or the interest? Especially when, as I already mentioned, that tool does already exist and it's called Mercurial and you can get started with it right now. Both tools can do close to exactly the same things under the hood with differences that won't make a lick of difference to the vast majority of users. The user-facing differences are where it really matters: one tool has an excellent CLI which is clear, concise and discoverable; the other has github. Damn. Lousy network effects.
- paulddraper 10y ago
  Mercurial is nowhere near the idilic interface you imply. E.g. I challenge you to figure out how to use its interface to delete a branch. http://stackoverflow.com/questions/41968796/how-to-delete-a-remote-branch-in-mercurial http://stackoverflow.com/questions/41968796/how-to-delete-a-...
  - ngoldbaum 10y ago
    You can close a branch, which makes it stop appearing in the UI unless you explicitly ask for closed branches. You can never fully delete a branch since the branch is part of the commit metadata (as it should be, IMO).

86 points by macmac 10y ago

I'm sure this has been posted before, but regardless it's still extremely relevant. It's been almost 3 years now since this article was written, and I've still yet to see a git UI which is anywhere near as good as the one proposed here in terms of functionality and UX. If a GUI like this is ever implemented, I might finally be able to use something besides the CLI for my git client.

inetknght 10y ago
Git has `git log --gra.....` actually no nevermind that's far too obscure and useless. Just use `tig`. TUIs are generally more useful than GUIs in my experience anyway.
- Ajedi32 10y ago
  > Git has `git log --gra.....` I have an alias `git lg` which does basically that. The only problem is that once I run that command and have that nice, pretty DAG, I can't manipulate any of those commits directly; I'm stuck manipulating the commit graph indirectly by typing out commands and copy-pasting commit hashes into the terminal. A decent GUI like the one described in this article would fix that.
  - hdhzy 10y ago
    Ha, I also use that alias. Simple operations can be done directly in gitk (moving branches etc.) but a real solution that'd make `git lg` editable would be an incredible boon.
js2 10y ago
> I'm sure this has been posted before Original discussion (41 points, 12 comments): https://news.ycombinator.com/item?id=7906511 https://news.ycombinator.com/item?id=7906511
gregmac 10y ago
GitKraken [1] has quite a few features that are very similar to what is shown in the article: * Switching branches with dirty working copy does an auto stash/pop (also stashes are shown visually in the timeline attached to the branch) * You can do a commit by editing the placeholder text in the timeline (though there's still a distinction between working copy and staged) * You can shift+click multiple commits and squash merge them * You can cherry pick by right-clicking, but not drag-and-drop * You can merge or rebase by dragging branches to each other (just found that out, I usually right-click) * It's a UI, so there's a visual DAG tree (and it's fairly nice looking) I have no affiliation with the company, I've just been using it for the past several months. [1] https://www.gitkraken.com/features https://www.gitkraken.com/features

david-given 10y ago

Sadly, 2014.

lucb1e 10y ago
Yet no less relevant for it.

gibbitz 10y ago

meh. I'm starting to hate using GUIs reaching out for the mouse is almost as irritating as clicking it. Since my hands are already on the keyboard, I may as well type... Maybe that's why this is unimplemented. Maybe I'm not alone.

Ajedi32 10y ago
The way I see it, the git DAG is fundamentally a graphical data structure, so it makes perfect sense to be able to manipulate it using a graphical interface. The only problem is there aren't really any UIs that take full advantage of git's nature as a DAG yet (at least, AFAIK). While I've yet to find a git GUI which approaches the same level of functionality the git CLI possesses, I think something like the UI proposed here might be good enough to finally get me to switch.
ursus_bonum 10y ago
This. By the time you get good enough at Git to make a reasonable GUI, you don't need/want it anymore.
hosh 10y ago
I do feel this way. I use mosh+tmux+emacs and do everything on the command line. My MBP is a very egregious machine that lets me use it as a very social, very smart terminal connecting into a cloud server. If my team adopts this tool, I probably would opt-out. However, my thinking and feeling about this has also been shifting in the past year. I've been slowly accepting more leadership functions where I work. My sense of myself as the heroic developer is eroding. I, as a single person, do not scale as well as a team. I'm learning about neurodiversity, how to be inclusive, what its advantages are. I'm learning about architecture in a different way -- understanding it as the empty space where best practices will naturally arise. So a lot of things are shifting in that, a year ago, I would not only feel this way about the tool, I would dismiss it as well. Now, I'm thinking of how this would benefit the team. Being the person on my team called in to perform git black magic, I've watched different people struggle with git. Having used git a lot, many of the basic git operations are practiced to the point of effortlessness. I don't really think much about the basics, and as such, I can compose those basics in higher-level operations. Many of the people on my team have not gotten to that point yet. By simplifying unnecessary concepts, someone would be able to use that version control to express higher level things. This proposed design covers many of the pain points. This includes writing it as a web backend (gitup will not work for our team and our tooling). I think it also enables collaboration I'd like my team to have (auto syncing branches for the whole team? hell yeah), but right now, is not doing so because git is too hard to use. I'm thinking of "empty space" here: I think this tooling shapes the empty space such that, the "best practice" is also "least effort", so people will naturally do the right things when it comes to version control and sharing code. For that, I'd support its use. Maybe not enough for me to give it up on my own workflow, but even that might change. I hope the author will develop this tool. The design is thoughtful and brilliant. Our team can sure use it.

rwbt 10y ago

That's why I switched to Fossil and now spend more time writing code than trying to deal with Git CLI weirdness.

2muchcoffeeman 10y ago
How is fossil? I've really wanted to use that.
- jaccarmac 10y ago
  Not OP, but I really like fossil. There are some rough edges, but the simple workflow is at least as simple as Git's and comes with QoL like the web interface.
- rwbt 10y ago
  If you're a small team or solo developer, fossil just works. Highly recommended.

telekid 10y ago

magit[0] solves many of the issues identified here. It's the first tool I've used that makes git feel like a paint brush rather than a camera. [0] https://magit.vc/ https://magit.vc/

jwr 10y ago
I've been waiting for someone to mention magit. It is the only UI I know of that is more than just a git shell. Real thought went into it and it shows. It is faster and more convenient than the command line, which says a lot.
- cygned 10y ago
  It's still not as fast as vim-fugitive for example. I know magit does more in nicer ways but the delay when staging, for example, is noticeable and can be annoying over time.
  - dota_fanatic 10y ago
    I'm not sure I follow. I hit s on my file in the Magit buffer and it's staged instantly; what delay are you referring to?
    - cygned 10y ago
      On my machine it takes like 400ms until it's staged. When working in vim, staging really instant.
agumonkey 10y ago
I stopped following magit closely after the big rewrite, but magit is goldmine, so lean and so mean.

marcrosoft 10y ago

I use CLI for almost everything except git after discovering gitup.

donatj 10y ago

> Everything is a commit. Treat working copy and staging area as commits, allow regular commit operations to be applied to them That… silly. No. That doesn't make any sense at all.

ygra 10y ago
To you, mayhaps. You'd be surprised in how many different ways people use tools.
Ajedi32 10y ago
Why not? A commit is essentially just a snapshot of the state of files in the repository, so IMO it makes perfect sense to treat the staging area and working copy the same as commits.
- LyndsySimon 10y ago
  For one, I try to keep my commits as "atomic units of functionality", not just state snapshots. I often have three or four commits' worth of changes in my working copy, and sort through them carefully when one is complete to create a commit of only that small piece of functionality.
  - infogulch 10y ago
    Right... now your working copy is just a commit named WIP that sits at the top of the branch and is updated (--amend style) in real time. Wait! let me finish: So now you decide you want to move a part of the delta from WIP into a real commit. So split it and move some of the delta from WIP into the split and rename the split. It's the same workflow!
    - JadeNB 10y ago
      But surely "your workflow can be re-implemented in this different interface" is merely an argument that the different interface has not lost power, rather than necessarily that it is as good as (or even better than) the existing interface?

milesrout 10y ago

This is the first time I've read a complaint/discussion/review/whatever of git's UI and thought 'wow yeah I actually agree this would be useful'. I would still use the command line, a lot, but the times that I open `gitk --all --date-order` and a terminal side by side and refresh the gitk whenever I do a command to see what happens? THOSE are the times I would use this.

Djabx 10y ago

Hi, Have you given a try to: http://gitup.co/ http://gitup.co/ There not everything you wanted, but maybe...

macmac 10y ago
gitup looks neat, but unfortunately macOS only.
- donarb 10y ago
  It is Mac only, but it is open source (Obj-C). Some enterprising developer could port it to Windows or Linux. https://github.com/git-up/GitUp https://github.com/git-up/GitUp

falsedan 10y ago

> You may have noticed that Git warns you a lot. Rebase is dangerous, headless state is dangerous, don’t do push -f, are you sure, think twice, you’re not supposed to do that, stuff like that Hmmm… > Remove warnings as Git repo is immutable and cannot lose data Ok this is a great response! There's also this wishlist/proposals for git log[0], which are extremely exciting to think about; it's from 2012, so even older than the article… [0]: https://gist.github.com/datagrok/4221767 https://gist.github.com/datagrok/4221767

xyzzyz 10y ago
It's not completely true, you can easily lose data in Git by accident. Here's an example. Suppose we have a single "master" branch, pointing to commit A. You create a new "feature" branch, making commits B, and then C. You realize that B and C are actually unrelated, so you want each of them to have separate branches. You git rebase --interactive onto master, picking only commit C. This way feature branch has commit C with parent A. Now, you git checkout commit B, which should put you into detached HEAD state, from which you plan to create a second feature branch. Alas, something has triggered git gc in the meantime, and commit B has been garbage collected, as it was no longer pointed to by anything. Something like this happened to me, breaking the whole Chromium repo for half an hour. Definitely not fun.
- dota_fanatic 10y ago
  > You git rebase --interactive onto master, picking only commit C. So during an interactive rebase you drop one commit, and pick the other, then are upset at git for dropping your commit? It did exactly what you asked of it. This would have easily been avoided if you had branched off your feature branch into a new one and did the interactive rebase there. Your old feature branch is still present, which you could rebase interactively, or drop HEAD so you only have the other commit, or whatever other thing to meet its needs.
  - xyzzyz 10y ago
    Sure, I know now exactly what happened, and what I should have done in order to avoid it. My point here is that "Git repo is immutable and cannot lose data" is a lie, and people who believe it (like I did at the time -- hey, if anything breaks on rebase, I can always git reflog and reset to good state, right?) will have a bad time at some point down the line, so it's better to stop this lie from spreading.

hosh 10y ago

This is a great UX rethink along actual user needs. It's unusual to see someone with more-than-superficial knowledge of git that also has enough product sense to come up with something like this. My team has varying levels of git skill, including product owners and testers. I am usually called in to do the git black magic -- and I only know a fraction of what is available on git. My git magic doesn't scale. Further, because we are using our dev environment in a VM, a remote client is harder to work with. Making this web-based would work out very well for us. (And power users can still use the command line tool instead). I hope this comes to fruition. My team can sure use it.

ilovecomputers 10y ago

Now I'm wishing GitUp had this selection tool. Sadly you can only do operations one commit/branch at a time.

sbzoom 10y ago

Just stop using Git. Jeez. I don't get it. It is a fundamentally broken tool. Why do people insist on using it? I have been confused about this for years. Just use something else. ANYTHING else. I understand the usefulness (and popularity) of GitHub. It is a great tool for collaboration. Its just too bad that it uses git as the underlying vcs. I wish there was a decent competitor to GitHub with a different vcs so we could see if people would make the switch. Oh well. Maybe someday.

ahuth 10y ago
What's fundamentally wrong with it? I haven't used anything else, and therefore don't have great context. Haven't felt like anything about it is horrible, though.
dijit 10y ago
Usually when giving out criticism it is wise to be specific. In this case, git can be awkward to use, but the underlying architecture is sound and it's a welcome change to centralised version control systems (CVS/SVN/Perforce). Not saying you're wrong of course, but as far as I currently understand it's objectively better on all fronts except UX for DVCS. Perforce is undoubtedly better but it relies on a constant connection to a server.
- hinkley 10y ago
  Don't play coy. The ergonomic shortcomings of git 'porcelain' are discussed here and elsewhere so often that if you don't know what people are talking about you either have a vested interest in deflecting, or you have actually been living under a rock. If the latter, save yourself, don't read the newspaper. It's too late for the rest of us.
- sbzoom 10y ago
  Most people moved from something like CVS/SVN/Perforce to Git. There are also a lot of people who started using Git at their first job. And most of these developers think of it as the same thing as GitHub. As others have said on this thread, you could try Mercurial. It is pretty nice. More user friendly than Git. But it does not do branching well. The original design did not include "named" branches, it was added later. Because of this it feels like it. The usual way that people work in Mercurial is to make a clone - which is a whole copy. If you were working in SVN you would probably make a branch first (on the server), and then check out that branch. When you are done with your branch, you get up to date with trunk, then merge it in. And, this is the important part, your merge is treated as one commit. Pretty normal stuff. Mercurial though threads all your local commits into the log. So even though you make one merge, you can't find that merge in the log. All the commits are shown stuffed in there by date. And everyone is sad. Now, you can change that if you use named branches instead of cloning. But it has other problems. The biggest one is you get "multiple heads." If I make a branch and you make a branch and we both commit, they both get stored in the index. But they get stored as different heads. So when I do a "pull" I get this strange warning about multiple heads - the "trunk" and your branch. I'm actually still not sure how to unwind it actually. I'm not enough of an expert. So I try to user Bazaar wherever I go. It doesn't always happen - it is hard to change people's minds or have a company that is flexible enough to try different solutions. And, because Git is so popular, there is an integration with just about everything. For a 3-rd party candidate like Bazaar IDE integration is half-baked. So is Jira integration. Actually, just about all integrations. I'm considering becoming a committer on like 10 different Bazaar-related projects. :) Check this out: https://duckrowing.com/2014/04/25/git-vs-mercurial-vs-bazaar-vs-etc/ https://duckrowing.com/2014/04/25/git-vs-mercurial-vs-bazaar... Yes GitHub is popular. But out there in the non-Opensource world, Git is WAY behind SVN. Which is totally fine. Use what works. If you have a centralized development organization, and everyone sits near each other and talks all the time, why do you need distributed VCS? And if everyone at the company knows how to use a tool and there aren't constant mistakes - just use it. It gets easy to not be able to see the forest for the trees when you spend 6 hours trying to figure out how to rewind a busted git repo.

ursus_bonum 10y ago

This is such a classic example of not thinking things through. The graphical manipulation stuff sounds cool until you think about what happens when it causes merge conflicts. I mean the graph stuff is still cool but it does very little for the hard problems. The automatic committing for WIP and "magic" pushing/fetching sounds cool until someone switches branches and accidentally commits 3.1TB of junk files they left lying around and it automatically syncs to EVERYONE else on the project. People complain now that Git is "too complex" just wait until it's automagically doing shit like that.

notgood 10y ago
Strongly disagree, the software should always list/show the files being commited in a little pop-up, if you see it is comitting a lot of files or something very big you should be able to press a "cancel" button; you know, like a regular OS file-copying dialog works.
- ursus_bonum 10y ago
  That's fine but the article doesn't mention any popups. It just makes it sound like all of this will happen in the background without bothering the user.
- stouset 10y ago
  Having worked with people who use these types of magic GUI tools that "hide the complexity" of $VCS, this shit happens all the time. When they exist, popups are clicked through and ignored just as they are in every other computing context. And in the end, these tools are just a shorthand for "I don't have the time, desire, and/or motivation to understand how to operate the tools I rely on for work." Not to argue that that perspective is bad or wrong, it just is what it is. And when someone doesn't understand a tool that operates an inherently complex system, it will inevitably lead to misuse.
alexeiz 10y ago
This is spot on. I have observed this very thing happen with co-workers who abuse git aliases to "avoid git complexity." They have an alias for, say, "add everything, commit and push" and they end up committing all kinds of random files to the repository. Or with another alias, they manage to merge random branches into their working branch and they don't understand how that happened. Another example is the VS Code "git sync" button. I'm never quite sure what's going to happen if I press it. Will my branch get merged with upstream? Or rebased? Am I going to end up with the working tree in the unpredictable state? This is where the Python guideline "explicit is better than implicit" applies to git perfectly. Git already does a substantial amount of work under the hood with porcelain commands. There is no benefit of stripping git off the fundamental concepts like branches, remotes and staging. It doesn't simplify the conceptual understanding of git, but only obscures the git behavior.

glandium 10y ago

> This brings very important addition to the table — ability to explicitly checkout STAGED version. Git’s index won’t allow you that. Of course it will. In fact, that's very much what `git checkout` does if you don't give a revision but give a path, e.g. `git checkout .`. (but then you lose any unstaged changes)

rjmunro 10y ago

I recently discovered the magical incantation: gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' ) which show's all the git commits in the repository, even those that are not on any branches any more. It's perfect if you need to find an old commit to undo a rebase, or if you accidentally deleted a branch. It really should be a button in GUIs called "show all commits" or something". I even posted a bug in gitx suggesting they add the feature: https://github.com/gitx/gitx/issues/78 https://github.com/gitx/gitx/issues/78 Source: http://stackoverflow.com/a/91795/3408 http://stackoverflow.com/a/91795/3408

mdns33 10y ago
have u heard about tig? try it

xenadu02 10y ago

>You may think auto-sync will completely ruin your familiar “commit now, restructure later” workflow. It will not. As you’re working in your branch, you can still reorganise, restructure, reorder and rename commits in your branch. These changes will be incrementally synced to all other peoples’ machines as you go. They’ll initially see your mess, but then they’ll see all the changes you’re doing to make your branch look pretty. All happening without any manual button clicking/remotes selections/any other decisions from them. As this branch is yours, it’s a perfectly safe and does not require any human intervention. One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge. No more "2 down / 5 up" commits because of a rebase; instead you'd see "3 new (2 rebased)".

jcranmer 10y ago
> One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge. This is ripe for flaming, but this is how mercurial handles rebasing under changeset evolution, and it's pretty much the biggest area where hg gets something right that git got wrong. Basically, it keeps around the old changeset of the rebase and adds a new kind of edge to indicate the update of the rebase, as well as keeping the obsolete changesets from being seen by most users while maintaining them internally. This means that normal rebase operations can see the old and new versions of a changeset as if they were regular changesets. Combined with phases, it's also easy to set up your repositories so that you can never accidentally rebase your master branch.

aequitas 10y ago

Some of the points mentioned are covered by the Ungit tool: https://github.com/FredrikNoren/ungit https://github.com/FredrikNoren/ungit In terms of how your intended changes are visualized in the DAG model. I stopped using this tool after getting a beter understanding of Git core and how the commands manipulate the database. But I do still think the changes suggested in the post are valuable. I'm not inline with the whole GUI idea. But I like the concept of 'everything is a commit' and reducing the 'delta algebra' to their basic forms. As my biggest struggle with Git is always to make the translation of my intended change to the database into an abstract Git command.

shabbyrobe 10y ago

This is especially funny considering the huge discussion recently about rewriting curl and then the entire world in Rust, but imagine you lived in a world where the magical "better tool" already existed and all you had to do was discover it. Leaving fantasy-land aside for a moment, this morning you woke up in the real world. In the real world, that tool does already exist, and it's called Mercurial. If you try command-line Mercurial for long enough to get past the initial "oh no Windows/macOS/Linux got updates and moved all my icons" muscle-memory-refresh phase (and especially if you last long enough to get into revsets and templates), you'll find it extraordinarily difficult to go back to using command-line git. Your power grows with Mercurial as you learn more about it because you aren't constantly fighting the complete absence of idioms and opaque "man-page" style of documentation that puts a slab of inscrutable text front and centre and neglects to provide simple examples for common problems (apparently we have a perfectly good Stack Overflow for that). The git boosters will respond to this by saying, as they always do, "yes, but the real power of git is in the model of the information under the hood. The CLI is just an interface, if you don't like it you should spend months studying the internals and build your own workflow on top of git". Again, back in the real world, who has time for that? Or the interest? Especially when, as I already mentioned, that tool does already exist and it's called Mercurial and you can get started with it right now. Both tools can do close to exactly the same things under the hood with differences that won't make a lick of difference to the vast majority of users. The user-facing differences are where it really matters: one tool has an excellent CLI which is clear, concise and discoverable; the other has github. Damn. Lousy network effects.

paulddraper 10y ago
Mercurial is nowhere near the idilic interface you imply. E.g. I challenge you to figure out how to use its interface to delete a branch. http://stackoverflow.com/questions/41968796/how-to-delete-a-remote-branch-in-mercurial http://stackoverflow.com/questions/41968796/how-to-delete-a-...
- ngoldbaum 10y ago
  You can close a branch, which makes it stop appearing in the UI unless you explicitly ask for closed branches. You can never fully delete a branch since the branch is part of the commit metadata (as it should be, IMO).