91–100 of 490 posts
This seems like putting a training wheel on a training wheel. git is already the easiest to understand of any VCS that I've used, and it's somewhat hard to do something in git that can't be reversed. As the articles states, it's unlikely you'll ever lose your changes. Further, this doesn't seem to be that different of a concept from git reset, so why not learn reset instead of yet another command?
You mean Mercurial :)
Any other recommendations for CLI tools? I've gotten kind of familiar with the Git CLI. But it took a lot of wasted hours and headaches to do so, and even now it takes headaches and extra time / effort to do certain things like rewrite history and "good" commits. I still prefer CLI to GUI but I wish it was more intuitive.
While GitUp is a GUI app, and only available for macOS, I think it's worth noting that it has some great undo/redo capabilities built in. From what I understand, some of them were more feasible to develop because they implemented their own plumbing (GitUpKit), instead of relying on the official git plumbing. https://gitup.co/
Nevertheless my main daily driver, along w/ the command line. It's undo capabilities, best-in-class visualization of the timeline, and ability to easily visually edit, reworder, and squash commits remain amazing.
(I was disappointed to see newer git clients like Submlime Merge did not take inspiration from GitUp.)
Ultimately I think the future of VC will be something patch-based (pijul?) w/ a UI along the lines of GitUp.
Earlier 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…
Yes. Especially git init --submodule --recursive Or is it git submodule --init --recursive? God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands. And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?
The most painful mistakes beginers endure with git are irrevocable code removal from the current working directory because of bad usage of `git clean`, `git reset` (or `git merge` if you're brutish enough). This problem cannot be solved by using git, because git doesn't have any reference to such code.
Earlier quoted context omitted.
Bitbucket used to provide free (and pretty good) Mercurial hosting.
Bitbucket had a much crappier UI.
Earlier quoted context omitted.
Yes. Especially git init --submodule --recursive Or is it git submodule --init --recursive? God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands. And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?
> And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"? This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a p…
I would guess there's an easy way to make git do this automatically for you via config so you never forget, but I just never, ever `git pull`
Or:
> git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD'
From:
The most painful mistakes beginers endure with git are irrevocable code removal from the current working directory because of bad usage of `git clean`, `git reset` (or `git merge` if you're brutish enough). This problem cannot be solved by using git, because git doesn't have any reference to such code.
I think it would be possible to solve these with git, by doing something like automatically running a `git stash --include-untracked` before an operation that can clobber untracked files.
Earlier 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.
git commit -v