by thijser on 11/16/22, 4:52 PM with 104 comments
by hbn on 11/16/22, 5:31 PM
Cmd+K to commit changes. There's a list of all files changed, organized by file hierarchy. You can click any of them to get an embedded editor and you can edit right from there.
There's a VCS pane you can pop up to view commits from any of the branches you have pulled without switching, you can select commits and right click > cherry pick to pull them into your current branch.
And the diff resolver is perfect. 3 vertical panes with the incoming and local changes on the left and right, and center is the merged product. You can press arrows on each side to bring those changes into the center, it shows right where they'll go with colored highlighting before you even make any changes. And the center is once again an editor so you can just manually type in it to resolve conflicts too.
Git's mental framework is so visual for me, it just seems like a better experience in a GUI. Especially one as well-thought-out and intuitive as what JetBrains came up with.
by noufalibrahim on 11/16/22, 5:44 PM
I've been using version control systems since CVS and I've found git the easiest and most sensible thing to use. Admittedly, some of the commands reflect internal data structures and concepts rather than what a user would want to do but that's just a learning curve issue. To address specific points.
1. Of the 157 commands, there are maybe 10 or so that one would need on most days and maybe 5 or 6 others when things go awry. Perhaps another half dozen for specific workflows but that's it. How many times do people use git daemon or git instaweb or git fsck? Why are these listed there? I do git trainings and teach a handful of commands in half a day which are sufficient to get people started.
2. The index has been extremely useful to me when I code for a while and then later need to commit only some files or parts of files into separate commits. This is a "good thing". The workflow which the author is suggesting would be like a "git commit -am ... && git push" which is not ideal
3. There are two destructive commands. git checkout and git reset when you've not committed. These two can discard uncommitted code in the working tree and you'll lose them. Once you've committed, it's possible to undo almost anything using the reflogs. They're very useful and worth learning how to navigate and use. Even rebase --hard can be undone by switching to a previous reference.
I think this is a deliberate decision. git is a power tool that sacrifices protecting the user from mistakes to give the user fine grained power over a project. A tool that hides these things from a user and tries to wrap the whole thing in a veneer of user friendliness might be good if engineered properly but my feeling that is that it wouldn't be worth the sacrifice.
Highflux itself advertises several things like " Automatic commit on every editor save." which I'm not sure are good ideas. I hit save repeatedly while working. Each one of those saves is not meant to be a commit.
by philipwhiuk on 11/16/22, 5:28 PM
Adding HighFlow on top will just add more commands because inevitably there'll be a point where some HighFlow abstraction fails and you have to go to Git anyway to fix it.
Also I can see that HighFlux runs as a daemon. That seems sub-optimal - sucking up my CPU all the time on the off chance I want to code something is not great.
It doesn't seem like HighFlow supports actual remote repositories except GitHub. Which is the entire point of a distributed version control system - to be distributed.
I think HighFlux is designed to solve a very limited subset of Git's usage and so they've stripped out a lot of useful commands they don't use and so they can ship a product.
But in the real world people will need this and their simple vision will crumble back to the complexity of Git (or close).
by rchaves on 11/16/22, 5:22 PM
by athorax on 11/16/22, 5:31 PM
by PaulHoule on 11/16/22, 5:03 PM
Visual Source Safe would outright die when your repository overflowed a 32 bit file.
Changing a wrong commit message was almost impossible with CVS.
I push into the wrong branch and make other mistakes like that sometimes with git and I have no fear about it at all and little stress because I can always look in the cookbook and find the recipe to fix it.
Git also is the basis for numerous tools such as GitHub that are accessible to non-technical users. Git is the only version control system I've seen that can be used like that.
by lordnacho on 11/16/22, 5:26 PM
So then you don't learn how it really works, and you get weird problems because you never formed the right model in your mind.
It's also the case that there's a few commands you use a lot, but a lot of commands that you reach for only in specific cases. This creates the impression that it's too complicated, because as soon as you go off road you get stuck.
by P_I_Staker on 11/16/22, 5:26 PM
Occasionally, I'll see articles talk about "fixing" git by eg. removing the staging area, or something like that... but the staging area is great! It's literally a feature I was dreaming about when I used Mercurial.
I definitely think there's room for a more intuitive solution. I would rate the git learning curve as "medium-easy"
by Justsignedup on 11/16/22, 5:36 PM
- I use sourcetree for committing, it is a great UI tool for seeing your commit graph and just entering commit messages / partial commits / selecting which files to commit
- I use command line for all pulling/merging/fetching/branching etc. Git command line is just so simple IMO (once you get a short intro to it).
- Repairing issues in git is honestly not difficult.
- The hardest part of git is branching, merge conflicts, and squashing. When you combine all 3 is where it gets challenging if you don't know how to avoid any gochas. But it does make for nice revision history.
So I guess if you are doing some crazy complicated git stuff, I can't speak to that. But in 8 years I can definitively say I have only enjoyed git, and have often been the person to debug issues with people using git, and it is always a fairly simple thing to un-screw things up.
Criticism: push -f is definitely a dangerous operation. I can see why the mercurial team said no history rewriting period.
by donatj on 11/16/22, 5:37 PM
I really don't know why anyone would use these new "easy" commands. They don't feel that much better and their existence irks me because now there's even more ways to do the same thing.
by alon7 on 11/16/22, 5:16 PM
by brap on 11/16/22, 5:47 PM
Dev experience at Google kinda sucks for the most part, but one thing that works amazingly well is VCS. You never even have to think about it, it literally just works, and it works at very large scale (monorepo for all of Google).
It’s just: 1. Create a workspace 2. Submit the changes in your workspace
And that’s it. I hate going back to the mess that is Git.
by pmoriarty on 11/16/22, 5:40 PM
Learning what rebase actually did and the difference between reset soft/hard/mixed along with using the reflog to get back to previous states made git a lot more understandable to me.
That said, if you want to see how insanely complex git is, try reading its many man pages.
by Ericson2314 on 11/16/22, 5:49 PM
If every time the journal / write-ahead log was flushed, the files were rehashed, we wouldn't need index vs non-index so much.
We would use normal commands to sync two work trees one being what we have, and one being what we want to commit.
Instead of .gitignore we simply should have temp files elsewhere.
Basically the file system is a bad abstraction and all VCS is ad-hoc work around it.
by billpg on 11/16/22, 6:21 PM
Why? I recently configured my github to use a hidden email address. To this end, it required me to use a github.com email address it generated for my commits. I set it up and started pushing commits, everyone was happy.
Then I went to a different folder that had a separate clone of the same repo, and I forgot I had configured github this way. I made some changes and did the usual commit-and-push but github rejected it. I had used the wrong email. Oops.
But now I had a problem. My local repo had the commit with the wrong email address in place and I didn't know to change it. I couldn't make a new commit with the new email as the old one was still there. I looked up how to revert already committed commits and long story short I did it wrong and deleted all my recent changes.
by jon889 on 11/16/22, 5:59 PM
by 1ark on 11/17/22, 3:52 AM
by raspyberr on 11/16/22, 6:58 PM
by anotherevan on 11/16/22, 8:23 PM
— Isaac Wolkerstorfer
by dbrueck on 11/16/22, 5:57 PM
I use git constantly and hardly ever have problems with it, but only because I use a tiny fraction of it and I religiously follow an exact process every time. I've had people tell me all sorts of reasons why my approach is not good, and they're probably right, but it's really nice to not have to give my VCS very much thought 99% of the time.
by bumf on 11/16/22, 5:34 PM
Most of these are 'plumbing' commands, not 'porcelain' commands. Perhaps the author should have read the book on the Git website¹, as it explains this.
> Git tracks 4 versions of files, instead of just "my" version and "the team's" version.
This is because it's a distributed version control system, not just a tool to upload files to GitHub.
It seems like the author hasn't even taken the time to understand the basics of Git, and its design goals, before writing this ignorant screed.
＿
by pugets on 11/16/22, 5:49 PM
by chaostheory on 11/16/22, 5:31 PM
Isn’t this one of the main purposes of branching?
Also git is easy to use. You can ignore the non-basic commands as a small team or solo dev, and there are plenty of GUIs to help with UX
by lbriner on 11/16/22, 5:32 PM
Once you realise why git is like that, I haven't found it that bad.
It's no different than someone who has only ever ridden a bicycle asking why a motorbike is so hard to use. Because it does more stuff.
by alcover on 11/16/22, 6:04 PM
There's a dread, a fatigue... I got burned merging (or was it rebasing?) and now I often just copy my folder to make a temp branch.
By the way, how do you extract a file from an old commit without checking out (and crushing your current files..) ? No hassle with the old folder-copy-tech !
by pixelfog on 11/16/22, 5:25 PM
by yoah on 11/16/22, 5:29 PM
by fragmede on 11/16/22, 5:34 PM
by metadaemon on 11/16/22, 5:50 PM
checkout, pull, commit, push and reset if you make a mistake. I'm not including one time commands like clone and init.
by newbieuser on 11/16/22, 5:39 PM
by kristopolous on 11/16/22, 5:40 PM
Here's something I posted 7 years ago over on a reddit comment thread about it
---8<---
I've been running a git hater twitter account for years and have had git use me, or me use it, for 8. (https://mobile.twitter.com/githater)
I "grok" the concepts. I do not however, get the broken command line interface. How is an error message like this at all helpful:
git push -u origin master
error: src refspec master does not match any.
That's not even a proper english sentence.
Here's an example of the three counterintuitive undiscoverable ways to do one common thing that everyone wants; be able to push and pull from a branch without specifying it each time.
git branch m
THEN
git checkout m
THEN
git push -u origin m
OR
git branch --set-upstream=m origin/m
Or if you want
git checkout --track -b m origin/m
How do you push to a branch?
git push origin m
how do you delete a REMOTE branch?! Same thing, but prefix it with a colon
git push origin :m
How do you delete a LOCAL branch? Use a different command, with a different option
git branch -d m
Show useful information about tags? What about sorting them, by date. Sounds typical, common if you dare say... If you think it's in git-tag, your princess is in another castle. You need git-for-each-ref. Here's the simple to remember magic:
git for-each-ref --format="%(taggerdate): %(refname)" --sort=-taggerdate --count=10 refs/tags
So easy to use, no wonder it's number 1.
how do you rebase? It's a simple task!
git rebate --onto something commit id that is one before where you actually start from [ space, not 2 dots like everything else ] commit id where you want to end at ...
Great, now you are in a "detached head" state. So the rebase onto didn't actually rebase on to it ... yeah ... about that...
---8<--- (from https://www.reddit.com/r/programming/comments/3qt28h/xkcd_15...)
So in conclusion, the documentation was full of arcane discussions in domain specific jargon. The interface was wildly inconsistent and asymmetrical and the errors were cryptic and unhelpful.
Here's a fun one. If you just git init and then have multiple users start pushing, you know, like the documentation encourages you to do, the objects database files get the ownership of the person pushing upstream and then can lead to wildly cryptic intermittent permission denied errors because the database is actually just a bunch of unix files. Yes there's many ways to fix this, but that's not the point. Why is a deep dive discovery process needed to make basic things work in obvious ways? It's a Heathkit when all you need is a calculator.
When you expressed these complaints people would respond with theoretical introductions to branching and ASCII art diagrams.
It was all no good. I even tried some futile attempts over 10 years ago to contribute to clean things up.
The problem was I was unable to convince people deeply intimate with the codebase that there were hostile user patterns that could be alleviated with a bit of expository writing. All the cryptic jargon was utterly clear, exact and concise to someone who's spent 1,000 hours on the source. "Many people find these interface patterns confusing" was met with "we have academic level documentation with diagrams". Alright. Useless.
It's gotten a lot better though.
by weba11y on 11/16/22, 6:29 PM
by mgkimsal on 11/16/22, 5:35 PM
tldr: the 'undo' in Tower has been really handy for me over the past few years. Really handy.
by _steady on 11/16/22, 5:46 PM
by yakirp on 11/16/22, 6:30 PM
by rod_ochoa on 11/16/22, 5:29 PM