history hard to read about netradiant-custom HOT 12 OPEN

Hi
The story is following:
I had 90 backups with a few changes in each one
When i decided to start using git, i reseted cloned repo to the initial point of my fork and applied backups one by one
Initial plan was to split then by feature, but cleaning and applying 90 ones was already huge work
I'm not too experienced with git... hopefully it's able to exchange commits between this and other branches :b
Prolly i don't understand you well, but which nonsquashed version do you want?

that's good for everyone of us

Not really
You easily break working stuff by considering only your particular use case or not even knowing your one/codebase enough well

As for missing fixes: i can merge them manually (at least there would be chance to understand them well this way); just show those commits

from netradiant-custom.

When i decided to start using git, i reseted cloned repo to the initial point of my fork and applied backups one by one

Oh I see, so in fact your fork did not have any git history at all? 😮

Does your fork was time to time synced with upstream or these 90 backups only contains your own changes between each of them.

I know a bit git (for example I'm the one who did the heavy scalpel work to extract the daemon engine from unvanquished source tree while keeping all the previous old paths of every file), so perhaps I can help you to rebuild the missing git history. Well, it highly depends of what exactly your backups contains (if they contains only your work or some random merge from upstream) and how I will be able to identify the original commits in the squashed ones.

Something very helpful to know is the very latest commit your pulled from upstream (the most recent one). I would be very happy to help to make this history more readable, if things make it doable of course…

from netradiant-custom.

Mostly my changes + a few worthy && verified ones from 'upstream', applied manually (never 'pulled' from one)
Commits titles are pretty certain about their contents
Tho they will expand to 600+ commits; but if that makes your happy, then c'mon...

from netradiant-custom.

how can we exchange code accross trees?

from netradiant-custom.

Is it rhetorical quiestion or just asking wrong person? -)

from netradiant-custom.

I'm asking @Garux and it's not a rhetorical question, I'm serious.

from netradiant-custom.

Idk, man, even potential options; Should be addressed to git gurus.

from netradiant-custom.

So the problem is that this branch diverge much from the Netradiant branch? This and UFORadiant appear to be most recently worked on. I will try to run this version as I have no luck with Netradiant.

from netradiant-custom.

So the problem is that this branch diverge much from the Netradiant branch?

That's not the problem, it's OK to diverge.

The problem is that information was deleted for each changes : dates, authors and how files were modified. This information is either deleted either mixed up with other changes or mixed up with custom changes that is specific to this branch. It means it's not possible anymore to pick-up one change from the history to exchange it with other forks. There is no way to find “the commit to add this feature” or “the commit to fix that bug” using tools made for that purpose.

To identify modifications in order to exchange them across radiants people have to read the whole code and to guess the additions by understanding every aspect of it. It requires intense thinking no one has time for, something the git tool was created to avoid.

When things are done properly, developers only have to read the code they have to read, no less, no more. That's what the git tool is made for: to make the contribution job possible.

A project like this has around 1 million word, that's almost 1.5 time a whole bible.

So to make an analogy, tracking modifications in this fork requires the same amount of cerebral effort that is required to keep the whole bible in brain to track changes that spans across more than 60 books. Some changes requiring both complete new paragraph in some books and just some words or even punctuation variation in some others. And if the lightest punctuation change is missed, the modification change would not be properly extracted hence improper for inclusion in another tree.

It looks like git is only used as a storage system there. This is using git but doing all the git work with the brain instead of letting the computer doing it. That's very painful and time consuming. Not only for others, but also for Garux. That's why the current situation is not good for anyone.

This and UFORadiant appear to be most recently worked on.

The current worked on radiants are:

• GtkRadiant
• NetRadiant
• Garux's NetRadiant (this one)
• UFORadiant
• DarkRadiant

In term of features the most advanced radiants are DarkRadiant and UFORadiant (forked from an old DarkRadiant but with things DarkRadiant does not have, like prefabs browser), after that comes NetRadiant then GtkRadiant.

Unfortunately UFORadiant is not multigame and DarkRadiant still lacks legacy q3 brush support (no problem if not using them) and q3 def support.

I already contribute to NetRadiant (Xonotic's upstream), GtkRadiant and DarkRadiant, so I have nothing against forks by themselves but this tree is the most painful tree to work with because of the mistakes that were done at its early age.

I offered my help to fix these mistakes more than one year ago but it never meant I'll do it all by myself. It would not be fair. Also, nothing proves that effort would be useful if we're not sure such mistakes will not be done again. That's why I propose my advice.

Note that I never consider the situation being intentional, but unfortunately this fork became the most painful tree to work with because of things that looks to be mistakes, mistakes that would have been avoided from the start thanks to advices people can provide. I can help (it does not mean I will do it alone).

Note that we all have busy lives but if you need help to run NetRadiant you can find me and others on #xonotic irc channel at Freenode, you can also find me on #unvanquished-dev (or Unvanquished's discord).

from netradiant-custom.

In fact this is the most advanced radiant in context of editing.
DarkRadiant has a lot of Doom 3 specific stuff and just a few cool bits about editing.
It is often impossible to direct grab wanted feature, even with good commits history, as code logic might be not dead simple; new stuff often relies on other changes, so decent grasp is required to play with codes (recall net->gtk q3map2 thing porting).
I'm not up to splitting 90 commits to 600 either ¯_(ツ)_/¯

from netradiant-custom.

I just want to say as someone who's tried a lot of different versions of radiant; this is the one that's worked for me. I don't have the technical knowledge about radiant/darkplaces/bsp/shaders to explain the issues I was running into; but until this repo's version of radiant I couldn't use it, I was last using JACK, but wasn't happy with it. It's been working like a charm and I hope it doesn't go away. Thanks.

from netradiant-custom.

@badquanta no one is saying there is no interesting things in this tree (otherwise no one would complain about the tree being hard to merge), the issue is about having two trees that have both fixes and enhancements the other does not have and this one being hard to merge so no one can benefit from all the fixes and enhancements at the same time. So please keep on topic.

Also this is not a question about which developer wins, first there is no competition, second it's about you losing as an user. Having fixes and enhancements split in two trees means your are losing as an user. If you hope this work doesn't go away, your only hope is in seeing it being merged one day.

from netradiant-custom.