Contributing upstream.

[CKolkey]

Hey @ten3roberts :)

I've been having loads of fun with this plugin. So much fun, in fact, that I'm at a bit of a loss on how to keep contributing back to this repo, since I'm building on top of things... pretty quickly. You can check out the full diff here, but the shortlist of changes is:

• Getting the UI for popups to better match Magit (multiple columns with headings)
• Cherry Picking popup
• Reseting popup (hard/mixed/soft/file implimented)
• Added Telescope to provide a fuzzy branch selector
• Removed CursorMoved autocommand for the status buffer (it's..slow)
• Also removed CursorMoved autocommand from the commit_view buffer... because it's very slow. I replaced it with a decoration provider.
• Bugfixes
• Performance improvements
• Diff's all get lazy loaded now, including the CLI IO.
• Added FileSelectView buffer for fuzzy-finding files
• Added Finder lib as an abstraction/interface for Telescope
• When creating a branch, whitespace in user input is replaced with -.
• On status buffer, show diffs for new and deleted files, even if they are untracked
• Added many missing switches/options/actions, though most are not implemented yet.

Anywhoo, I know thats an obnoxiously long list of things. I'd really love to upstream it all, but I also don't want to overwhelm you all. And, if you're not interested, I completely respect that and I'll just keep doing my own thing.

How would you like to proceed? :)

[gegoune]

I, and bet many others too, am very happy with new wave of life you were putting into this plugin. I have been tracking your progress recently and am in awe with what you are doing here.

Hope your work will land on master branch. Thanks for all your effort and time!

[CKolkey]

I got tired of seeing my colleagues who use Emacs have all the fun.

[ten3roberts]

All this looks amazing.

I guess this also closes #415 and a good few others.

It may be good if the owner of Neogit looks through the meta to ensure it all still aligns with the goal of the plugin. Furthermore, if you wish to become a maintainer you can ask @TimUntersberger

[CKolkey]

Yea, I'd love to come onboard if that's possible. I figure feature-parity with Magit is probably within scope, no?

What's the best way to get in touch with him?

[ten3roberts]

It may be worth creating a pinned Breaking changes issue, and mention some of the things like telescope being required, and the filetypes having changed for people using autocommands.

Additionally, on my part it is ok to diverge from Magit and be our own thing if it proves for the better.

How is the lazy-loading diffs different from the previous PR which lazied them?

[CKolkey]

Good idea, I can do that.

I'd like to avoid a hard fork, but I'm not against it. Mostly just to continue delivering value to the existing userbase.

The diffs thing just builds upon what I already did, but instead of just deferring the processing, we can defer everything. The biggest change is wrapping the git cli calls in their own closure. I was getting swamped by "too many open files" with... not many changes in the index. By wrapping those calls in a closure, we do just about no work when building the buffer.

[ten3roberts]

From what I understand @TimUntersberger does not have that much time to actively develop and code, but is usually reachable for discussions by pinging.

[CKolkey]

Gotcha. Alright, @TimUntersberger, if you're reading this, I'd love to become a contributor to this project if that's alright with you :)

[ten3roberts]

It would be fantastic if you joined as a maintainer, and your downstream features look awesome

[ten3roberts]

Hey @TimUntersberger are you okay with adding more maintainers to this project?

[ten3roberts]

Unfortunately, I am unable to add more contributors due to insufficient permissions. I can only push and accept PRs etc.

But if you want to open larger "general" PRs I will be more than happy to review and merge them.

[CKolkey]

Yea, if you're up for that, then that could be a way forward. How big is too big? At this point I've messed with... a lot of different levels (buffers/popups/lib/git), that are all - as you know - somewhat interdependent.

Maybe a good place to start are the PR's that I have open currently? Some of it is out of date, but all of those commits are in my fork's history. Or we could be slightly less responsible and merge it all now as a one-time-deal, and keep it in smaller pieces moving forward. What's best for you?

[ten3roberts]

Perhaps separate PRs which are separate or larger features as much as possible.

How many breaking changes are there in the lib/git levels? Because what could be done is merging the "backend" at once, and maybe fix some existing code to conform to the new api, and then merge feature by feature ontop of that.

[CKolkey]

Alright, I'll see what I can do to find a logical division between things. IIRC there's not a ton of breaking changes with the git stuff, but a lot of things are added or expanded upon.

I closed the existing PR's that were open on this repo, since a lot of them are outdated.

I've incorporated (and built upon) #448 and #451, so it would be good to get those merged in when possible.

[misaflo]

* Added Telescope to provide a fuzzy branch selector

Is it possible de use vim.select instead of telescope? With plugin like dressing.nvim it leaves the choice between telescope, fzf, nui or a built-in.

[ten3roberts]

Oh, that kind of "blocking".

You could do

local async_select = plenary.async.wrap(vim.ui.select, 3) -- 3 arguments (items, opts, callback)

which will transform a callback style function where the callback is the last argument, into an "blocking" style async fn.

If the callback isn't the last function I just write a wrapper

[ten3roberts]

I only use telescope when the user can perform multiple actions compared to just selecting with enter, or to show additional information using the previewer

[CKolkey]

Hmm, alright, if it's that straight-forward then we could give it a look. While I do like having a bespoke fuzzy-finder styled after emac's ivy, maybe it would be more polite to leave it up to the user to decide

[ten3roberts]

If we don't need multiselect and/or keymaps, e.g; <C-l> to open log on commit <CR> to checkout, etc we should prefer vim.ui.select and let the user setup dressing.nvim or alike for fzf-lua, which is something I suspect many already do, and will further unify plugins

[CKolkey]

I did use multi-select for the reset popup to be able to reset multiple files at once

[CKolkey]

@ten3roberts Since we're getting close to catching up with my fork, I was wondering how you feel about merging in the entirety of my fork instead of the CKolkey branch on this repo. The principal reason to do that would be to preserve the git-history for all the files. I don't know how much you use this, but I make heavy use of history when debugging a tricky problem, to get a context for why a change was made.

In order to pull that off smoothly, I've can do a couple things:

1. Merge CKolkey into my fork, so any/all changes that we've made along the way are kept. (I've been doing this)
2. Move all my current "in development" features to a new branch (I've already done this) so master is "frozen", so to speak.

Also, regardless of how we merge all this into master, I'll be around to field any bug-reports/issues that come in. Really wish I could commit on this repo, but... This will have to do for now. @TimUntersberger, if you're reading this... ;)

[ten3roberts]

I use git history quite a lot whenever debugging, mostly to figure out if the problematic code block is as it is because it fixed another issue.

I am always slightly put off for projects using squash merges, as that information is mostly lost or buried deep inside a commit description.

That sounds like a good idea, and doing it piecemeal like we have done has helped to break down and validate the changes separately. Since I have already had the chance to have a look and review it. So technically, your fork is also review. (insert mathematical set theory about knowing A and B separately implies you also know of A ∪ B.) The diff will mostly be the same, but the history will be preserved which is an added cherry on top.

What I could do now is have a look at the 3 more PRs, and we could merge them all into the ckolkey today to get it all done, and then compare that to your fork to see if there would be any feature that will sneak in undetected so that we don't break anything. I am mostly thinking about the difference between the non-telescope picker in ckolkey to make sure that no direct telescope picker usage if outlied in your fork.

Most likely, the difference between the fork and the stacked final ckolkey will be minuscule, which is the only part I'd need to look at, so go ahead, sounds like a great idea ❤️

I will also be around and commit often (when *everything inside popups won't induce creating a merge conflict)

I have sent @TimUntersberger an email just now, and if he does not respond in perhaps the next coming week I am thinking about creating an issue for a public opinion of forking or in other ways moving neogit to an organization so that more people can benefit and contribute.

[ten3roberts]

If there are any remarks I find in the remaining few PRs I'll just note them down personally and fix that afterwards

[ten3roberts]

Is it ok if I approve and merge the upstreaming 8-11 PRs into ckolkey now?

[CKolkey]

Agreed on all points 😊 I'll write a better response tonight after my kid is asleep

[CKolkey]

Alright! Glad to hear we're on the same page then. At your convince then, let's get the remaining PR's merged into origin/ckolkey, then I'll make sure ckolkey/master is up-to-date with all of it's changes, and I'll figure out a nice way to enumerate any remaining changes.

For what it's worth, I appreciate the restraint in creating conflicts 😓 I know it's a pain to have such a big set of changes, but ideally this won't need to happen again.

I have also considered creating an organisation to manage this project, though I didn't wan't to do it without the blessing of the existing project. Hopefully we hear back from Tim about this soon, otherwise I think it would be perfectly reasonable to move forward in making this more of a community driven effort.

If we do go that route, I think it would be pretty straight forward to add something to the setup() function like print("Neogit has moved repo - update your config to point to 'neogit/neogit'") and chuck something similar in the readme. But, let's see :) I'm mostly just excited for all this work to see the light of day, haha :D

[ten3roberts]

Neogit is now moved to an organization, and you have been added as a collaborator.

Feel free to create branches and PRs and commit fixes directly to this repository. Hopefully you won't have to maintain your separate fork.

I figure we finish up this upstreaming synchronization using a PR as mentioned above, and what I'd recommend it so either merge or rebase and use the aggressive --our/--theirs (depending on merge or rebase) and just choose you forks version of all the conflicts, and they will then show up in the final PR. That way we will save all the hassle of conflicts which may arise from the slight differences between the fork and the ckolkey branch due to PR changes.

[CKolkey]

Awesome - Thats so much easier, thanks for making that happen. Hopefully the merge shouldn't be too bad - I've tried to backport the changes. Lets see. The really nice thing is that Neogit is far enough along that all of this can be done without needing to bail out to the shell 🥳

[CKolkey]

When you have a minute, do you mind enabling the update-via-rebase feature for this repo? It's nice to have the choice between merge commit and rebase in the UI :)