Development/Submodules

Working on core
If you are working on core only the submodules should track where they need to be based on the commit you are in in core. If, when you do git status, you see something like

you can rectify the situation by running

That will reset the submodule to the commit it should be on according to core's information, and git status after that should not contain any reference to submodules.

Working in submodules
The recommended way to get submodules is to simply use autogen options like  and. The mentioned options fetch translations and help respectively.

If you decide to manually clone a submodule, run this command after the clone is completed:

By default your submodule repository is in a state called 'detached HEAD'. This means that the checked-out commit -- which is the one that the super-project (core) needs -- is not associated with a local branch name.

Don't forget to add a correct pushurl for the   you are working on or you will not be able to commit.

If the working submodule is helpcontent2, you should set help in place of.

If you want to create a new change, create a new branch:

Edit the submodule's files and commit your changes inside the submodule directory.

Then push them to Gerrit from within the submodule directory:

On the gerrit side, when your patch is reviewed and submitted, gerrit will automatically create a commit on core to reflect the change in. so that everybody will see the change at their next ./g pull -r

Once your submodule patch is merged, you can delete 'my_branch':

By using the ./g script, you do not need to worry about git submodule update.

Note: if you are not pulling from gerrit.libreoffice.org, but from freedesktop for example, it may take a minute before a pull from core will get you the automatic commit created on core by gerrit. This is not a problem for anyone else because the commit on core is always _after_ the commit on the submodules, so anyone else who pulls will not have your submodule commit before core knows about it.

There are of course other workflows that one can use, and plenty of other situations one can drive oneself into. The advice is: stick to the one described here. If you want to be creative, good for you, but then do not whine, if you shoot yourself in the foot.

Missing Change-ID
If you are only cloning the submodules repo and gerrit complains about missing Change-Ids you can get the commit hook that adds the Change-ID by running this in the core directory:

After that use git commit --amend to update the commit msg and let git add the Change-ID.