I'm still scared of using got undo
Git undo: We can do better
311–320 of 490 posts
Re: Git undo: We can do better
#312Earlier 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.
Yes Jetbrains have totally nailed this. I have tended to prefer the command line for git but the exceptionally designed GUI support in Rider is fast changing that - especially for rebasing.
Re: Git undo: We can do better
#313Earlier 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.
I really understand your sentiment, and I've been there for long enough myself - but once you have a somewhat decent understanding about gits internal data model, the commands that allow you to clean up pretty much any mess (reset & reflog probably being the most prominent ones) start to somewhat make sense. If you had previous exposure to anything computer-science, it very likely won't take more than a few hours until the puzzle pieces start to come together.
And it's time well-spent in my opinion; git will probably be one of the longer-lasting constants in software development.
Re: Git undo: We can do better
#314Earlier quoted context omitted.
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.
It's a handful of commands, very well documented with tons of SO questions that is one search away if you can figure it out yourself. It's something I use all day, every day. I'd say it's worthwhile to learn if your daily job involves working under source control
Yes I agree. If you’re going to use git (whether by choice or force) it is 100% worth learning the small set of commands required to undo a screwup without needing to reclone.
Recloning to me is a bit like tearing your house down and rebuilding it just because you painted your living room the wrong colour (in most cases!)
Re: Git undo: We can do better
#315Earlier quoted context omitted.
Unfortunately, it is still very easy to lose data, e.g. by trying to undo a temporary commit with `git reset --hard HEAD^` (note the --hard option) before committing your changes.
That's why it's a flag. You could do git reset HEAD^ && git stash instead Also, git reset ---hard HEAD^ deletes nothing. The commit HEAD was pointing is not deleted. You have to work really hard to delete that commit accidentally
It does delete whatever uncommitted changes you had.
Re: Git undo: We can do better
#316I used GIT recently for tracking an SSIS package and despite many commits I still have no idea whether I should use a rebase or a reset or a hard reset. Reading the manual does not help. I just simply want to undo a mistake. Glad I am not the only one who feels dumb about this.
Re: Git undo: We can do better
#317Earlier quoted context omitted.
What a pointless project! U hope you were paid well, at least.
I was. But it wasn't quite as pointless as it sounds - the tool was a sort of tripwire-like system, with changes shipped to an append-only log, that itself was checkpointed in an early blockchain-ish structure. The threat model was "nation state actor" so the client wouldn't accept SHA1. It was actually a pretty cool system. I don't think it was ever sold though.
Man, I thought zero days and secret backdoors were bad enough. Now we have to worry about manufactured hash collisions in all our repos' files dating back forever?
Re: Git undo: We can do better
#318Earlier quoted context omitted.
> 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 a…
Are there any git frontends that do this today?
The one built into IntelliJ IDEs is pretty good. SourceTree is decent too. They are both cover the vast majority of day to day operations. I only ever very rarely have to resort to the command line for ritualistic summoning of the git demons.
Re: Git undo: We can do better
#319Earlier quoted context omitted.
Not a single person I’ve met using git in the last decade has thrived using a UI for it.
That's a failing of Git. TortoiseSVN brought source control to millions of people. A good tool should be fully embeddable in a UI, 15 years after its launch.
Or a success of git? No good GUI exists because they realise they'd just be recreating things that exist, but with a GUI frame?
If you wrote git 2.whatever from scratch would you structure rhe commands a bit differently? Yeah, sure, probably; but I always think these threads are way overblown. The common stuff that you use frequently.. well you use it frequently, so either you remember it as a result or you use the alias feature so that you can. For the less common stuff.. if you have to look it up in the excellent documentation, is that a failing?
Re: Git undo: We can do better
#320Earlier quoted context omitted.
like why it's different? `git fetch` (and by extension `git pull` when given a remote) and `git push` copy data to and from a remote. When you specify `git pull origin master` you're saying "pull down a copy of the remote ref master from origin", which it then saves locally as the ref `origin/master`. Everything under `origin/ ` (or really `refs/heads/origin/ `) is just a cached pointer to the last known state of tha…
I tend to default to `git pull --rebase`.
I have this configured as default everywhere and strongly believe that merge-pulls are always wrong. The first place I used git we were learning together (i.e. nobody knew what a sensible workflow was) and people would push their local merge commits back to master. It was horrible.