Recommend new users use the repo as a template instead of as a fork

[stephansama]

currently the recommended installation step is to fork the repo and then continue from there "kickstarting" your configuration. i think it would make more sense if the repo was converted into a template (similar to neovim-plugin-boilerplate) that way users do not get "out of sync" with something that they should only have used as a starting point.

https://github.com/nvim-lua/kickstart.nvim?tab=readme-ov-file#recommended-step

[guru245]

I like this opinion. This can prevent users from sending a false pull request.

[Sefriol]

No. This is actually a great feature and allows you to update changes to your configuration, if you so desire. I have done this multiple times and regularly update my own fork.

Guide should be updated, recommending you to do your changes in your own branch after forking. This way you can easily sync changes to your fork's main branch and rebase fast forward them.

I have used this workflow over a year with only minor merge conflicts.

False pull requests might be a nuisance to the maintainers, but also quite easy to notice.

[stephansama]

No. This is actually a great feature and allows you to update changes to your configuration, if you so desire. I have done this multiple times and regularly update my own fork.

Guide should be updated, recommending you to do your changes in your own branch after forking. This way you can easily sync changes to your fork's main branch and rebase fast forward them.

I have used this workflow over a year with only minor merge conflicts.

False pull requests might be a nuisance to the maintainers, but also quite easy to notice.

This is an interesting point. I personally do not use kickstart so I am not super opinionated on it. I just noticed this when I was helping someone who uses it. And thought it could potentially help others. Curious what others think as well.

[JoniBecker]

Neovim-Newb perspective:
I've been using kickstart as a starting point for quite a while but never really did much with my nvim config, only updating my fork a couple of times. However, between the last two times updating my fork, I wrote a small nvim plugin for myself. When it came to updating my fork again like an hour ago, I intuitively also settled on moving my custom configuration into a custom branch, discarding the custom commits from my main branch and rebasing my custom branch onto main once I updated the fork.

What I'm trying to say: At least from my limited amount of experience, this seems like a rather intuitive way to go about things (admittedly, I have a relevant amount of experience working with git in professional settings, so not sure how intuitive this would be for someone who is also new to working with git).

[ggrzybow]

I also only make limited changes and keep them on a separate branch. From time to time I pull the current master branch and rebase my branch on it. I don't want to deal with things like some plugin moving to a new repo or being discontinued and in need of a replacement. I let kickstart devs deal with it. This way I only maintain my specific changes.

[eamonburns]

Something that is annoying with creating a fork for your own configuration is that it makes it difficult (impossible) to create a second fork if you want to contribute.

I made a fork for my own configuration. I now want to contribute, so I tried to make a fork but can't, since I already have one (GitHub is annoying sometimes). If I want to contribute, I'll have to somehow either disconnect my fork from upstream entirely, or maybe create a special branch on my fork specifically to keep up to date with upstream that I can then branch off of and contribute back.

[Sefriol]

I made a fork for my own configuration. I now want to contribute, so I tried to make a fork but can't, since I already have one (GitHub is annoying sometimes). If I want to contribute, I'll have to somehow either disconnect my fork from upstream entirely, or maybe create a special branch on my fork specifically to keep up to date with upstream that I can then branch off of and contribute back.

Easiest way to work with this is to put your config to feature branch. Then you can easily sync main branch to your fork.

If you setup upstream to your git config, you can do this via console too using rebase. That is what I do personally.

[eamonburns]

Easiest way to work with this is to put your config to feature branch

Yeah, but that would have either required for-thought on my end, or a note in the instructions.

I will likely do this, but I'll have to fiddle around to move my config to a different branch, and hard reset master back to tracking upstream

[Christoph-Raab]

Just watch PRs in this repo for a week and see the tons of PRs being closed without being merge, pply because newcomers don't understand the workings of GitHub and forks (yet).

I guess maintainers are so deep into how to work with this, they don't see, how someone new to this who just wants to get started with nvim might have issues here.

Switching to template repo would definitily reduce the noise. But instructions should also contain a good explaination about how to keep the template repo in sync with upstream. Bc currently it's just a button in the ui one has to click (provided they didn't produce any merge conflicts).

[oriori1703]

Just watch PRs in this repo for a week and see the tons of PRs being closed without being merge, pply because newcomers don't understand the workings of GitHub and forks (yet).

That's true, but there are also a lot of non-newbies that just click the open button too quickly and notice immediately (talking from experience :)

[oriori1703]

I would like to close less accidental PRs, but the one click update for noobs is also nice, so I'm not sure what is better.

Anyway, it doesn't matter what I think because I don't seem to have permissions to change this even though I'm a maintainer, so we have to defer to higher authority.

@tjdevries Do you have any opinion on this?