Oh Shit, Git • Hacker News Board

Re: Oh Shit, Git

#191

Post by canaus » Sat, Jun 25, 2022, 6:34 PM UTC

metaltyphoon wrote: post #164

canaus wrote: post #151

Earlier quoted context omitted.

I'd really like to know what mess people make when they don't rebase. I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch. Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

Interesting take. If anyone care to actually learn how git works when rebasing, then it becomes much simpler. I always rebase and in 10 years of professional use, never once had a problem with it. That doesn’t mean other people don’t.

> If anyone care to actually learn how git works when rebasing, then it becomes much simpler.

That's a very arbitrarily vague answer. It's very easy to hand-wave the misuse of a tool just by saying "you don't know it well enough". It's much harder to admit that maybe the tool is just difficult to use in the first place.

Re: Oh Shit, Git

#192

Post by dahart » Sat, Jun 25, 2022, 6:43 PM UTC

Nullabillity wrote: post #181

canaus wrote: post #151

Earlier quoted context omitted.

I'd really like to know what mess people make when they don't rebase. I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch. Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

> I'd really like to know what mess people make when they don't rebase. I think this part is really telling: > And worth mentioning, the question’s partially moot for people using Github or other hosting services where some GUI tools are built-in. Using the CLI for all interactions with Github, and using the site for the visualizing diffs & branches is totally reasonable. GitHub's branch view is uniquely awful, and d…

No disagreement from me, so I don’t know what that snippet is telling you. I wasn’t saying GitHub or any other service is the greatest, I was only saying that using the GitHub site mixes GUI and CLI workflows, since using GitHub is so common.

In some sense that goes to the point that CLI can be better than some GUI tools. The ascii railroad diagram you get with git log might be preferable to what GitHub can do.

Re: Oh Shit, Git

#193

Post by dahart » Sat, Jun 25, 2022, 6:48 PM UTC

canaus wrote: post #151

dahart wrote: post #131

Earlier quoted context omitted.

> I find people are religious about being git cli purists […] we have state of the art GUI tools I would humbly suggest you avoid framing it that way, even if you believe it’s true. From someone who is only sometimes a cli advocate, my immediate assumption is that your opinion here may be formed out of naïveté and a bit of fear of the cli. Please note I’m actually quite a fan of using various GUI tools for basic git…

I'd really like to know what mess people make when they don't rebase. I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch. Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

FWIW, I was mainly referring to making local branches presentable and/or just organizing things, not to rebase as a merge strategy. Don’t assume that rebase always means moving the local branch to the head of main, and don’t assume that rebase and merge are interchangeable. There are a lot of ways to rebase.

Re: Oh Shit, Git

#194

Post by thefz » Sat, Jun 25, 2022, 7:07 PM UTC

Git is just a tool, or better, a toolset for software development. Saying that it is too hard to me is a huge red flag. It means you do not want to spend the time, or the effort, to learn it.

It's like a mechanic saying that a wrench is too complex.

Re: Oh Shit, Git

#195

Post by nocman » Sat, Jun 25, 2022, 7:07 PM UTC

at_a_remove wrote: post #188

nocman wrote: post #168

Earlier quoted context omitted.

> How is "reflog" the correct and intuitive choice for "undo"? Was there something I wasn't understanding? No, I'm just supposed to accept that. Actually your initial intuition was correct. There are things you obviously don't understand about git. "reflog" is short for reference log. As "git help reflog" will tell you: Reference logs, or "reflogs", record when the tips of branches and other references were updated i…

You have made my point for me. "This command manages the information recorded in the reflogs." WHAT? Of course everything has an obvious name if you have to learn everything about it. The point I am making is that the name ought to be obvious before you have to learn everything about it. "Undo" is a reasonable choice if you barely understand what git is for and "reflog" is not. Once you master a system and agree to a…

You have made my point for me.

There is a minimum level of knowledge you need to know to use git. It is not as straightforward as, say a simple text editor. The problem git is solving is more complex than that, and therefore understanding how to use it requires investing a significant amount of time in learning how it works.

If I was going to go back to my previous commit, I would use "git reset" to go back to the commit prior to the one I just committed. The only reason to use "git reflog" as part of that process is to see which commit was prior to the one you are working with now (in order to pass it to "git reset" to undo the changes).

> "Undo" is a reasonable choice if you barely understand what git is for and "reflog" is not.

But "git reflog" is not an undo mechanism. It can be used to determine a commit SHA to reset to (in order to 'undo' the last commit with "git reset"), but it is used for a bunch of other things also. It is appropriately named for what it does.

If you "barely understand what git is for" then the solution is to learn the minimum you need about git in order to use it effectively. I am not talking about mastering git, that's an entirely different topic. I'm talking about basic-level knowledge. Again, the required initial time investment for git is significant, but in my opinion it is worth it.

If you don't feel the investment is worth it, then you should use something else.

Re: Oh Shit, Git

#196

Post by amelius » Sat, Jun 25, 2022, 7:09 PM UTC

dahart wrote: post #137

amelius wrote: post #104

Earlier quoted context omitted.

Good modern software always offers an undo option. Where is "git undo"?

It’s the first thing in the article. Git reflog. (BTW you won’t get any disagreement from me about the lack of intuitiveness of the command name. But, in a way, git’s whole reason for existing is to undo, and almost everything you do in git can be undone by design.)

Of course, but Git keeps track of everything you undo, which at the meta level is something you can't easily undo ...

Re: Oh Shit, Git

#197

Post by seadan83 » Sat, Jun 25, 2022, 7:09 PM UTC

olvy0 wrote: post #175

gpspake wrote: post #108

I find people are religious about being git cli purists and only interacting with it in this black box (the terminal). On top of that a lot of people stop learning git after add commit push pull branch and merge so concepts like rebasing and cherry picking are scary. In this day and age we have state of the art GUI tools that change the game and allow git users to see and interact with the state of a git repository i…

For me git is really difficult, and the CLI makes it even more so. That's just my personal experience. That's just me. I have a really terrible short term memory, so when using a CLI I tend to scroll up and down a lot since I forget after a few seconds what was the error I was just shown and what state I'm in. This creates a lot of friction. When using a GUI I see the new state immediately, in a single glance. My the…

I don't think any of the three problem areas are intrinsic to gui or cli

The rename aspect is a problem in both cases and is related to how git works internally.

Dirty commits van be really useful for the above, do a commit to rename, then another to modify. That keeps the rename operation clean and modifications in their own diff.

For workflow, that is a team process and documentation problem. Every team should document the typical CLI commands for their workflow. Having no documentation around this is negligent, simply referencing some webpage is lazy, it should be spelled out for you

Re: Oh Shit, Git

#198

Post by nocman » Sat, Jun 25, 2022, 7:13 PM UTC

nocman wrote: post #195

at_a_remove wrote: post #188

Earlier quoted context omitted.

You have made my point for me. "This command manages the information recorded in the reflogs." WHAT? Of course everything has an obvious name if you have to learn everything about it. The point I am making is that the name ought to be obvious before you have to learn everything about it. "Undo" is a reasonable choice if you barely understand what git is for and "reflog" is not. Once you master a system and agree to a…

You have made my point for me. There is a minimum level of knowledge you need to know to use git. It is not as straightforward as, say a simple text editor. The problem git is solving is more complex than that, and therefore understanding how to use it requires investing a significant amount of time in learning how it works. If I was going to go back to my previous commit, I would use "git reset" to go back to the co…

Also, if you don't want to use "git reflog" at all for "undoing", you could undo your previous commit with:

  git reset HEAD^

Or if you also want to discard the changes you made to files in the repo at the same time:

  git reset HEAD^ --hard

But use the --hard option wisely. Be sure you really don't want to keep any of the changes you made (or that you have already saved them elsewhere before running it).

Re: Oh Shit, Git

#199

Post by rfiat » Sat, Jun 25, 2022, 7:21 PM UTC

dahart wrote: post #137

amelius wrote: post #104

Earlier quoted context omitted.

Good modern software always offers an undo option. Where is "git undo"?

It’s the first thing in the article. Git reflog. (BTW you won’t get any disagreement from me about the lack of intuitiveness of the command name. But, in a way, git’s whole reason for existing is to undo, and almost everything you do in git can be undone by design.)

The reflog is very helpful but I don't think it counts as an "undo". Some operations (like git add or git push) won't show up in the reflog.

Even the operations which do show will often require more thought to undo than a hypothetical "git undo" would. I know how to use the reflog but I often go out of my way to avoid it because "git branch tmp HEAD; git $POSSIBLE_MISTAKE; git reset ---hard tmp; git branch -D tmp" requires less effort than deciphering the reflog's output.

Re: Oh Shit, Git

#200

Post by tharkun__ » Sat, Jun 25, 2022, 7:23 PM UTC

rfiat wrote: post #170

tharkun__ wrote: post #83

Earlier quoted context omitted.

I think this is what can confuse people. We have to face the facts that not everyone will need or be able to grok all of what goes on in git and what makes the car go forward. We can all drive that car still! Take the recursive merging stuff around minute 39. Do I need to know why git's model for merging is so much better and how it works its magic? I don't think so. It's an implementation detail. Do I need to know h…

> Do I need to know how a gearbox works to drive stick shift? No, but it helps. If I treat my car's powertrain as a black box then it won't be intuitive that: * I shouldn't slip the clutch to hold my car on an incline. * Blipping the throttle gives me smoother downshifts. * Double clutching lets me shift from 2nd to 1st while rolling. * I can use the engine to slow my descent on longer hills and avoid brake fade * I…

It may not have sounded like it but I'm actually going to agree with some of this. We might be on a different part of the gradient so to speak. Maybe you can find a good analogy but at least from my point of view the gearbox analogy is falling short now and we'd need a different one or look at git commands one by one :)

Like you say, you can just remember those things. In fact 4 out of those 6 were taught in driving school and you had to remember them. One I only learned because trucks still needed that (double clutching while shifting - not just your case, just in general) but cars didn't when I learned. I personally don't like copy and pasting commands like that but I see a lot of people doing that even for stuff that should be second nature because you need it all the time. I think - to stay in the analogy - for me this is the difference between knowing that I should engine break and how to do it when I want to slow down vs. having a piece of paper in the glove compartment that I pull out and check for what to do and how every time I approach a red light ;)

I'm also someone that likes to get an understanding of the things that I use and do every day. The thing is that there are so many things we use and do all the time that I think (almost) everyone just has to keep a certain level of abstraction away from many things, because there are just so many rabbit holes out there and it's not beneficial for most people to have explored every single rabbit hole all the way to the end (the 'gradient'). Git commit graphs are a DAG and lots of cool things can be done with DAGs, most of which I totally forgot about since I learned about and enjoyed them in university and have never needed them again at that level. It's good to know they exist and be able to dig in when needed/wanted.