So many people that have issues with git, yet it still is quite popular... everywhere. I wonder if they would do any better with another VCS. I do look forward to pijul.
Git undo: We can do better
451–460 of 490 posts
Re: Git undo: We can do better
#452Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…
> What does "git reflog" or "git reset --hard ...." do? What are the implications?
If you have ever done a "git reset" (which implies --soft), then you should know what "hard" in this case means. I am not sure, I knew that it would most likely get rid of my uncommitted changes. I "git stash", then "git stash pop".
Do not run anything without knowing what it does, you should consult the manual page: "man git reset". Search for "--hard", and you get:
--hard
Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.
Slightly off-topic, but I love working with meld! If I do a "git rebase --onto [...]" I do not get "meld" open automatically, you gotta type "git mergetool" to resolve conflicts.
Re: Git undo: We can do better
#453Earlier 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.
Sorry, I'm trying to get work done, not memorize an obscure set of incantations like some kind of D&D wizard. If the repo gets messed up, I delete it and reclone.
Isn't understanding how to use your tools part of being effective at getting work done?
Sure, recloning and cp your changes to a fresh local repo will _work_, but what happens on the day you don't have access to the remote? What happens when you have to work on a repo that takes minutes to clone from the remote? All of those lost minutes because you don't understand how to use your tools means you aren't getting work done.
> memorize an obscure set of incantations like some kind of D&D wizard
If you're using Git then you're probably someone that works on software, isn't our whole job memorizing and reproducing permutations of obscure incantations to produce business value? Knowing how to use your tools provides business value, that's not some hot take but literally how you provide value to whoever pays you.
Re: Git undo: We can do better
#454Earlier 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.
What's wrong with 'git diff'? Then there's 'git add -i' to easily choose which files to add
> What's wrong with 'git diff'?
Not GP, but I find it extremely hard to parse visually even after having had to do it a lot. Something like git-delta makes it bearable, but a decent syntax-highlighted, color-coded, side-by-side diff view with proper keyboard navigation (next diff, next file) is a huge quality of life boost for me.
> Then there's 'git add -i' to easily choose which files to add
Didn't know that, just tried it, and, wow, that's easily the most unintuitive and inscrutable TUI since vi. I haven't been able to make it show a simple diff; someone else also tried, failed as well.
Re: Git undo: We can do better
#455Earlier quoted context omitted.
Indeed, it makes using git so much less painfull. There are days where I daydream of Clearcase when dealing with git.
Early in my career- when I got evil twin error- I was conditioned not to daydream of clearcase ever. :)
On the positive side, messing up the view configurations doesn't wipe our files.
Re: Git undo: We can do better
#456Earlier 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'm a huge fan of git fork [1] on windows (or mac). Looks good, never failed me and does everything I need (branching, rebasing, merging, squashing, cherry picking, blaming and it can even show lost commits with reflog). And it performs really well (in contrary to sourcetree). [1] https://git-fork.com/
This looks neat! And a one-time purchase, too.
Re: Git undo: We can do better
#457Earlier quoted context omitted.
> if you have to look it up in the excellent documentation, is that a failing Yes, if we ever want version control to become mainstream. Version control is a very practical, day to day concept. It's just almost unusable for regular folks. And regular folks for sure won't use CLIs (unless you point a gun to their heads).
Version control is mainstream; git isn't, and isn't trying to be? Git is version control for plaintext files, (yes yes I know LFS exists) primarily software, and used by people who like using CLIs and have all kinds of other CLI tools for it to interface with. Who's trying to make 'regular folks' use git, with or without a gun?
> Who's trying to make 'regular folks' use git, with or without a gun?
I would have loved to have that option quite a few times. Lots of projects that involve software, but also get contributions from non-developers, or need almost no user-facing config, but not exactly zero. If git wasn't so hostile, quite a few tiny config web UIs I've built over the years could have been SublimeText or the like and a very userfriendly git client. It's kind of frustrating to have a repository with a directory full of .sql files, a CI pipeline that versions and verifies those and deploys the updated app, but the domain expert who is perfectly capable of writing the SQL still needs me to put the file in the right place and commit+push it, because they (understandably) just won't use git on Windows.
Re: Git undo: We can do better
#458Re: Git undo: We can do better
#459Earlier quoted context omitted.
You should change the way you work with git. Commits are cheap. Really, really cheap. Commit all the time. Make "WIP" commits to remind you to squash them later. Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing.
> Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing. Which means git is failing to do its whole job: keep the history of my work safe. I'd argue that git actually makes data on your filesystem less safe, because it pointlessly write-protects files in the .git directory, which encourages a bad habit of using rm -rf.
I've not once lost work in 15 years of using git. A bad workman always blames his tools.
Re: Git undo: We can do better
#460Earlier quoted context omitted.
Version control is mainstream; git isn't, and isn't trying to be? Git is version control for plaintext files, (yes yes I know LFS exists) primarily software, and used by people who like using CLIs and have all kinds of other CLI tools for it to interface with. Who's trying to make 'regular folks' use git, with or without a gun?
> Who's trying to make 'regular folks' use git, with or without a gun? I would have loved to have that option quite a few times. Lots of projects that involve software, but also get contributions from non-developers, or need almost no user-facing config, but not exactly zero. If git wasn't so hostile, quite a few tiny config web UIs I've built over the years could have been SublimeText or the like and a very userfrie…
> they (understandably) just won't use git on Windows.
I'm not sure how understandable that is, especially in the age of WSL - but I just won't use Windows so what do I know :)