I'll often launch lazygit just to use its undo feature since that's easier than navigating the reflog. Happy to see a standalone utility.
Git undo: We can do better
191–200 of 490 posts
Re: Git undo: We can do better
#192Earlier quoted context omitted.
The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this hap…
> It's a human problem If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows? > 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before. SVN isn't distributed; it mos…
> If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows?
Because maybe mercurial's real problems wouldn't show up until people started using it at scale.
This is a classic problem that happens time and again.
Windows vs. Mac back in 2005:
"Windows having malware is a human problem"
"If it were a human problem, how could alternatives like Mac get consistent amounts of praise for their lack of malware?"
Turns out it's just because Mac didn't have a big enough market share. As soon as it did, Apple could no longer claim that Macs can't get malware because they can and do.
Similarly, if you scaled up the number of Mercurial users by several orders of magnitude so that it was now "mainstream", I'm sure some of its lesser known pain points and/or counter intuitive behaviors would start floating up to the top 10 HN stories. But since hardly anyone uses Mercurial vs. Git, that doesn't happen. Just because a minority of users praise something (, , , etc.) doesn't mean if you scaled up the userbase one or more magnitudes it would continue getting that level of praise from all users.
Re: Git undo: We can do better
#193i wish the branchless tools would be incorporated in standard git. :|
Re: Git undo: We can do better
#194I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI? Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certa…
The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this hap…
GitHub is what made git so popular, git wasn’t inevitable, and GitHub didn’t become huge because of git, GitHub’s big innovation was attaching a social network to a software/code repo. It’s what made it way more popular than basically all the competition, which were just software/code repos but didn’t have a great network/social story. (Also at the time GitHub was coming out, the biggest player in the space decided to monetize in an annoying way.)
Re: Git undo: We can do better
#195Earlier quoted context omitted.
I agree and limit Git Gui usage to read-only use, any mods to git I use command line.
Git Gui is a decent tool to compose commits, but for everything else I can't see myself using anything but the command line.
gitk (and similar) are great for browsing the history and figuring out what is going on. I couldn't live without it.
Re: Git undo: We can do better
#196From the article: > How is it so easy to “lose” your data in a system that’s supposed to never lose your data? I think the author is mistaken; git isn't "a system that’s supposed to never lose your data". One of its features is the ability to "lose" data in a controlled way; i.e., to rewrite history. If you want a version control that is supposed to never lose data, use Fossil.
This is a figurative use of the word "lose", hence the quotes. The beginner comes in with the impression that it's impossible to lose your data with Git, and then manages to "lose" it anyways. Whether it's really lost, or it's just that the user doesn't know how to get it back, isn't relevant from the novice's point of view.
Re: Git undo: We can do better
#197Earlier quoted context omitted.
I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.
even if you use the git CLI you can still set up a mergetool so that when you are resolving merge conflicts you can use something like BeyondCompare or P4Merge to handle the merge conflicts.
Meld
Re: Git undo: We can do better
#198Earlier quoted context omitted.
> Git branch list" is just "git branch". "git branch create" is "git branch [name]". So creating a branch is the SAME COMMAND as the one you use to produce a list of current branches, just with an argument. Madness. And this is the rule, not the exception. As a counter-opinion, I actually like it this way. Especially since it's the rule and not the exception. When one makes the small effort to learn the commands, the…
There's nothing wrong with having a UI for power users in addition to a more intuitive one. But having a power-user UI as the only option (or even as the default) is not so good.
In particularly well designed UIs, the interface for power users and the intuitive one are one and the same!
Re: Git undo: We can do better
#199Earlier quoted context omitted.
I know (or, at least, have known ) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the com…
definitely agree, and I'm in the same boat. I don't even think the data model of git is that hard to grok at all, it's mostly that commands are very unclear on what they operate on and in particular people get really tripped up about how many levels of state there are (stage, working tree, local branches, remote refs) that they have to interact with. Like, I've had to explain a lot of times why you `git pull origin m…
> levels of state
This is the crux for me. Command naming is completely unrelated to and unindicative of state.
It feels like surely there's an opportunity for the basic CRUD operations to be collapsed down into a standard "{action} {source} {target}" style.
There will be nuances, specifically around branching, but the basics should be basic. As opposed to a Swiss Army knife, where you have to pull out the scissors and squeeze them three times before you can unfold and use the blade.
Re: Git undo: We can do better
#200Earlier quoted context omitted.
Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.
I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.
The Jetbrains IDE git GUI is by far the best git GUI I've used, I feel lost trying to use git without it.
There's a user request that's been sitting around for a while to pull it out into a dedicated application, which I could personally get behind since we have one project at work that's pretty difficult to run outside of Eclipse