Read through the part about git 1.8.2 twice but the description is still fuzzy to me,
>From reading this it seems like we can use submodules to track master and not have to do any manual updates. http://stackoverflow.com/questions/9189575/git-submodule-tracking-latest I'm really against having to manually update some SHA1 just so addons are up to date if it can be at all helped. When developing FBX import for example - I could ask a user if their build was <2 days old and be sure they had a fixed version. For translations its less of an issue because you dont experience bugs when its a little behind, but getting complaints on bugs fixed for a week already is bad. if something is broken but nobody notices for a week its equally bad. On Tue, Nov 12, 2013 at 12:32 AM, Dalai Felinto <[email protected]> wrote: >> - Manually update submodule's SHA regularly, like once a week. > I think this is reasonable, and how we do for translations already. > > Apart from that I think it's a nice workflow. > > Cheers, > Dalai > -- > blendernetwork.org/dalai-felinto > www.dalaifelinto.com > > > 2013/11/11 Sergey Sharybin <[email protected]> > >> Notes about git submodules. >> >> Intention is to use git submodules as a replacement for svn:externals which >> we used for "integrating" translations and addons into main tree. >> >> Tricky part about submodules is that submodules in git are poiting to a >> specific SHA revision of external repository. So if you want to use latest >> addons you'll need to update blender's repository to use latest SHA >> revision from from adons repository. >> >> This is what we'll want for release tags. Basically, we'll create tag in >> addons/translations repositories and make release tag in blender repository >> track submodules with given tag name. >> >> This is done by adding/modifying "branch" setting in .submodules file. >> >> Now, how to deal with regular development. It is possible to update >> submodules to their latest SHA: >> >> git submodule update --remote >> >> --remote means submodules will be updated to latest HEAD of an external >> repo instead of hash stored in parent repository. >> >> Bad thing about this is that this marks parent repository as changed with >> uncommited changes (because submodule update modifies SHA of submodule >> stored in parent repository). We don't want such changes to be commited by >> an accident, and seems there's a workaround for this. >> >> If you add ignore=all to .gitmodules, then parent repository will ignore >> all the changes made to submodule, ingcluding modifying/adding files there >> or updating HEAD of submodule. This way doing `git submodule update >> --remote` will pull all the changes from submodule's repository but >> wouldn't mark parent repository as changes. Roughly speaking, `git commit >> -a` invoked from parent repo will say "no changes to commit" which is nice. >> >> Fortunately, if you make changes to submodule itself (like, fix bug in an >> addon) you still able to commit changes to addons repository directly from >> submodule. To do this you just cd to addons submodule and do regular git >> commit followed by push. >> >> As a sideeffect of such approach, you owuldn't be able to commit changes >> made to submodule together with changes made to parent repository. But in >> fact, this is also rather good. Generally speaking, you would NOT want to >> commit chnages to submodule and parent repo with the same commit and will >> want to commit changes to submodule first and then update parent >> repository. Otherwise you'll run into all sorts of possible issues. >> >> So, the proposal is: >> - Attach blender-addons, blender-addons-contrib and blender-translations to >> main git's tree as a submodule (`git submodule add git:// >> git.blender.org/blender-addons/ ./release/scripts/addons` and so on) >> - Add ignore=all to .gitsubmodules. This will be stored in blender's >> repository, so you only need to do this once. No need for all the >> develoeprs to modify their .gitsubmodules. >> - To checkout checkout the repository: `git clone --recursive git:// >> git.blender.org/blender`. This will also download all the submodules. You >> would need to `run git submodule update --remote` after this manually, coz >> submodule's SHA might not be updated in blender repo yet. >> - To update the checkout: `git pull && git submodules update --remote`. >> This will pull all the changes made to blender itself and changes made to >> all the external repos. This will NOT add changes from submodules to parent >> repository, >> - Commits from blender repo would NOT include changes made to addons >> - To commit changes made to addons you simply cd to >> ./release/scripts/addons and do git commit and push from there >> >> There's one weak aspect still, which is it's not clear which SHA submodules >> should point to. This doesn't affect workflow proposed above, but would be >> nice to have some trict policy about when and how to update submodule's >> SHA. Couple of ways: >> - Submodule's SHA will point to previous release's tag during current >> development cycle. All the changes made to those repos will be pulled with >> `git remote update --remote`, so not a bit isue wor dveelopers/regular >> users. >> - Update submodules's SHA with commit hook of external repositories. This >> will clutter our main repo's history with bunch of "update submodule SHA" >> commits. >> - Manually update submodule's SHA regularly, like once a week. >> >> And one last note about changes made to git 1.8.2 about tracking tip of a >> branch. Those change only makes ti so `git remore add --branch` will add >> branch=xxx to .gitsubmodules, which would make git remote --update follow >> the branch specified to git submodule add command. You might do the same >> change manually and there's no need to use brand-new git. And this is only >> needed when one initialized submodules to blender repo, after this it >> doesn't matter whether you use git 1.8.2 r older one. >> >> >> On Sat, Nov 9, 2013 at 12:06 AM, Brecht Van Lommel < >> [email protected]> wrote: >> >> > Latest Update: >> > >> > * Contrib Addons will be in a separate repository from Release Addons >> > * Translations repository will contain only .po files, with binary .mo >> > files generated as part of build >> > >> > * Documentation is being written: >> > >> > >> http://wiki.blender.org/index.php/Dev:Ref/Proposals/Migration_to_Git_Phabricator#Documentation >> > http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator >> > http://wiki.blender.org/index.php/Dev:Doc/Tools/Git >> > http://wiki.blender.org/index.php/Dev:Doc/Tools/Code_Review >> > http://wiki.blender.org/index.php/Dev:Doc/Process/Addons >> > >> > * We aim for migration somewhere next week, perhaps wednesday >> > >> > >> > On Thu, Nov 7, 2013 at 7:33 PM, Brecht Van Lommel >> > <[email protected]> wrote: >> > > The bf-extensions trackers have been migrated for testing as well now. >> > > >> > > >> > >> http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator/Migration#Addons >> > > http://developer.blender.org/project/view/3/ >> > > >> > > >> > > On projects.blender.org there is an bf-extensions project with various >> > > trackers that not only store bug reports, but also an entry for each >> > > addon. This is confusing however, and there is already a wiki page for >> > > each addon with this information duplicated. We will simplify the >> > > process as follows: >> > > >> > > * There is an Addons project >> > > * The authoritative list of addons and their information is on the >> > > wiki (a page here was already required) >> > > * We will have Submit an Addon and Report a Bug forms for the Addons >> > > project, similar to regular Blender bug reporting and patch submission >> > > * Based on the wiki page information, bug reports can be assigned to >> > > the relevant addon maintainer when they are triaged >> > > >> > > The only remaining open reports are: >> > > >> > > * Bugs reported to the tracker >> > > * Patches in Py Scripts Upload (so, not committed to svn) >> > > * Everything else is closed as archived >> > > >> > > The addon/extensions workflow documentation will be updated in the wiki >> > later. >> > > >> > > >> > > Feedback on this is welcome. >> > > >> > > Thanks, >> > > Brecht. >> > > >> > > >> > > >> > > On Wed, Nov 6, 2013 at 6:46 PM, Brecht Van Lommel >> > > <[email protected]> wrote: >> > >> Hi all, >> > >> >> > >> As you may have noticed, we now have a test version of phabricator and >> > >> git running: >> > >> http://developer.blender.org/ >> > >> http://developer.blender.org/diffusion/B/ >> > >> >> > >> These are both test versions and work is ongoing, so don't base any >> > >> actual work on them yet. You will have to redownload the git repo and >> > >> recreate any data on developer.blender.org when the final thing goes >> > >> live. As we are planning to switch to them next week, now seems a good >> > >> time to get some feedback from other developers. >> > >> >> > >> Migration status: >> > >> >> http://wiki.blender.org/index.php/Dev:Ref/Migration_to_Git_Phabricator >> > >> Phabricator docs: >> > http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator >> > >> >> > >> You can basically go to developer.blender.org and check things out, >> > >> your username and password from projects.blender.org will still work. >> > >> >> > >> There's still a bunch of incomplete things that we are working on, >> > mainly: >> > >> * Addon and translation repositories >> > >> * Patch / code review submission clarity >> > >> * Migrating bf-extensions trackers >> > >> * Documentation for git, arc, building, .. >> > >> >> > >> Feedback is welcome! >> > >> >> > >> Thanks, >> > >> Brecht. >> > _______________________________________________ >> > Bf-committers mailing list >> > [email protected] >> > http://lists.blender.org/mailman/listinfo/bf-committers >> > >> >> >> >> -- >> With best regards, Sergey Sharybin >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
