How-To: Repair a broken submodule in your Chromium checkout

[AndrewH]

Hi all,

The other day, I accidentally did a rebase in one of the third party modules and ended up (through a series of unfortunate commands) totally breaking my local repository. Trying the "obvious" solution of "rm -rf"ing the entire directory and doing a "gclient sync" did not fix things, and I didn't have any luck finding a solution online. So I deleted my entire repo and started again. And then I broke it... again. ::sigh::

I did find what appears to be a working solution and I want to share it with the community. Someone with more git knowledge than me can hopefully clean this up a little bit, and then perhaps we can add it to the documentation to save people some trouble. Having to re-download the entire repo just to fix one module really hurts. Anyhow, here it is:

$ cd $CHROMIUM_REPO/src

$ export BROKEN_LIB=whatever_you_borked

# Blow away broken module

$ rm -rf third_party/$BROKEN_LIB

# This re-bootstraps the git config from DEPS, if I understand correctly.

$ git submodule init third_party/$BROKEN_LIB

# This makes sure that your repo URL is up to date, and maybe some other stuff.

$ git submodule sync third_party/$BROKEN_LIB

# Checks out the specific pinned revision specified in the DEPS. This will restore the module (clone its repo) if it has been deleted.

$ git submodule update third_party/$BROKEN_LIB

After this you want to do a "git status" in the module's base directory. You may see something like this:

$ cd third_party/$BROKEN_LIB

$ git status

# On branch master

# Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.

#   (use "git pull" to update your local branch)

#

# Changes not staged for commit:

#   (use "git add/rm <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

# deleted:    README.chromium

# deleted:    [whatever_you_borked].gyp

#

no changes added to commit (use "git add" and/or "git commit -a")

You need to restore those, of course.  E.g.:

$ git checkout -- README.chromium

$ git checkout -- $BROKEN_LIB.gyp

And voila: Submodule repaired. A lot faster than rebuilding your repo from scratch. I assume that there are lots of folks out there like myself who have never worked with submodules before, so hopefully this saves you all some time.

Regards,

Andrew Hayden

[Scott Graham]

This looks helpful to me. Could you find a place to add it to https://code.google.com/p/chromium/wiki/UsingGit ?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[Rachel Blum]

I might be missing what you mean by breaking, but if it's really just a rebase, doesn't the following do the trick?

cd $BROKEN_MODULE_DIR

git merge-base master origin/master

<prints a SHA of last common point between master and origin>

git reset --hard <SHA printed above>

gclient sync

Basically, instead of removing the entire repo, the above just removes everything that diverges from origin/master from that repo.

Also, if you want to restore a bunch of files, 'git checkout -- .' saves you typing filenames. Just make sure you really want to blow away everything under the cwd.

 - rachel

[Stefan Zager]

There is a sanctioned git-submodule-based workflow for chromium:

https://code.google.com/p/chromium/wiki/UsingGitSubmodules

It is also fine to run raw git-submodule commands, as you have done, but there is some essential boilerplate that you're missing if you haven't gone through the 'Getting Started' section of those docs.

Otherwise, what you have done LGTM, with a couple of observations:

- It should never be necessary to completely delete a submodule checkout to get to a sane state.  Worst case, you can look up the pinned revision of the submodule in src/.DEPS.git and run 'cd third_party/wurlitzer && git checkout --force <revision>'.

- If you're doing development of a submodule checkout inside your chromium checkout, the submodule flow is probably the only sane way to work.  The docs above detail how to keep the tools from messing up your submodule changes, but very briefly: 'git config submodule.third_party/wurlitzer.update none'.

Stefan

On Mon, May 13, 2013 at 1:56 AM, AndrewH <andrew...@google.com> wrote:

--

[Scott Hess]

I've been using git for Chromium development since it was just a bunch
of made-up stuff from Evan, and I have no idea how to parse what
you're saying, here. I'm sure I could figure it out, given sufficient
time, but honestly I'd rather have something like:
gclient sync --reset
which could act as the omnitool to just fix the heck out of everything.

[No, I'm not offering to write it. But I am annoyed that deleting a
directory and re-syncing is apparently no longer sufficient to fix
things. I've had to do that a number of times, and I _never_
intentionally do work in non-Chromium repos we pull in.]

-scott

[Stefan Zager]

On Mon, May 13, 2013 at 11:26 AM, Scott Hess <sh...@chromium.org> wrote:

I've been using git for Chromium development since it was just a bunch
of made-up stuff from Evan, and I have no idea how to parse what
you're saying, here.  I'm sure I could figure it out, given sufficient
time, but honestly I'd rather have something like:
  gclient sync --reset
which could act as the omnitool to just fix the heck out of everything.

I think the intent of gclient was to offer a tool that "just does everything for you."  Unfortunately, there's a trade-off with tools like that: when they work, everything is wonderful; but if you get into any kind of bad state -- and everyone does from time to time -- then "do everything for me" tools pretty much always bork, sometimes with disastrous results.

The submodule flow is deliberately designed NOT to be a "do everything for me" flow.  It has unambiguous appeal to power users and assorted control freaks.  For everyone else, I still think it can be a pleasant workflow, but you will have to expand your git comfort zone a bit.

[No, I'm not offering to write it.  But I am annoyed that deleting a
directory and re-syncing is apparently no longer sufficient to fix
things.  I've had to do that a number of times, and I _never_
intentionally do work in non-Chromium repos we pull in.]

Speaking only for the submodule flow: deleting a directory and running 'git crsync' will fix it, for sure, every time.