10 ms·
Thank god. I have been waiting ten years (https://www.google.com/url?q=https://stevebennett.me/2012/02/24/10-things-i-hate-about-git https://www.google.com/url
by stevage 4y ago
Thank god.
I have been waiting ten years (https://www.google.com/url?q=https://stevebennett.me/2012/02/24/10-things-i-hate-about-git https://www.google.com/url?q=https://stevebennett.me/2012/02...) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it.
This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is.
- bergheim 4y agoAdmittedly this might not help since it is not CLI, but spend some time this weekend with Emacs and magit. You don't have to use emacs for anything else, just the magit client. It will transform your git experience.
- stevage 4y agoI did something similar for years with Sublime and Gitsavvy. But I couldn't stop Sublime updating itself from time to time, and it kept breaking Gitsavvy, and it got really tedious to try to fix it.
- waynesonfire 4y ago
- somehnguy 4y agoLol. Orrr we could just do things sensibly in the first place.
- sixstringtheory 4y agoI always chuckle when things like “sensible”, “user-friendly” or “sane” get thrown around as if they are anything more than that person’s opinion. When are developers going to learn that they actually have to learn and familiarize themselves with preexisting systems, instead of endlessly reinventing them, and that there is no such thing as the perfect system?
- Shish2k 4y agoNothing is perfect, but some things are clearly better than others - hence why we’re nearly-all using git rather than "learning and familiarising ourselves" with CVS :)
- sixstringtheory 4y agoFair point, but it is not clear to me that Sapling is better than Git. I haven’t seen anything in its docs or in the comments here where I haven’t thought of a way to do it with Git. I wonder what the cost benefit analysis would be: how many developers hours have been expended building Sapling so far, vs a list of things it can do that Git cannot. And I guess it bears repeating that I’m interested in possibility and not aesthetics.
- Shish2k 4y agoGiven that they’re both open source and can be customised using turing-complete languages, the only limit to possibilities is how much effort you’re willing to put into customising them. Even CVS has the possibility of working as a distrubuted system if you wrap it up in enough layers of hacky shell scripts ;) Having done quite a bit with both mercurial (which the sapling CLI is based on) and git, I find that the mercurial approach has a lot more sane defaults, is generally less effort for the same results, and has a lot of quality-of-life improvements — like git has the possibility of doing interactive commits with `git add -i`, but sapling's interactive-commit interface actually makes it usable.
- waynesonfire 4y agoThe last thing I want to do is learn a new source control tool. For this to occur, it truly needs to be 10x better and not because someone isn't motivated enough to read the manual. With how well git has worked for me, I suspect I'll use it for the rest of my career.
- johannes1234321 4y ago> where I haven’t thought of a way to do it with Git. With git one can do "everything" true, doesn't mean that I want to teach everybody first what a DAG is and how one can manipulate that using git commands, but want to have something simpler. And yeah, git became a lot better over the years, but the plumbing still shines through in many places with inconsistencies.
- otikik 4y agoGitHub’s success was in part due to it making Git interface’s bareable. Imagine an UX so bad it generates a whole industry.
- peteradio 4y agoLol wut. Github's success is in being a remote code repository.
- nulltype 4y agoSo your claim is that GitHub would be equally successful if their website was just information about how to push to a git remote hosted by them?
- UncleEntity 4y agoSourceForge was pretty successful back in the day and they were pretty bland compared to GitHub.
- xyzzy_plugh 4y agoGitHub's UX is so incredibly terrible. Pull Requests are horrible -- even mailing lists are better and that's impressive. GitHub's UX is so bad it has indeed generated a whole industry of out-of-band review tools.
- djur 4y agoI don't think this is true. GitHub (the website) became very successful with virtually no feature overlap with the git CLI. I suppose you could say that GitHub pull requests and forks are a replacement for git's built-in email-based workflow, but that's not really what people complain about when they say git is hard to use (and it's not like the other DVCSes had obviously better solutions).
- deleted 4y ago[deleted]
- mikepurvis 4y agoMy brain immediately jumped to "but you can just git reflog and then copy the state you want to revert to and then git reset --hard <commit>", but not only is that not simple or obvious, it isn't even correct, since a commit or amend operation can be performed with only some of the changes staged, and a hard reset will wipe out anything unstaged. Ah sigh. So yes, in short I agree.
- latifk 4y agoWell in that situation you can stash unstaged, reset, then pop. But that just reinforces the OP’s point. Not the most ergonomic or discoverable path for something that should be simple to do.
- michaelmior 4y agogit reset HEAD@{1} should do the trick to "uncommit" and keep uncommitted changes in the absence of conflicts. (I may be missing some edge cases.) It does however unstage changes.
- galaxyLogic 4y agoRight and it is not obvious: git reset HEAD@{1} .
- acchow 4y agoRight, if you grok the git model then this makes sense. But if you just want to use a tool without learning how it manages state, git is a pain.
- srcreigh 4y agoIsn’t this just git reset —soft HEAD~1? Put my stuff from the last commit back into working directory? Very unintuitive (soft?) and I’ve just memorized this for the past 10 years.
- mikepurvis 4y agohttps://xkcd.com/1597/ https://xkcd.com/1597/
- sli 4y agoI've been using lazygit[0] for a while, which might not be what you're looking for but I enjoy it a lot. [0]: https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit
- stevage 4y agoI tried it, but I found it too radical a workflow change, and it wasn't intuitive for me. Loved the concept though.
- peterfication 4y agoUsing lazygit has improved my usage of Git so much! There is a nice video from the author that introduces a lot of its features. [0]: https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE
- mjsir911 4y agoMaybe I'm misunderstanding, but isn't this what `git revert` is for? Harder with an amend due to having to get the difference of commits within the reflog, sure.
- zeroonetwothree 4y agoThat’s actually not what git revert does, hence the poor usability of its API.
- mikepurvis 4y agogit revert doesn't undo a commit though— it creates a new commit that undoes it. That might be what you want under some circumstances, but most of the time that I want to revert it's a commit I just made and haven't pushed yet, so I just want to pretend it never existed.
- pooper 4y agoI don't know much about git but I just do git reset --soft HEAD~n where n is the number of commits I want to undo. Known issue: can't undo all the commits.
- bombolo 4y agogit reset --hard origin/master just deletes all your local work on the current branch.
- pooper 4y agoI never want that though. If I wanted to do something like that, I'd do the git reset soft, followed by git stash, followed by git switch. I think this at least allows me to look back at it locally? Git switch is also something I learned recently so sometimes I type checkout because of force of habit but I am trying to do better (even though I'm not sure what switch dies that checkout can't but don't want to get into arguments, just want to do things the prescribed way).
- terminal_d 4y agoEmacs + Magit, and never looked back.
- jakear 4y agoForget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen. (Disclaimer used to make VSCode)
- stevage 4y agoI used to use Gitsavvy in Sublime, and honestly it was much, much better than what VSCode offers so far.
- zabzonk 4y agobecause doing a commit with one keystroke is a good thing? i think it isn't - i like to consider things, rather than program like a hyperactive cockroach
- jakear 4y agoYou still gotta type the message.
- gen220 4y agoI think the original poster was referring to staging the commit as their "thinking" step, not composing the message. Personally, my workflow is to make many changes, then use `add -p` and `commit` to create a series of small commits. While staging, you might decide that you don't want to commit some bit of code and `restore -p` to toss it away. I think your workflow would work well if you see commits as "development checkpoints" rather than semantic patches. It's not an invalid workflow, just a different one. I'm sure you could configure VSC to be analogously ergonomic for any git workflow. But people who are comfortable with git and their shell of choice tend to develop comfortable workflows in the terminal as well.
- boardwaalk 4y ago
- deknos 4y agobefore building a new git, there just could be a new git command, i do not know like, undo for example. just they build one for switch. i hope they build a migrate one, where you can switch to new/other hashing standards.
- agumonkey 4y agoI don't blame git, I'm mostly surprised about the social inertia regarding improving it. But like programming languages, pressure accumulate until it's released, I'm sure sapling and similar will make people want to try new things and git will soon catch up.
- ShredKazoo 4y agoThe social inertia point is an interesting one. It seems like in some areas, like JavaScript frameworks, there is a ton of inertia for change; in other areas, like git, there is a ton of inertia for stasis. Why is that?
- stevage 4y agoI honestly don't know. For some reason, with JS frameworks, everyone seems to agree that improving ergonomics is a good thing. New methods are added, old ones are tweaked, constantly improving the developer experience. But with Git, every conversation about improving the CLI has 50% of the participants claiming that the other 50% are just too stupid to use it, and that the CLI is brilliant.
- recuter 4y agoWriting the umpteenth Javascript framework might be good for your career. It isn't hard, in fact, it is so easy a multitude of javascript-only developers attempt it on a regular basis. Occasionally one takes off. Really just a function of how many friends the author has, their stature in "the community" and/or their aptitude for creating cute marketable landing pages. There is a multitude of people capable of jumping in with hot takes explaining why the new framework is superior/inferior, tweets, blog posts, courses, books and conferences abound.. In contrast re-inventing git is hard. Few people can wax poetic about the differences between alternatives. Even fewer can come up with a new one. The audience is far smaller not to mention skeptical. Less profit in it. Rather the difference between a new age cult/mega-church and the Catholic church.
- rockwotj 4y agoCheck out jj, it's made by someone who works on Google's source control https://github.com/martinvonz/jj https://github.com/martinvonz/jj
- zemnmez 4y agoI have been looking for something like this for so long!
- selfhoster11 4y agoI got 90% of the way there with a lot of git aliases. The other 10% is constraining your workflow and reasoning about what state each of your commands leaves the git tree in.