New in Git: switch and restore • Hacker News Board

Re: New in Git: switch and restore

#481

Post by wizzwizz4 » Mon, Aug 02, 2021, 1:22 PM UTC

ekster wrote: post #216

wizzwizz4 wrote: post #209

Earlier quoted context omitted.

Version control isn't a tool I use. It's the filesystem I store my files in.

Would you use an accountant who doesn’t think it’s important to know how to file documents, or that their file cabinets are even a tool of the trade?

I know how to file documents in filing cabinets. I don't know how the bearing mechanism for sliding out the drawers work, or how to replace the user-serviceable locks – but I know that there's a mechanism, and that the locks are user-serviceable, and I could look up the relevant information if I ever needed to do anything with that.

You don't need much knowledge of your version-control system in your head to be an effective programmer.

Re: New in Git: switch and restore

#482

Post by dotancohen » Mon, Aug 02, 2021, 1:32 PM UTC

mixmastamyk wrote: post #435

Shacklz wrote: post #131

Earlier quoted context omitted.

> Figuring out what "properly" means is the whole problem with git. I think you've missed OPs point by focusing too much on a single word ('properly'). Yes, there's no clear-cut way on how to use git, no silver bullet, but the main problem with git is that most devs simply panic when they have to do anything that goes beyond the bog-standard commit/pull/push/merge. Rebase? Squash? Reset? Rebase interactively? I think…

I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts. So I go back to merging the main branch into my feature branch workflow, which works every time. I then hit squash in gitlab for my merge request, and no one is the wiser. Should I be doing something different? As I said, rebase in that situation is disastrous. Many folks rec…

I've never understood - or used - rebase as a standard part of a workflow. And I've been using git for nine years.

What is wrong with a master branch whose history reads "Merged feature foo" after "Merged feature bar"? If you need more detail then check out the feature branch and git bisect to your heart's content.

I do wish that we could "archive" branches from the output of `git branch -a` but really it's not a big deal when branch names are prefixed by Jira ticket identifiers.

Re: New in Git: switch and restore

#483

Post by Arch-TK » Mon, Aug 02, 2021, 1:33 PM UTC

afiori wrote: post #461

Arch-TK wrote: post #440

Earlier quoted context omitted.

I don't know, most people I've seen "scared" by merge/rebase conflicts have simply been scared by the UI provided to resolve them. It's just a matter of spending a bit of time familiarising yourself with what you're seeing and understanding what the tools are doing. There's a bunch of resources on that and once you wrap your head around what git is doing it shouldn't be too hard to figure out how to navigate conflict…

Merge conflicts in a rebase can propagate through every commit in your feature branch (suppose that you modify a boilerplate line in 10 commits, and you get a conflict on that line in the rebase, you now have to solve that conflict 10 times possibly with some interference with nearby conflicts) In many cases also there are problems with git being line oriented rather than token oriented, IMHO I would have expected la…

>Merge conflicts in a rebase can propagate through every commit in your feature branch (suppose that you modify a boilerplate line in 10 commits, and you get a conflict on that line in the rebase, you now have to solve that conflict 10 times possibly with some interference with nearby conflicts)

Yes, this is true. But in a lot of cases this is a relatively trivial fix. That being said, I do think git could do better here. But I have not had it happen very often (and usually I know when it's about to happen so I know what to expect).

> In many cases also there are problems with git being line oriented rather than token oriented, IMHO I would have expected language aware diffs (for definition of "words" and maybe parenthesis) for common languages to be common place by now (maybe even with a language server support)

Language aware diffs would be a neat idea indeed, but I guess the issue may be that now git would need to have metadata to tell it which language server to use for which file.

I wonder if it would be possible to give git a plugin system for diffs, just have an option to offload to a diff program which could handle the metadata separately.

Re: New in Git: switch and restore

#484

Post by web007 » Mon, Aug 02, 2021, 1:37 PM UTC

pdimitar wrote: post #439

web007 wrote: post #416

Earlier quoted context omitted.

Don't use it blindly. Learn it enough that you understand those mystical incantations and aren't summoning Cthulhu by accident, only on purpose Don't cookbook it, understand what the thing you're typing means. Don't use a GUI to abstract it away, be familiar with the CLI and what it's doing. Don't default to rm-rf when you get stuck, check git reflog and see if you can unfuck yourself first. Ask someone who doesn't h…

In my eyes all you did with this comment is join the people your parent poster is arguing against; you kind of just reiterated the stance they don't like. Not sure how constructive such a comment is. > it's the people familiar with "what does pull --rebase really do?" that don't get into trouble and/or can get themselves back out of trouble Absolutely not my experience. No small amount of people who seem to be doing…

> I am not paid to know GIT inside out. I am paid to deliver and fix code and to not step on other people's feet.

Your argument is still the same as the other git detractors, and is still wrong.

It _is_ part of your job, it _is_ part of delivering and fixing code. It's the same as anything else you're using. It may be a larger surface area that you're exposed to, but it's no different from CI/CD, build systems or something like a package manager. You don't need to understand how pip or npm or maven works to deliver software effectively, but if you get into trouble you have no alternative to rm-rf.

> As if I care what an index, staging area, reflog etc. are. I don't.

If you don't want to learn it then stop complaining about how difficult it is to use. That's your problem, not git's.

All of those things are important to the power of git. If you don't want / refuse to learn about them then you're trying to build your software with a car stuck in first gear and complaining about how slow it is. STFU and RTFM.

None of this detracts from your final point, which is valid! Just because the UX is mediocre (at best) doesn't mean you can't learn it.

Re: New in Git: switch and restore

#485

Post by afiori » Mon, Aug 02, 2021, 2:04 PM UTC

Arch-TK wrote: post #483

afiori wrote: post #461

Earlier quoted context omitted.

Merge conflicts in a rebase can propagate through every commit in your feature branch (suppose that you modify a boilerplate line in 10 commits, and you get a conflict on that line in the rebase, you now have to solve that conflict 10 times possibly with some interference with nearby conflicts) In many cases also there are problems with git being line oriented rather than token oriented, IMHO I would have expected la…

>Merge conflicts in a rebase can propagate through every commit in your feature branch (suppose that you modify a boilerplate line in 10 commits, and you get a conflict on that line in the rebase, you now have to solve that conflict 10 times possibly with some interference with nearby conflicts) Yes, this is true. But in a lot of cases this is a relatively trivial fix. That being said, I do think git could do better…

> [...] in a lot of cases this is a relatively trivial fix. > [...] I have not had it happen very often

Often it is simple but it is tricky and hard to practice. Part of the problem is not git fault, it is just that thinking in diffs is not easy.

> metadata to tell it which language server to use for which file

My understanding is that git already does this (via filename or custom helpers) for binary/text files, I believe that it is used only for newline conversion, but for most usecases filename-based rules in a gitignore derived syntax would be enough.

Re: New in Git: switch and restore

#486

Post by afiori » Mon, Aug 02, 2021, 2:05 PM UTC

alkonaut wrote: post #369

> with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch > You can do the same with the new one, but the flag is -c: git switch -c new_branch It's like they had a design meeting where they discussed this and said "so I propose switch -b newbranch to create and switch to a new branch" and the objection was "nah that would make it consistent with check…

That is probably what happened, with the observation that being consistent with checkout is a terrible idea for everything, as checkout is a clusterfuck of a command

Re: New in Git: switch and restore

#487

Post by IgorPartola » Mon, Aug 02, 2021, 2:14 PM UTC

CrazyPyroLinux wrote: post #229

IgorPartola wrote: post #106

Earlier quoted context omitted.

“Hey can you help me? I stood up a kratr pod and it’s lined to fundle but for some reason when I try to press the bin tree to the overlay layer the reznik instance on my laptop says ‘out of tokens’. Have you ever encountered this?” No, no I have not.

Yup - Every darn time. Reminds me of "How it feels to learn JavaScript in 2016" https://news.ycombinator.com/item?id=12628921

Nothing has changed in 5 years, has it?

Re: New in Git: switch and restore

#488

Post by leokennis » Mon, Aug 02, 2021, 2:27 PM UTC

web007 wrote: post #484

pdimitar wrote: post #439

Earlier quoted context omitted.

In my eyes all you did with this comment is join the people your parent poster is arguing against; you kind of just reiterated the stance they don't like. Not sure how constructive such a comment is. > it's the people familiar with "what does pull --rebase really do?" that don't get into trouble and/or can get themselves back out of trouble Absolutely not my experience. No small amount of people who seem to be doing…

> I am not paid to know GIT inside out. I am paid to deliver and fix code and to not step on other people's feet. Your argument is still the same as the other git detractors, and is still wrong. It _is_ part of your job, it _is_ part of delivering and fixing code. It's the same as anything else you're using. It may be a larger surface area that you're exposed to, but it's no different from CI/CD, build systems or som…

The issue here is GIT is way more complicated to learn, because it has 10.000 options that might do what you want to do or do something else entirely.

Imagine your deployment pipeline required you to manually craft TCP packages to send to your machines to deploy code...would you still say "it _is_ part of your job, it _is_ part of delivering and fixing code", or would you say "that is stupid"?

With GIT, you are spending more time on learning and battling the tooling required to deliver code, than actually writing and testing the code.

Re: New in Git: switch and restore

#489

Post by Arch-TK » Mon, Aug 02, 2021, 2:32 PM UTC

afiori wrote: post #485

Arch-TK wrote: post #483

Earlier quoted context omitted.

>Merge conflicts in a rebase can propagate through every commit in your feature branch (suppose that you modify a boilerplate line in 10 commits, and you get a conflict on that line in the rebase, you now have to solve that conflict 10 times possibly with some interference with nearby conflicts) Yes, this is true. But in a lot of cases this is a relatively trivial fix. That being said, I do think git could do better…

> [...] in a lot of cases this is a relatively trivial fix. > [...] I have not had it happen very often Often it is simple but it is tricky and hard to practice. Part of the problem is not git fault, it is just that thinking in diffs is not easy. > metadata to tell it which language server to use for which file My understanding is that git already does this (via filename or custom helpers) for binary/text files, I be…

Currently for binary files git has heuristics described in gitattributes(5) and these only go as deep as text encoding autodetection and the ability to specify the text encoding of a file or mark a file as binary. It's not sophisticated enough to know what kind if file it's looking at outside of just that.

Re: New in Git: switch and restore

#490

Post by wpietri » Mon, Aug 02, 2021, 2:34 PM UTC

asimpletune wrote: post #418

wpietri wrote: post #399

Earlier quoted context omitted.

I have trouble imagining you can't figure that out on your own. If that's really the case, then take a little time and explain exactly what impact you think that comment would have had on the person they were replying to. Then explore some other ways to actually encourage submitting a patch. Write a couple of them out. If you do that work, I'm glad to try to help you see where their approach falls short in terms of s…

> I have trouble imagining you can't figure that out on your own. I'm not being coy, as if I really know what you think, but I'm asking anyway just to be frustrating. I mean, I have an idea , but I also didn't want to make assumptions about your intent, when it's just as easy to ask you to elaborate. After all, it's your point that it was incorrect, so I just wanted to know why. Any way, you said there are "legitimat…

I'm not convinced of anything based on one terse reply. But given the history of replies like that and given the user's history, it's my best guess that they were not intending to be helpful. I read them as being dismissive in a way that shuts down a complaint.

If I wanted to actually invite somebody to contribute to an open-source project, I'd start with positive reinforcement. "Great point! That's definitely an issue with the docs." I'd then first tell them how to let the right people know about the problem. "You can file an issue here Be sure to categorize it as X, mentioning Y, and Z." Then I would explain that if they wanted to get involved in the project, they could try submitting a patch, giving them at least a few sentences of instruction on what files to look at, where to find the contributor guidelines, etc. In sum, if I'm asking somebody to do work, I'd encourage them and do a little work myself to show that I'm trying to support them.

And it's not just me. The "submit a patch" bit is a cliche bit of jerkiness, so much so that there are whole discussions of it. For example this: https://softwareengineering.stackexchange.com/questions/6874...

And this: https://softwareengineering.stackexchange.com/questions/8323...

And it's a long-standing problem in open source. This, for example, is more than 10 years old: https://xenoterracide.com/post/dont-say-patches-welcome/

So if that reply truly seems fine to you, please understand that if it ever was, it has been ruined by a long history of people acting like that to be dismissive or jerky. That rudeness is something I can almost excuse in someone actually working on an open-source project, as they can get a raw deal. But I think there's no place at all for it in a forum like this.