Running 'make gitconfig' will add two aliases to your coreboot git configuration: git sup and git sup-destroy.
'git sup' (submodule update) updates the submodules to the latest versions, but leaves any locally modified files. 'git sup-destroy' will remove the current submodules and re-initialize them. This deletes any local changes.
Martin
On Tue, Mar 28, 2017 at 6:49 PM, Paul Menzel via coreboot coreboot@coreboot.org wrote:
Dear coreboot folks,
Often I am running into problems, when updating the tree.
Normally I do `git pull --rebase` to update my branch, and rebase my changes on top of the upstream master branch. But if something in the submodules, under `3rdparty` changes, I get a dirty tree. The same is true, when bisecting or checking out a very old commit.
Just today, after running `git pull --rebase`
$ git show commit 3c645391c0b7272f66d842bed454c29ceb9ce0bf Author: Marshall Dawson <marshalldawson3rd@gmail.com> Date: Sat Mar 25 17:49:45 2017 -0600 3rdparty/blobs: Update for AMD Stoney Ridge Add the binaryPI file for the FT4 package and add SMU firmware to be consumed by fanless OPNs. Change-Id: I1c9b5ded6b494fac1553cc2ec7756a7a47386ecf Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/18988 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> diff --git a/3rdparty/blobs b/3rdparty/blobs index 8090bdd598..b5e64d7cf4 160000 --- a/3rdparty/blobs +++ b/3rdparty/blobs @@ -1 +1 @@ -Subproject commit 8090bdd59853599e469b7503ea473ca12e8c681b +Subproject commit b5e64d7cf4984dcf8e284c1878d943e88d53de5d $ git diff diff --git a/3rdparty/blobs b/3rdparty/blobs index b5e64d7cf4..8090bdd598 160000 --- a/3rdparty/blobs +++ b/3rdparty/blobs @@ -1 +1 @@ -Subproject commit b5e64d7cf4984dcf8e284c1878d943e88d53de5d +Subproject commit 8090bdd59853599e469b7503ea473ca12e8c681b
In this situation, I am manually changing the directory under `3rdparty/`, in this case `blobs`, and do `git reset --hard <hash>` there to get a clean state.
Do you know of tricks that the submodules are, by default, always in the state of the commits noted in the coreboot branch?
Do you have other hints or suggestions on how to work with git submodules?
Thanks,
Paul
coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot