Seems like the author's only talking about the extreme end of the spectrum. Not every fork is attempting to replace the forked project. There are so many other lesser degrees.
You can fork something just for a fun or experimentation. You could have a use case that the project doesn't handle and you aren't ready or interested in contributing that solution (especially if you only need this for a one-off scenario or a short-lived project).
This could also apply to needs that your client or company has, but it's out of scope for the original project, so you make a private fork that you and your team maintain internally. It could be that you DO actually make this public (either initially or eventually) so other people who have the same need can benefit and possibly contribute.
It could even be that, over time, the amount of users of your fork convince the upstream project that there is a need for this use case. Maybe they decide to handle it themselves or maybe your fork merges back in with the upstream. Sometimes projects just can't say yes to certain things because they wouldn't want to/be able to implement, maintain and support it. Seeing that you and others maintain a fork for a non-trivial amount of time can establish the credibility that there is indeed someone who will maintain this.
2. You don't need to be a Vim pro to interactive rebase effectively. Most of it will be `dd` to remove a line, `p` to paste a line, `j`/`k` to move up and down lines, and `cw` to change `pick` to `edit`, etc. Spend 15m with `vimtutor` (which is probably available on your system) and you'll never be afraid of vim again.
TIL there is 'vimtutor'. I barely new the basics for quickly creating a file and inserting stuff. Will have a look if there is something to learn there, thanks for the pointer.
You’re getting downvoted (probably because of the mini Vim tutorial in #2) while the author of the post wrote a whole TUI because they didn’t know to change their EDITOR variable.
Learn your tools, people. This is the equivalent of a contractor taping rulers together because they didn’t realize their bag comes with a tape measure.
> Learn your tools, people. This is the equivalent of a contractor taping rulers together because they didn’t realize their bag comes with a tape measure.
I feel like this is one of the big things we lose when working completely remote and disconnected: missing out on all these chances to help each other. We don't know the things we don't know.
Imagine OP was going to do a rebase -i, sitting next to a teammate and said, "man, I would do anything to be able to use interactive rebase without having to learn vim", and their teammate turned back and said, "Oh, you can use any editor you want".
Yes, but EDITOR is also read by a lot of other tools. And if you want to use a particular editor with git, and didn’t know about EDITOR, you probably want to set EDITOR so that when other tools open an editor it will be the same one.
But if you already have that and want something specific and different for just git then yeah GIT_EDITOR.
It depends how you use them. If your goal is learning and understanding, you will use LLMs much differently than if your goal is to produce copy-pastable code with as little effort as possible.
Honestly, I do a bit of both depending on the situation. Sometimes I just want a one-off script that does xyz and I don't really care enough to have a deep understanding of every detail. Other times I'm getting a crash course in some advanced concept and in an hour I have knowledge that previously only someone with years of experience in a niche domain (and a lot of patience for my dumb questions) could have given me.
Get Programming With Haskell by Will Kurt. Made up of small lessons that all build on top of each other and will really help you understand what's going on.
I wanted to like Effective Haskell but honestly didn't. YMMV.
You can fork something just for a fun or experimentation. You could have a use case that the project doesn't handle and you aren't ready or interested in contributing that solution (especially if you only need this for a one-off scenario or a short-lived project).
This could also apply to needs that your client or company has, but it's out of scope for the original project, so you make a private fork that you and your team maintain internally. It could be that you DO actually make this public (either initially or eventually) so other people who have the same need can benefit and possibly contribute.
It could even be that, over time, the amount of users of your fork convince the upstream project that there is a need for this use case. Maybe they decide to handle it themselves or maybe your fork merges back in with the upstream. Sometimes projects just can't say yes to certain things because they wouldn't want to/be able to implement, maintain and support it. Seeing that you and others maintain a fork for a non-trivial amount of time can establish the credibility that there is indeed someone who will maintain this.
reply