Dev Meeting Minutes (2011-02-21)

[Kloot]

Date: 21-2-2011
Present: jK, abma, Kloot, spliff, Tobi

_Agenda_____________________________________________________________________

• assimp integration
• release plan

_Notes_____________________________________________________________________
<Tobi> ok if spliff joins to discuss assimp?
<Kloot> sure
<Kloot> (and hi)
[21:13:35] ** spliff joined the channel.
<spliff> hi
<Tobi> hey
<Kloot> lo
<spliff> only 4?
<Kloot> people tend to drop in later
<spliff> i c. i assumed i was very late :)
<Kloot> although hoi probably won't be coming again
<spliff> right, so is now a good time to discuss assimp?
<Kloot> fine with me yes
<jK> yeah, all relevant ppl for this topic are here
<spliff> ok. the gist of it is it's nearly ready, there's more to do but I don't believe it's a lot. main issue is some win7 64bit issue i haven't determined the cause of.
<jK> we don't support win64
<spliff> and i just test directly because I dont have win7
<jK> (a lot of trouble with the dlls)
<spliff> not even win7 64? i thought that was popular?
<jK> 64bit support is linux only
<spliff> well, it's a 32bit build
<spliff> it works on wine at least
<Kloot> and this issue is specifically related to the assimp lib?
<spliff> possibly
<spliff> or maybe just how i compiled it
<jK> you compile assimp with dynamic linking?
<jK> because it is sync related I would say it can be static
<spliff> it can be done that way, i'm currently doing it statically but mostly to make things simpler for me, i have no preference how it's built
<jK> I assume we can't even rely on linux package systems, because assimp could return different results depending on its version
<jK> so we have to include it with the tarball as lua
<spliff> i assume any working assimp version *should* return an accurate model on all platforms
<spliff> but the assimp API is quite young, it will probably change
<Kloot> yeah it needs to be very tightly versioned
<spliff> i also had to make changes to assimp itself, like using streflop
<spliff> at least i think i need to do that, i'm not sure how much effect the maths library has on the outcome of the assimp import
<jK> (for the minutes: the model is used for the collision volume, so it is synced related)
<Kloot> potentially quite a lot if the lib performs operations on vertex positions
<Kloot> which affect eg. collision volume sizes
<Tobi> (btw I will keep it short today as I'm a bit ill and need to get some extra sleep, I take it you guys can figure stuff out :))
<jK> yup, also offset & piece(+names) are
<spliff> yes, but i did speak to the assimp developers and they're reasonably sure the outcome of an import is deterministic
<Kloot> ok [RoX]Tobi
<spliff> much of it is just reading values from files after all
<jK> I am sure too
<jK> but still it is safer to rely on fixed versions
<spliff> sure, but even shipping our own assimp we still have the option of shared lib or static linking
<jK> in the case streflop is needed static linking is prefered by me
<jK> (all other dlls we include aren't compiled by ourself)
<jK> ourself = not in our cmake script
[21:33:11] ** abma_irc joined the channel.
<abma> hey!
<spliff> hi
<jK> hi
<spliff> so there's no real case for DLL then, we move on?
[21:35:36] ** [RoX]Tobi left the channel( Quit: Exiting ).
<jK> yup
<spliff> anyway, i came to ask what I should focus on to get the assimp code up to standard reasonable for merging
<spliff> and wether any objections stand in general
<Kloot> I understand your metadata format is not a superset of mine?
<Kloot> or rather, strict superset
<spliff> it is close, but i structure the piece table differently
<spliff> because i didn't want to require a whole hierachy to be built
<spliff> and i wanted to make it easier for scripts to build a metadata file
<spliff> ie, non-lua applications generating the file
<spliff> or parsing it if necessary
<spliff> like from blender python
<Kloot> hmm imo it's up to the modeller to decide if he wants a full or partial hierarchy; in the latter case he can just omit linking the relevant pieces
<spliff> i only require a single level table with children having a name attribute
<jK> why not move the metadata parsing to a lua-file (like defs.lua)?
<spliff> but in your format you can't omit a parent
<jK> so the engine just calls modelsmetadata.lua and sets a global var to the wanted model name and it returns the wanted data?
<spliff> the parser could be shared yes
<jK> this way such a lua handler could even add XML support etc.
<spliff> my concern is only that we can generate metadata from other applications
<spliff> but i'm not hot on an XML format
<Kloot> in practice that depends on whether the modelling tool has scripting/plugin support
<jK> I mean that such a handler gives the modeller much more flexibility (+backward compability)
<spliff> but we could be making it harder for tool developers who need to handler the data. it should be kept simple, even lua format is a bit overkill
<spliff> it's just keys and values really
[21:45:22] ** abma_irc left the channel( Quit: IRC connection timeout ).
<spliff> in the old days it probably would have been an FBI / INI file or whatever
<jK> not at all
<jK> the tool developer would just run the handler
<jK> and would get a standarized lua table
<jK> same as it is for defs.lua etc.
<spliff> perhaps, it seems quite common for tools to end up written in VBA or C#/.Net whatever
<jK> ?
<jK> who says they can't?
<spliff> as in the tools generally lack a true lua parser
<jK> but they already to be able to parse lua
<jK> they already need
<Kloot> there are lua bindings for c# afaiaa
<jK> licho uses it everywhere
<spliff> ok, then so not really an issue?
<jK> not at all
<spliff> great, i'm not in a hurry to change it
<spliff> so the other issue was how to handle OBJ.
<Kloot> indeed
<spliff> how would you like that to proceed?
<Kloot> until the community has really picked this up, I'd like to keep the better tested code alive
<Kloot> but I did assume there would not be any metadata incompatibilities
<spliff> i don't object in principle, there's only the matter of the pieces table
<jK> with a handler this could be solved
<spliff> i do prefer the flat structure to the nested
<Kloot> I figured
<spliff> jk, you propose a generic handler to pass a metatable to the model parser?
<jK> yup
<Kloot> so I'll look at adding a lua-lua parser
<jK> the model parser just calls 1 lua file and it searches the metadata file for the model and process it (e.g. changing the layout for backward compab.)
<spliff> ultimately i'm ok with anything except 2 seperate formats
<spliff> i just worry we'll make an unparsable model format mess
<jK> the formats don't matter they would be outsourced to the game itself
<spliff> if someone wanted to say export TA models elsewhere
<jK> it's the way all luadefs work in spring
<spliff> it would suck to have random metadata files to deal with as well
<Kloot> other engines would have their own metadata requirements
<spliff> but models are more general than spring
<spliff> with is why Collada has its own application-specific metadata
<Kloot> and collada is hellish to deal with :)
<spliff> not with assimp though
<jK> even then
<spliff> anyway, i just figure one format will be easier to handle overall
<spliff> and document
<jK> afaik all 3dtools have different standards for collada
<jK> so you need a handler for those to handle the different layouts
<spliff> well, honestly I'd just prefer to use kloots format entirely than have open house on the files themselves
<spliff> then write up the format in wiki and be done with it
<jK> bad
[22:01:10] ** abma_irc joined the channel.
<jK> it should fit in the current enviroment
<jK> and so it should work the same way as all other stuff
<jK> and it should be easy to maintain
<spliff> it does really, it's almost the same code as used for loading ModInfo and friends
<jK> so it needs to be possible to write backward compability code in lua (it's much easier on that stage than c++)
<spliff> well ok, so we require metdata files have a version number?
<Kloot> that is one way, the parsing script could also just insert defaults for missing values in older metadata files
<Kloot> so long as newer versions are only additive
<spliff> im losing track of what the issue is. we have two working parsers whose only difference is the structure of one table. we can have this working in under an hour just by picking one and sticking to it rather than build a more complex parser.
<spliff> we can move the code to it's own files though
<spliff> like Lua/ModelMetaParser.cpp or whatever
<spliff> but that file really only needs one way to order pieces
<spliff> multiple parsers just sounds like bloat
<jK> that file would support many types of formats and just return one standard one to the engine
<spliff> but each format needs a parser, are you saying right lua parsers?
<spliff> right=write
<jK> the metadata parsing would be pure lua
<spliff> as in lua parsers written in lua?
<Kloot> yes
<spliff> ok
<jK> same as unitdefs, weapondefs, featuredefs, cegdefs, ...
<Kloot> that's what all the current *defs parsers are too
<spliff> i thought they just eval a lua file
<jK> and it is reason why BA can still use TDF/FBI and other use luas
<spliff> but that's special-cased, not really inherent to the system
<spliff> anyway, i have no objection
<spliff> as long as it isn't too complex
<spliff> we aren't passing that much metadata
<spliff> most of it is optional anyway
<spliff> in the assimp parser the file itself is even optional
<spliff> so i'm more interested in code maintenance than flexibility
<jK> and that's what it adds
<spliff> ok, so who write it?
<jK> it can be done after the merge, also I have to learn those code paths
<jK> my idea of a timeline would be: 1. revert offset->pos rename (you said you already did) 2. make assimp linking static 3. merge 4. check syncing 5. add new lua metadata handler
<spliff> 2 is done
<jK> O_O
<spliff> 4 is untested
<spliff> also mac OSX untested
<spliff> win7 64bit crashes
<jK> win64 should be solved with static
<spliff> so i would say testing is main lack atm
<spliff> it is static
<jK> and macosx has a lot of troubles currently so it won't break anything
<spliff> the build i used
<jK> -a lot + a few
<spliff> i had to force doubles to floats in cmake build options for assimp, it may be related to win64 issue
<jK> maybe a pointer issue in ASSIMP itself?
<Kloot> has assimp itself been tested on 64bit ?
<Kloot> ^that
<jK> ^^
<spliff> i run gentoo 64bit, no issues here
<spliff> also i set:
<spliff> # Spring's compiler flags break assimp (especially -fsingle-precision-constants)
<spliff> SET( CMAKE_CXX_FLAGS "-g -c -DDEBUG -D_DEBUG -gstabs" )
<abma> compile on ubuntu 64 works fine, too
<spliff> in assimp CMakeLists
<spliff> unsure of potential side-effects
<spliff> and probably need to remove the debug stuff
<spliff> or test the cmake build type
<abma> what happens with -fsingle-precision-constants?
<Kloot> strange that -fsingle-precision-constants would break anything
<abma> maybe that can be fixed in assimp?
<abma> send bug reports to them
<spliff> i spoke to the devs
<spliff> via stackoverflow
<spliff> http://stackoverflow.com/questions/2026 ... ed-but-how
<abma> streflop stuff should be fixable...
<abma> (ok, i think i can't do it, but it looks not hard)
<Kloot> ah, that seems like a minor issue
<spliff> we can cast everything explicitly
<spliff> but i wanted to touch the assimp code as little as possible
<abma> yep, thats fine
<Kloot> ideally assimp would use an ASSIMP_REAL type like lua uses NUMBER
<Kloot> that can be typedef'ed to whatever
<Kloot> but if all of it is double-based then a simple #define double float hack could work too :)
<jK> we can make a patch
<spliff> there's another issue that assimp can use boost - if we match versions
<abma> or add a overloaded function to streflop, or make a patch for assimp... looks really minor
<spliff> for threading and optimisation
<spliff> current I use -DASSIMP_BOOST_WORKAROUND
<jK> why is it version bound?
<jK> boost is a very stable API
<spliff> not sure
<spliff> some change in thread lib maybe
<jK> it is stable since ages to
<jK> *too
<spliff> or maybe I did something wrong, but I remember boost issues at the start
<spliff> as in, the start of working on this
<jK> then it is worth to give it a 2nd try
<spliff> which the workaround... works around
<spliff> anyway, probably minor also.
<spliff> i need to check i've used the log system correctly too, i noticed one log system is mentioned twice in infolog
<jK> I favor an early merge, so those issues can be solved after it
<spliff> suits me, it's hard to keep up with master working from a remote repo
<jK> esp. because I don't know if we can cherry pick your branch or if we need to create new commits
<spliff> let me clean up my repo and then see
<spliff> i tried to do commits cleanly but i'm not as experienced at this as most of you
<spliff> git still defies me sometimes
<spliff> like that weird stuff with the Java AI
<jK> auswaschbar&hoij were our git heros (for cherrypicking & merging)
<spliff> hmm, what happened to Aus anyway?
<jK> left with imbaczek
<spliff> new project?
<jK> lost interest
<spliff> shame.
<Kloot> seems all foss rts engines I know about have this problem
<jK> bzFlag is dead too
<abma> there are others? no, that can't be!
<jK> the others were never as big as spring
<spliff> bzflag was over-hyped. it was cool when it was the only linux game in existence but now ...
<jK> also most of them were uni projects
<spliff> i have faith in spring, that why i chose it. it just needs a few more decent games
<spliff> because TA won't carry it forever
<Kloot> BA will "carry" it until we are all dead ><
<jK> lol
<spliff> yeah but anyone who played TA back when it was cool is old now
<spliff> that's just nostagia then
<jK> btw we still need to decide who does the merge
<jK> after spliff updated his branch
<spliff> so spring needs new coolness for twilight "noughties"
<abma> who is currently best in git?
<spliff> well, won't be me
<abma> hoijui, where are you? :-/
<abma> hm, but hoijui gave a few hints...
<abma> i think its best to follow them.. spliff did you try it? ( http://springrts.com/phpbb/viewtopic.ph ... 26#p474426 )
<spliff> not yet, i don't really understand what a rebase actually is
<jK> k will try to get hoij back on the ship till next week, I will learn git better
<spliff> and i don't know when the AI files changed
<jK> rebase overrides the parent commit of your changes
<jK> so the are moved to the top of the timeline
<jK> *they
<abma> afaik a rebase is: in my words: all your changes will be added as the last few commits
<spliff> so lose history basically?
<abma> yes, partly.. the order of commits will change
<Kloot> rebase is like a hard reset + reapplication
<abma> hmm
<spliff> hmm, i'll look into it, I'll try not to make it worse i guess
<abma> looks like 92869da99714dfacf4477292eb026468a959f88c is the faulty merge?
<jK> when not doing so, any "git pull" will add those crappy merge commits
<spliff> so if I understand this correctly i need to rebase 92869da99714dfacf4477292eb026468a959f88c ?
<abma> hm, as hoijui wrote, the previous commit of that
<jK> you should rebase the commits before those merge commits
<spliff> ok, thanks. i'll look into it later
<jK> -before +in front of
<spliff> anything else assimp related? otherwise I think I said everything i was planning to
<Kloot> I had some minor point about coding style but that can wait
<spliff> ok. so i won't make any major changes, just some cleanup in preparation to merge
<spliff> after merge we work out what to add/remove/change
<spliff> and you guys decide who want to actually merge it
<Kloot> in that case we can continue with the regular agenda now
<spliff> if that's cool, i gotta go. work in 30 minutes
<spliff> thanks for listening
<jK> thanks for your work
<spliff> it was fun... sorta. i think i'll stick to lua from now on though
<spliff> C++ is just hard work!
<Kloot> and sadly underpaid
<spliff> yeah, cheapskates :)
[23:08:52] ** spliff left the channel( ).
<abma> so... the rest of the agenda...
<abma> the two points are from me, i think, i'll ask tobi in a pm about that, as he is the person who can solve that?!
<Kloot> so that leaves release plan which is same as last week then?
<abma> oh... ok
<jK> macosx should be build in the same regular intervals as the others are
<abma> yep, i think so too... this will make it easier to see breaks in compiling
<abma> but afaik only tobi can change that in the buildbot config / set it live
<jK> I always thought it had to do with the onair times of the build client
<abma> no, its only not enabled: https://github.com/spring/spring/blob/m ... er.cfg#L91
<abma> adding there a ,"full-macosx" should enable it
<abma> i'll pm tobi about that
<abma> so... next point... who can create a subforum for implementation ideas? tobi, too?
<Kloot> all forum admins
<Kloot> http://springrts.com/phpbb/memberlist.p ... oup&g=3572
<abma> ok, thx, i'll pm someone != tobi
<abma> next :)
<abma> hm, about the release plan... are there enough fixes for a 0.82.8 ? imo currently the "units flying of map" isn't important enough?
<abma> #2360
<Kloot> http://springrts.com/mantis/changelog_page.php ==> three of these exist in .7
<Kloot> 2238, 2324, 2336
<abma> hmmm
<abma> then ok, looks like its worth to make a release
<Kloot> also 2301 is fixed by all accounts
<abma> but ehm....
<abma> hoijui, please cherry-pick! :-D
<abma> uh, damn... i play to often the master version... i thought, this is already fixed :-/
<Kloot> yeah, but we have to face the chance that he won't return
<Kloot> I can cherrypick those
<abma> yep i know :-/
<abma> would be nice if you do that
<abma> then commit to 0.82 branch + make some test-games...+ release
<Kloot> yup
<abma> ok... then... next?
<abma> / meeting finished?
<Kloot> I've nothing further myself
<abma> ehm, who makes minutes? i can do, but i'm missing a few minutes at the beginning
<abma> monday afternoon isn't currently so ideal... but other days won't be better i think

[knorke]

<spliff> i have faith in spring, that why i chose it. it just needs a few more decent games
<spliff> because TA won't carry it forever

Spring could have a huge advantage over closed source games (TA, C&C, Starcraft) where modders have to reverse engineer the engine. But it does not.
I actually found this by while browsing the forum at tauniverse.com:

Look at the Spring Forum : Modder do guess on how to do this or that, even the "official sticky" and wikis do guess. Devs absolutely don't care for what the users know.

Tools and documentation are just as important parts of an engine as the engine code itself. If something is not documentated, it can not be used. Atm you need to look at other games and c&p for so basic things such as weapons.
decent docu -> decent games.
But if this new model format and its tools are anything like Upspring then yeah..

[SinbadEV]

But if this new model format and its tools are anything like Upspring then yeah..

Theoretically the "new model format" is essentially a way to allow ANY model format to be used... so presumably that should fix this issue as people will be able to model in whatever tool they wish and then provide some meta-data in a "simple" text file.

[knorke]

and then provide some meta-data in a "simple" text file.

and that will need to be explained ie what variables there are.

[hoijui]

they way jk and abma described rebase is just the most basic/common way of using rebase. rebase -i is something quite different. basically: you choose what part of history you want to rewrite (usually, you just give it one sha1, of the commit before the oldest commit you want to change). then it lets you choose which commits to delete, merge together with other commits, re-arrange order of the commits, edit commit contents or only the commit message. everything except changing commit content can be done automatically, as long as there are no conflicts. .. i guess you should just read about it in a tutorial or so.
it is a very handy/useful thing, even for daily work. like when you have 10 commits locally, which are not yet pushed to master, and you forgot a tiny thing in the 5th commit, you just rebase -i . takes no time if you are used to it, and you will not end up with a much nicer history. this may mean, that the 5 commits in-between are compilable, or that a change is where it should be, and you do not have to do a "-" kind of fix commit.

cherry-picking is nothing special... it is about the ugliest thing you can do, and it is one of the main reasons for using the new branching model, as it will largely prevent this (if applied right).

if i am around, i can do the merge, but i think anyone could do it. just do it locally, and have a look at it in gitk, and do some git diff --stat afterwards, to see if it looks right, and only then, when you are sure about it, push it! .. or maybe push to your own repo on github and let one of the other devs have a look if you are unsure, you can always force push something else there.
reverting merges and re-applying is not something you want to do.

[FLOZi]

Documentation is as much our responsibility as it is theirs.

[knorke]

Documentation is as much our responsibility as it is theirs.

making "advanced" tutorials & guides - yes. Figuring out what ConfigureLayout() --> "command" does, figuring out what the minimal unitdef for a unit is or what tags are used by a FlameThrower type weapon - no.

[SpliFF]

I 've performed a rebase but I'm discovering this solution is actually more of a problem than the problem itself.

There are something like 1000 commits after the point where I pulled a release branch rather than the master and it took me nearly 4 hours to resolve all conflicts back up to the HEAD. Many of these conflicts turn out to be irrelevant in the long run (like changes to files that will later be deleted). In the end my branch still had changed/additional files from master. Rather than repeat the whole thing I simply deleted all affected paths and checked those paths out from master - checking it with git diff to ensure only necessary files are changed between the branches.

I realised I'd rebased from the wrong commit. The problematic one was actually further back in the history. Unfortunately my second rebase attempt required me to resolve even more conflicts in code I hadn't actually changed (like in the Java AI, docs and installer) so I have no way of being sure what to merge or skip. This time the rebase took even longer and I'm even less sure the process was clean.

The biggest issue is the list of commits to 'pick' are show separately from the merge that brought them in. To cancel the 'merge from 0.82.7.1 branch' I need to know which individual commits were involved and I'm not sure how that's done.

Honestly I'd have to say the rebase appears to have solved very little. For all the time spent on this the original history may actually be better than the rebased ones. The assimp-2.0 branch contains the first rebase and later cleanups, the assimp-clean branch contains a full rebase but may actually have a worse history.

Since assimp-2.0 now has a rewritten history it's important anybody who cloned it previously delete the old repo and clone again, otherwise you'll have problems with the history.

So, what to do from here?

1.) Use the original history (I have a local backup)
2.) Use the rebased/cleaned history in assimp-2.0 on GitHub
3.) Attempt another rebase
4.) Selectively pick assimp-related files or commits and apply them as patches on top of the latest master.

I think 2 may be the best overall.

[jK]

I don't know how you rebased it, but it seems something went wrong:

https://github.com/SpliFF/spring/compar ... its_bucket.

When done right, all those commits to master shouldn't be shown.

[SpliFF]

EDIT: Actually the commits you are referring to are the result of pulling master again AFTER the rebase and fixes. They should be there.

My understanding is rebase doesn't work like that. It takes all commits after the specified hash tag and shows them as a list to pick, edit or skip. The ones you pick are applied sequentially as patches on top of the working directory and end up having a different committer (SpliFF) and datestamp (yesterday). The list includes all commits resulting from later pulls, not just my own which means I am constantly presented with merge conflicts to resolve - 100's of them, and many that are not my commits (meaning I risk screwing up other commits). Even the simplest changes to history can lead to cascading conflicts.

I'm not saying I didn't make mistakes but you have to understand the problem facing me. This rebase technique is not, by itself, a perfect solution unless I can also isolate all commits related to up to three different merges over a 6 month time period and coherently and selectively organise them in a way that doesn't interfere with other peoples commits.

My second attempt at rebasing "assimp-clean" from further back didn't come to much. I spent about 3-4 hours doing merges as best I could but eventually after about 60-80 merges I gave up and aborted it. 80% of the merges weren't remotely related to my code and I really had no idea whose changes were correct.

[hoijui]

though all your explanation of what you did is really vague, it sounds like you did it totally wrong. what did you do with any release branch?? you should not have to touch them ever, they are strictly for releases only. you should also just use git rebase -i <SHA1-of-a-commit-in-current-branch-(assimp-1.0)>, and not rebase on master somehow. ... well i already explained how to do it in the other post. if you do it like that, and remove eg the java AI changes from the faulty (merge-)commit, which only concerns files that you never touched later on, there should be no conflicts. maybe you would have to revise merge-commits where you merged master back in, but at max it would mean, adding/removing files again, not solving conflicts inside files.
what you do with rebase -i, is just changing one commit in the past, which requires rewriting history after that. but in this case that rewriting should mostly consist only in recalculating the SHA-1's of the commits (which include the parents SHA1).

[SpliFF]

what you do with rebase -i, is just changing one commit in the past, which requires rewriting history after that. but in this case that rewriting should mostly consist only in recalculating the SHA-1's of the commits (which include the parents SHA1).

That explanation greatly oversimplifies what I'm seeing after I begin a rebase. First I'm presented with a huge list of commits that I understand represents every commit made after the hashtag.

Code: Select all

On branch assimp-clean
nothing to commit (working directory clean)
HEAD is now at 582c607 Merge branch 'master' of git://github.com/spring/spring into assimp-2.0

Rebasing off the parent commit of 
$ git rebase -i 721f326f1f891c354bff267ec6e0c28bd7918501

Code: Select all

pick f1a676f * fix wrong ASSERT_SIZE in VertexArray
pick 3210751 get rid of a warning [minor]
pick 4d36af9 also create meta engine flavor build targets [CMake] ... in addition to the install targets
pick 55a1f5c E323AI: improvements and fixes for NOTA & general stuff
pick b186f28 allow to parse unitsync API header more easily This only possibly makes sense when parsing with pre-pro$
pick a8ce7a0 small cleanup for in-source-builds (credits to abma) [CMake] [minor]
pick 386e226 remove SelectionEditor It has been integrated into SpringLobby and SpringSettings, and is now also cros$
pick 286cf76 * start cleaning up Path/
pick a529df8 * unify PathFinder::SquareState and PathEstimator::BlockInfo
pick 465fb73 * PFS: allow unsynced code to influence path-node cost calculations
pick 974e8eb * fix
...
# Rebase 721f326..582c607 onto 721f326
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.

This file has 1672 commits. What I don't know is which need to be picked, reworded, edited, squashed or lost. If I leave everything on pick then everything gets reapplied and the resulting conflict resolution takes hours. For example the first error:

Code: Select all

warning: too many files (created: 913 deleted: 785), skipping inexact rename detection
error: could not apply 39cd3e4... AI: Java: establish native generated source dir handling
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' and run 'git rebase --continue'
Could not apply 39cd3e4... AI: Java: establish native generated source dir handling

$ git status
# Not currently on any branch.
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:      AI/Interfaces/Java/CMakeLists.txt
#       both modified:      AI/Interfaces/Java/bin/java_wrappCallbackOO.awk                                          
#       both modified:      AI/Interfaces/Java/bin/jna_wrappCallback.awk                                             
#       both modified:      AI/Interfaces/Java/bin/jna_wrappCommands.awk                                             
#       both modified:      AI/Interfaces/Java/bin/jna_wrappEvents.awk                                               
#       both modified:      AI/SConscript                                                                            
#                                                                                                                    
no changes added to commit (use "git add" and/or "git commit -a")

So now I'm merging somebody else's commit! I have no idea which of these AI files should stay, go or merge. Even if I merge, "git add" and "git rebase --continue" I'll just be confronted by scores of similar conflicts before the process completes. If the merge involves my own commits I can resolve them in a few minutes usually but other peoples commits that much longer. In the end I don't even know if the result is any better than before the rebase.

So much parallel development has occurred in model and texture code between master and assimp that any change in an early commit raises unexpected conflicts later. Since the original problem occurred so far back in history the solution does not appear to be as simple as implied by hoijoi's comments.

I really don't know how to resolve this except by using the assimp-2.0 branch as-is, as it was, or as a series of new patches against an untainted master.

[hoijui]

:/
i tried to find out what the problem is by looking at history in gitk, but ...
there is like a hundred arrows of different colors, i can not grasp it. what i see though, is that where it first conflicts is right after some commits by zerver about Lua state splitting. it might be that the problems are caused by some git action we had at the time, as we did revert something which should not have been put into master yet, and i remember it having been ugly (git wise).

i would say, use your old history, and make that commit that removes all differences in your branch (compared to master) that should not be there, like the Java AI ones. that should be possible by simply copying stuff from master.
... looks like you already did that.