VC History?

[neovim]

VC History?

[frioux]

It's still kindav a drag that in your initial commit you did a bunch
of stuff, so we can't even see the diff between that and what you
forked off of.

[cweagans]

On one hand, I'm very in favor of this, as it will allow for easily figuring out why a line of code is how it is.

On the other hand, the architecture changes for this project seem pretty significant, and I'm not sure how much longer mainline patches will even apply to this codebase (especially if all of the stretch goals in the crowdfunding drive are met).

[frioux]

Sure, but currently unless you manually do a diff you can't even really see
what @tarruda did for that first commit.

[blueyed]

Please note that there is a semi-official Git mirror already, which could be used to fork neovim from: https://github.com/b4winckler/vim

[frioux]

Ah, thanks @blueyed, so then the fact that that source wasn't included is even more silly to me.

[tarruda]

As @cweagans mentioned, I doubt that upstream patches can be automatically merged after processing the source files with unifdef/uncrustify, and especially after merging #91 .

Personally, I don't think that automatic merging of upstream patches will be missed and here's why:

• Vim is full of spaguetti code and consequently very fragile to patches (for an example, see #3). I'm sure many of those bug-fixing upstream patches to end up introducting other bugs that only get to the surface later.
• After the initial cleanup, the SLOC count went down to about 160k, and is will go much lower as the refactoring progresses. For example, all patches related to GUI , terminal handling or automated tests won't be necessary in neovim as those parts will be rewritten in lua.
• After the first iteration(see first stretch goal) neovim will suffer another great 'weight reduction' with the replacement of the code implementing vimscript to an implementation on top of lua(eval.c will likely be replaced too). I wont be surprised if in the next two or three months the SLOC count goes below 100k.

If some patch fixing a critical bug is pushed by Bram, we can always apply it manually. Otherwise it can wait until the code is more maintainable.

[Olivia5k]

You should still be able to see that by checking out the original commit as noted in the commit message and diffing that against that original commit?

I don't really see the benefit of this anyway. The refactoring applied to this repo will make patches unusable without manual intervention, so walking through hoops to retain the old history that we are walking away from seems backwards to me.

[tarruda]

yes it shouldn't be too hard to generate such a diff from the first commit. closing as it isn't currently relevant