[Bf-committers] developer.blender.org status

Mon Nov 11 16:40:46 CET 2013

You can not avoid manual update of SHA since the nature of submodules.

Submodule always points to a specific SHA in a given repository, no way to
change it or affect on it. It's just given by git design.

Before git 1.8.2 you used to do:

git submodule add -b branch_name url
manually modify .gitmodules, adding branch = branch_name
git submodule update --remote

This was the only way to pull changes to submodule from a given repository.
If you skipped manual config edit latest SHA from master branch was used.

Since git 1.8.2 branch name is adding to .gitmodules automatically by git
submodule add command. So if you do:

git submodule add -b branch_name url
git submodule update --remote

then latest head from branch branch_name will be pulled.

Regardless to git version, if `git submodule update --remote` pulls new
HEAD from whatever branch/tag it is configured to point to then your parent
repository will end up in changed non-commited unstaged state. If you'll
run `git diff` you see change like:

-Subproject commit xxx
+Subproject commit yyy

Basically, if submodule is used as it is intended to, you'll do

git clone --recursive url
git remote update

This two commands will download latest repository and download that exact
SHA of submodule which parent repo is configured for.

The proposal was to use:

git clone --recursive url
git remote update --remote

This will download latest repository and latest submodule. Now, to avoid
changes in submodule SHA being considered as uncommited changes, we'll use
ignore=all.

This would make it so everyone i able to use latest blender and latest
addons/translations without cluttering development workflow of addons (you
could still commit changes to addons from a submodule) and will prevent git
history from endless manual SHA update commits.

Now, the only issue is, if you do regular `git clone --recursive url && git
remote update` you wouldn't have latest addons checked out, because bender
points to some older SHA in addons repo.

This does not mean anything to those who simply use proposed commands, but
some git nerds might consider this hackish. It is only important to make
sure release tags points to a specific tag in submodules. For general
development we might just skip updating SHA stored in parent repo and tell
everyone to use `git remote update --remote`.

On Mon, Nov 11, 2013 at 9:20 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> 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 <dfelinto at gmail.com>
> 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 <sergey.vfx at gmail.com>
> >
> >> 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 <
> >> brechtvanlommel at pandora.be> 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
> >> > <brechtvanlommel at pandora.be> 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
> >> > > <brechtvanlommel at pandora.be> 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
> >> > Bf-committers at blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >>
> >>
> >>
> >> --
> >> With best regards, Sergey Sharybin
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
With best regards, Sergey Sharybin