Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
557 changed files
with
4 additions
and
199,801 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Submodule assimp
added at
350487
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YES WE CAN!
no really... why?
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hoijui: bit easier to upgrade assimp this way
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, actual i wanted to update assimp...
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that makes no sense; it is not easier to update.
submodules should be used for strictly optional stuff only.
the normal user wanting to compile spring from git should not have to use submodules. it would only complicate stuff (also for us, when we have to tell everyone and so on).
even if assimp is still optional (if it is, i do not know) it surely will/should not be in the long run, or say, as soon as games start to use formats supported by assimp.
submodularizing stuff also gives merge conflicts, always, so please thing 3 times next time you want to submodularize something, and maybe discuss it first.
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is easier to update assimp: now you can exactly see what was modified. you can also make pull requests to merge changes upstream, before you couldn't.
both ways have drawbacks:
i see assimp as an external module, even if its currently not optional (but it shouldn't be hard to make it optional...)
we can't maintain assimp and it still contains many bugs, so i think its better to have it as git module. this also marks it as "please don't touch it, change it upstream"
(even if this change is really bad, "reverting" is very easy. most time i spent for this, was to make the newest version of assimp work)
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should not be optional. that it is buggy is no reason to make it optional.
the AIs are fully optional, but as said, as soon as games will start to use assimp supported formats - and that is what we ultimately want and should prepare for now already - assimp will be anything else but optional.
when we make changes to assimp ourselfs, merging will not result in any more conflicts whether it is a submodule or not. the only difference is, that we would have to execute one or two very simple shell commands more (like
rm -Rf rts/lib/assimp/*
).you treat a pro of very minor increased comfort for devs changeing assimp (which is a thing happening seldomly), against less comfort for anyone compiling spring, including main devs (i hardly ever use git submodule update, as i usually have local changes in the AIs, so i would run into conflict solving whenever rebasing on the main repo).
in short, the choice of whether to use a submodule or not does not depend on whether it exists as git repo, but purely whether it is optional or not.
assimp should not be a submodule.
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"merging will not result in any more conflicts whether it is a submodule or not"
hu? how will you merge, when its not a submodule? do a full directory-tree comparison?
(btw this would make it optional: http://pastebin.com/fdnazpkh only a few cmake changes would be still required...)
hm, i think you're right, but i dislike to do a ~300k code-commit again. talk about it on monday with others?
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah right, making a revert commit would not be optimal (still produces merge conflicts, maybe), i am in favor of force-push removing this change (cherry picking the commits after it).
maybe everyone should keep local changes local until we settled this (at the latest, monday evening) ... if you see this comment.
how to merge:
of course we would not have assimps own development history this way, but we do not need that. we could create an additional file in step 4.b, containing the assimp SHA1 or something, for easy reference.
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good points hoijui.
I should have considered it a bit longer before saying it's fine with me to abma :-)
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I am skeptical of submodules here, too.
On the other hand, I see the simplification of updating.
Isn't there a way to force submodule checkouts/syncs in "git clone" & "git pull"?
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, there is no way to do that purely from the repos side.
btw, the "how to merge" instructions i gave above are wrong. they would always overwrite our own changes to assimp.
we need an assimpUpstream branch, and then the procedure works like this:
b) [optional] put the output of assimps "git describe" into rts/lib/assimp/VERSION or the like
from now on, always update assimp version in the assimpUpstream branch.
the same technique should/could be done for rts/lib/lua, i guess (so we could profit from gits merge magic there too).
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if it is not a submodule, we could use the spring/assimp repository to maintain our changes and easily merge upstream / send pull requests as Spring team, and then instead of a submodule update do the
rm -rf rts/lib/assimp
&git clone git@github.com:spring/assimp.git
etc. in the Spring repository.That way our changes to assimp remain clear as a patch set in spring/assimp/master (as long as we rebase & force push when we update, instead of doing a real merge), there aren't any of the disadvantages of a submodule, and updating assimp can be done more easily (by having git rebase handle any merge conflicts per commit, etc.)
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh i see! true .. even better that! :-)
i don't get why we would need to force push anywhere in this scenario, but maybe you can explain this next time in chat.
i will possibly not be around in tomorrows meeting (Monday 10. July 2011).
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hoijui, to keep the spring changes from drowning under hundreds of new commits in spring/assimp I think we'll want to git pull --rebase when merging upstream. And that implies a force push will be needed to push that update.
1bb82ca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahhh i see, thanks for explanation. :-)
makes sense.