3 ms·

Git is pretty hard, but the examples in the post are _terrible_. The specific cases are actually pretty easy to explain: Undo the change: "The recommended appr

by theamk 3y ago

Git is pretty hard, but the examples in the post are _terrible_. The specific cases are actually pretty easy to explain: Undo the change: "The recommended approach is to make another change which undoes the original one and push it, using command AAA. If you want to un-push the change you made and pretend it never happened we can try it as well, but Git does not really expect published history to change, so but if someone else on your team has already pulled it, their machine will get pretty confused. It's like deleting email right from someone's inbox -- OK if they haven't seen it yet, but pretty confusing if they read it and already typing the reply" Delete the branch: "Does that branch exist on a server?". Depending on the answer, you either delete remote branch + local tracking one, or just a local one. The key idea is to have a workflow in mind, and steer users towards that workflow. Because sure, you can ask user if they want to "delete a local branch, and then just get it recreated when you pull again".. but that's terrible idea. Why would you want to do this _ever_ as part of any regular workflow? There are certainly circumstances when you have to do advanced/unusual stuff, but there is no need to push that to novice users, unless you hate git and your goal is convince them that the git is hard.

necovek 3y ago
> ...but Git does not really expect published history to change... That's a weird statement for a tool which has had `rebase` as the very basic command from the get go. Git does expect history to change, it's publicised as a solution to a bunch of issues: basically, there is no getting around understanding the Git internals, and even once you do, it's hard to remember how GIT cli commands tie into those internals for things you seldom use because of their arcane naming.
necovek 3y ago
And let me cover this separately: > The key idea is to have a workflow in mind, and steer users towards that workflow. Because sure, you can ask user if they want to "delete a local branch, and then just get it recreated when you pull again".. but that's terrible idea. Why would you want to do this _ever_ as part of any regular workflow? I've recently tried to guide someone to fix their bad branching strategy, and after a few of their bad attempts, just suggesting they remove their local branch and then refetch it from the published repo instead (just imagine how easy it is to figure out what commands-people-have-blindly-typed-in-from-the-internet have done, and then reverting that with git). Going back to a known good state is the most common of all debugging tools (also part of more advanced tricks like bug bisection search — interestingly also present as `git bisect`), and with it being too easy to mess up your local repo, going back to a remote that's "clean" is sometimes the fastest approach.

by theamk 3y ago

necovek 3y ago

> ...but Git does not really expect published history to change... That's a weird statement for a tool which has had `rebase` as the very basic command from the get go. Git does expect history to change, it's publicised as a solution to a bunch of issues: basically, there is no getting around understanding the Git internals, and even once you do, it's hard to remember how GIT cli commands tie into those internals for things you seldom use because of their arcane naming.

necovek 3y ago

And let me cover this separately: > The key idea is to have a workflow in mind, and steer users towards that workflow. Because sure, you can ask user if they want to "delete a local branch, and then just get it recreated when you pull again".. but that's terrible idea. Why would you want to do this _ever_ as part of any regular workflow? I've recently tried to guide someone to fix their bad branching strategy, and after a few of their bad attempts, just suggesting they remove their local branch and then refetch it from the published repo instead (just imagine how easy it is to figure out what commands-people-have-blindly-typed-in-from-the-internet have done, and then reverting that with git). Going back to a known good state is the most common of all debugging tools (also part of more advanced tricks like bug bisection search — interestingly also present as `git bisect`), and with it being too easy to mess up your local repo, going back to a remote that's "clean" is sometimes the fastest approach.