PSA: changes to src.git, redux

[Stefan Zager]

I'm going to be rolling out the previously-announced changes to src.git this afternoon, shortly.  Friday afternoon turns out to be a pretty good time, because if developers run into trouble, they tend to be quite willing to pack in early and start drinking.

A brief recap:

- When this change takes effect, the HEAD revision of git.chromium.org/chromium/src.git will be a merge commit.

- To see the svn-only commit history, run `git log HEAD^`

- The repository will have registered (invisible) submodules and a (visible) .gitmodules file.

- dcommit will work this time!

Thanks,

Stefan

[Stefan Zager]

It has just been pointed out to me that the M21 branch is on Monday, so developers may be racing a deadline right now.

So, nix this change for this afternoon, and I'm going to start drinking now.

Thanks,

Stefan

[Stefan Zager]

Now that we have cleared the M21 hurdle, I'm going to roll out this change today.

Thanks,

Stefan

[Anthony LaForge]

Hey Stefan,

Depending on stability numbers, we may have to shift the branch point for 21.  Karen will send out a note when M21 we have finalized the branch and it is open.  

Big thank you for holding off until we've established a branch point, I very much appreciate it.

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

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

[John Sheu]

I'm getting a git-status (probably git submodule-related) that now is preventing me from doing a 'git pull'.  I'm not entirely sure what to do with this.

-John Sheu

sheu@longjacket /usr/local/google/home/sheu/chromite/chromeos/chromium/src $ git status
# On branch mali_egl
# Your branch and 'cros/master' have diverged,
# and have 1 and 8 different commit(s) each, respectively.
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#   (commit or discard the untracked or modified content in submodules)
#
# modified:   breakpad/src (new commits)
# modified:   googleurl (new commits)
# modified:   native_client (new commits)
# modified:   seccompsandbox (new commits)
# modified:   testing/gmock (new commits)
# modified:   testing/gtest (new commits)
# modified:   third_party/WebKit (new commits, modified content)
# modified:   third_party/angle (new commits)
# modified:   third_party/bidichecker (new commits)
# modified:   third_party/ffmpeg (untracked content)
# modified:   third_party/flac (untracked content)
# modified:   third_party/hunspell (untracked content)
# modified:   third_party/icu (untracked content)
# modified:   third_party/jsoncpp/source/include (new commits)
# modified:   third_party/jsoncpp/source/src/lib_json (new commits)
# modified:   third_party/leveldatabase/src (new commits)
# modified:   third_party/libjpeg_turbo (untracked content)
# modified:   third_party/libphonenumber/src/phonenumbers (new commits)
# modified:   third_party/libphonenumber/src/resources (new commits)
# modified:   third_party/libphonenumber/src/test (new commits)
# modified:   third_party/libsrtp (new commits, untracked content)
# modified:   third_party/libvpx (new commits, untracked content)
# modified:   third_party/libyuv (new commits, untracked content)
# modified:   third_party/mozc/chrome/chromeos/renderer (new commits, untracked content)
# modified:   third_party/mozc/session (new commits, untracked content)
# modified:   third_party/openssl (untracked content)
# modified:   third_party/ots (new commits, untracked content)
# modified:   third_party/pyftpdlib/src (new commits)
# modified:   third_party/pymox/src (new commits)
# modified:   third_party/skia/src (new commits)
# modified:   third_party/smhasher/src (new commits)
# modified:   third_party/snappy/src (new commits)
# modified:   third_party/speex (untracked content)
# modified:   third_party/trace-viewer (new commits)
# modified:   third_party/undoview (modified content, untracked content)
# modified:   third_party/v8-i18n (untracked content)
# modified:   third_party/webdriver/pylib (new commits)
# modified:   third_party/webpagereplay (new commits)
# modified:   third_party/webrtc (new commits, untracked content)
# modified:   tools/deps2git (new commits)
# modified:   tools/grit (untracked content)
# modified:   tools/gyp (new commits)
# modified:   v8 (new commits)
#
no changes added to commit (use "git add" and/or "git commit -a")

[Stefan Zager]

On Wed, Jun 20, 2012 at 12:13 PM, John Sheu <sh...@chromium.org> wrote:
> I'm getting a git-status (probably git submodule-related) that now is
> preventing me from doing a 'git pull'.  I'm not entirely sure what to do
> with this.

Please try running this command, and let me know if it fixes the problem:

$ git submodule foreach 'git config -f $toplevel/.git/config
submodule.$name.ignore all'

Thanks,

Stefan

[John Sheu]

Before I do that -- is this a hide-the-problem solution, or an actual solution?  I'd like not to get my tree in an undefined state :-)

Thanks,
-John Sheu

[Stefan Zager]

On Wed, Jun 20, 2012 at 12:35 PM, John Sheu <sh...@chromium.org> wrote:
> Before I do that -- is this a hide-the-problem solution, or an actual
> solution?  I'd like not to get my tree in an undefined state :-)

It's an actual solution. gclient is *supposed* to be running that
command for you. I'm still not sure why it's not working for
everyone, but you might check to see if your depot_tools checkout is
stale.

Stefan

[John Sheu]

I updated depot_tools, did a repo sync, and still had a problem.

Then I ran your command line once, then the problem went away.  I guess that's the solution then.

Thanks,
-John Sheu

[Daniel Cheng]

I'm seeing a similar variation of this:

# On branch invalidation-state-tracker

# Your branch is ahead of 'origin/master' by 7 commits.

#

# Changes not staged for commit:

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

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

#   (commit or discard the untracked or modified content in submodules)

#

#       modified:   seccompsandbox (untracked content)

#       modified:   third_party/WebKit (new commits)

#       modified:   third_party/angle (untracked content)

#       modified:   third_party/ffmpeg (untracked content)

<snip>

Running the snippet you posted does fix it, but it'd be nice to figure out why this bit isn't working automagically. if it helps narrow it down, I run an unmanaged gclient checkout, and I manage third_party/WebKit myself as well.

Daniel

--

[Daniel Cheng]

Also, I see a bunch of warnings when I try to git cl dcommit:

warning: unable to rmdir third_party/xdg-utils: Directory not empty

warning: unable to rmdir third_party/yasm/source/patched-yasm: Directory not empty

warning: unable to rmdir tools/deps2git: Directory not empty

warning: unable to rmdir tools/grit: Directory not empty

warning: unable to rmdir tools/gyp: Directory not empty

warning: unable to rmdir tools/page_cycler/acid3: Directory not empty

warning: unable to rmdir v8: Directory not empty

It still seems to work though...

Daniel

[Avi Drissman]

What I'm doing is avoiding ever doing:

git rebase origin

and am sticking to

git rebase origin^

to stay off the gitdeps entries.

Unfortunately, GitX doesn't like the topology and yields the picture:

This is going to get unpretty quickly. Fortunately it's just the display.

Avi

[Stefan Zager]

On Wed, Jun 20, 2012 at 1:44 PM, Avi Drissman <a...@chromium.org> wrote:

What I'm doing is avoiding ever doing:

git rebase origin

and am sticking to

git rebase origin^

to stay off the gitdeps entries.

Unfortunately, GitX doesn't like the topology and yields the picture:

Rebasing off origin^ should be fine for now; `git cl dcommit` effectively does that, anyway.

For most query-type operations (including graphical views of the tree), you'll want to use master^ or origin^ anyways, to get the svn-only view of changes.  Alternately, you can use the --no-merges option to various git tools (not sure about GitX; maybe try it and report back).

Stefan

[Stefan Zager]

To clarify, because I think more people are running afoul of this: the
above command *must* be run in your gclient-based checkout. If you
run `gclient sync`, it *should* be done automagically for you.
Otherwise, you can run the command directly.

There may still be circumstances (e.g., when switching to a new
branch) when git spews out a bunch of warnings like this:

warning: unable to rmdir breakpad/src: Directory not empty

Those warnings may be safely ignored. I'm looking into ways to suppress them.

Thanks,

Stefan

[Scott Hess]

Is there any possibility that this would result in things like
git-diff, git-status, git-commit, etc, becoming much slower? Because
these things have gotten a lot slower for me very recently (today or
yesterday afternoon or something on that order). This is on OSX.
I'll be poking other things to see what might be up.

-scott

On Tue, Jun 19, 2012 at 11:03 AM, Stefan Zager <sza...@chromium.org> wrote:

[Stefan Zager]

On Wed, Jun 20, 2012 at 3:39 PM, Scott Hess <sh...@chromium.org> wrote:
> Is there any possibility that this would result in things like
> git-diff, git-status, git-commit, etc, becoming much slower?  Because
> these things have gotten a lot slower for me very recently (today or
> yesterday afternoon or something on that order).  This is on OSX.
> I'll be poking other things to see what might be up.

If you don't have the appropriate 'submodule.*.ignore' entries in your
.git/config, then git-status and related commands will *definitely* be
much slower. If you *do* have the config entries, and it's still
slow, I'd like to know about it.

Thanks,

Stefan

[Scott Hess]

I've got a billion entries like this in .git/config:

[submodule "v8"]
ignore = all

I ran your suggested command-line without checking that file first, so
I don't know if they were there from a previous gclient sync or not.

Just ran 'git commit -a' on a client with no changes, and stopped
counting at 30s, still hasn't brought up my editor. Oooh, just
finished, so 30s plus typing that previous line, call it 60s. Only
one untracked file (a logfile). I use unmanaged in gclient.

-scott

[Stefan Zager]

On Wed, Jun 20, 2012 at 3:51 PM, Scott Hess <sh...@chromium.org> wrote:
> I've got a billion entries like this in .git/config:
>
> [submodule "v8"]
>    ignore = all
>
> I ran your suggested command-line without checking that file first, so
> I don't know if they were there from a previous gclient sync or not.
>
> Just ran 'git commit -a' on a client with no changes, and stopped
> counting at 30s, still hasn't brought up my editor.  Oooh, just
> finished, so 30s plus typing that previous line, call it 60s.  Only
> one untracked file (a logfile).  I use unmanaged in gclient.

`git commit -a` might be broken now. I didn't think people actually did that :)

Let me dig a little.

Stefan

[Eric Uhrhane]

One data point: I use it all the time.

> Let me dig a little.
>
> Stefan
>

[Thiago Farina]

Why there was this change to submodule without describing how the workflow should be? This is pretty frustrating and I'm unable to commit right now.

About to commit; enter to confirm.

warning: unable to rmdir breakpad/src: Directory not empty

warning: unable to rmdir chrome/browser/resources/software_rendering_list: Directory not empty

warning: unable to rmdir chrome/test/data/extensions/api_test/permissions/nacl_enabled/bin: Directory not empty

warning: unable to rmdir chrome/test/data/perf/canvas_bench: Directory not empty

warning: unable to rmdir chrome/test/data/perf/frame_rate/content: Directory not empty

warning: unable to rmdir googleurl: Directory not empty

warning: unable to rmdir native_client: Directory not empty

warning: unable to rmdir native_client_sdk/src/site_scons: Directory not empty

warning: unable to rmdir rlz: Directory not empty

warning: unable to rmdir sdch/open-vcdiff: Directory not empty

warning: unable to rmdir seccompsandbox: Directory not empty

warning: unable to rmdir testing/gmock: Directory not empty

warning: unable to rmdir testing/gtest: Directory not empty

warning: unable to rmdir third_party/angle: Directory not empty

warning: unable to rmdir third_party/bidichecker: Directory not empty

warning: unable to rmdir third_party/cacheinvalidation/files/src/google: Directory not empty

warning: unable to rmdir third_party/cygwin: Directory not empty

warning: unable to rmdir third_party/ffmpeg: Directory not empty

warning: unable to rmdir third_party/flac: Directory not empty

warning: unable to rmdir third_party/gnu_binutils: Directory not empty

warning: unable to rmdir third_party/hunspell: Directory not empty

warning: unable to rmdir third_party/hunspell_dictionaries: Directory not empty

warning: unable to rmdir third_party/icu: Directory not empty

warning: unable to rmdir third_party/jsoncpp/source/include: Directory not empty

warning: unable to rmdir third_party/jsoncpp/source/src/lib_json: Directory not empty

warning: unable to rmdir third_party/leveldatabase/src: Directory not empty

warning: unable to rmdir third_party/libexif/sources: Directory not empty

warning: unable to rmdir third_party/libjingle/source: Directory not empty

warning: unable to rmdir third_party/libjpeg_turbo: Directory not empty

warning: unable to rmdir third_party/libphonenumber/src/phonenumbers: Directory not empty

warning: unable to rmdir third_party/libphonenumber/src/resources: Directory not empty

warning: unable to rmdir third_party/libphonenumber/src/test: Directory not empty

warning: unable to rmdir third_party/libsrtp: Directory not empty

warning: unable to rmdir third_party/libvpx: Directory not empty

warning: unable to rmdir third_party/libyuv: Directory not empty

warning: unable to rmdir third_party/lighttpd: Directory not empty

warning: unable to rmdir third_party/mingw-w64/mingw/bin: Directory not empty

warning: unable to rmdir third_party/mozc/chrome/chromeos/renderer: Directory not empty

warning: unable to rmdir third_party/mozc/session: Directory not empty

warning: unable to rmdir third_party/nacl_sdk_binaries: Directory not empty

warning: unable to rmdir third_party/nss: Directory not empty

warning: unable to rmdir third_party/ots: Directory not empty

warning: unable to rmdir third_party/pefile: Directory not empty

warning: unable to rmdir third_party/psyco_win32: Directory not empty

warning: unable to rmdir third_party/pyftpdlib/src: Directory not empty

warning: unable to rmdir third_party/pylib: Directory not empty

warning: unable to rmdir third_party/pymox/src: Directory not empty

warning: unable to rmdir third_party/python_26: Directory not empty

warning: unable to rmdir third_party/safe_browsing/testing: Directory not empty

warning: unable to rmdir third_party/scons-2.0.1: Directory not empty

warning: unable to rmdir third_party/sfntly/cpp/src: Directory not empty

warning: unable to rmdir third_party/skia/include: Directory not empty

warning: unable to rmdir third_party/skia/src: Directory not empty

warning: unable to rmdir third_party/smhasher/src: Directory not empty

warning: unable to rmdir third_party/snappy/src: Directory not empty

warning: unable to rmdir third_party/speex: Directory not empty

warning: unable to rmdir third_party/swig/Lib: Directory not empty

warning: unable to rmdir third_party/swig/win: Directory not empty

warning: unable to rmdir third_party/syzygy/binaries: Directory not empty

warning: unable to rmdir third_party/trace-viewer: Directory not empty

warning: unable to rmdir third_party/undoview: Directory not empty

warning: unable to rmdir third_party/v8-i18n: Directory not empty

warning: unable to rmdir third_party/webdriver/pylib: Directory not empty

warning: unable to rmdir third_party/webgl_conformance: Directory not empty

warning: unable to rmdir third_party/webpagereplay: Directory not empty

warning: unable to rmdir third_party/webrtc: Directory not empty

warning: unable to rmdir third_party/xulrunner-sdk: Directory not empty

warning: unable to rmdir third_party/yasm/binaries: Directory not empty

warning: unable to rmdir third_party/yasm/source/patched-yasm: Directory not empty

warning: unable to rmdir tools/deps2git: Directory not empty

warning: unable to rmdir tools/grit: Directory not empty

warning: unable to rmdir tools/gyp: Directory not empty

warning: unable to rmdir tools/page_cycler/acid3: Directory not empty

warning: unable to rmdir v8: Directory not empty

Switched to branch 'git-cl-cherry-pick'

error: could not apply bfd6b3b... browser: Add ExternalTabContainer interface.

hint: after resolving the conflicts, mark the corrected paths

hint: with 'git add <paths>' or 'git rm <paths>'

hint: and commit the result with 'git commit'

Command "git cherry-pick bfd6b3b1a4b43a703b802db0ed3775403990b874" failed.

error: you need to resolve your current index first

Command "git checkout -q external-tab-container-interface" failed.

third_party/libsrtp: needs merge

third_party/lighttpd: needs merge

[Scott Hess]

On Wed, Jun 20, 2012 at 4:25 PM, dominic <domi...@google.com> wrote:

> On Wed, Jun 20, 2012 at 4:23 PM, Eric Uhrhane <er...@chromium.org> wrote:
>> On Wed, Jun 20, 2012 at 4:17 PM, Stefan Zager <sza...@google.com> wrote:
>> > On Wed, Jun 20, 2012 at 3:51 PM, Scott Hess <sh...@chromium.org> wrote:
>> >> I've got a billion entries like this in .git/config:
>> >>
>> >> [submodule "v8"]
>> >>    ignore = all
>> >>
>> >> I ran your suggested command-line without checking that file first, so
>> >> I don't know if they were there from a previous gclient sync or not.
>> >>
>> >> Just ran 'git commit -a' on a client with no changes, and stopped
>> >> counting at 30s, still hasn't brought up my editor.  Oooh, just
>> >> finished, so 30s plus typing that previous line, call it 60s.  Only
>> >> one untracked file (a logfile).  I use unmanaged in gclient.
>> >
>> > `git commit -a` might be broken now.  I didn't think people actually did
>> > that :)
>>
>> One data point: I use it all the time.
>

> +1

I'm still trying to figure out how else anyone would commit :-).

-scott

[Stefan Zager]

On Wed, Jun 20, 2012 at 4:25 PM, Thiago Farina <tfa...@chromium.org> wrote:
> Why there was this change to submodule without describing how the workflow
> should be? This is pretty frustrating and I'm unable to commit right now.

The difficulty with a change like this is that no two git developers
do things the same. So, anticipating all possible complications is
nigh impossible.

A simple workaround is the one that avi discovered previously: root
your branches at origin/master^. I will continue to whack moles, and
keep you abreast.

Thanks,

Stefan

[Rachel Blum]

Is there any chance to roll this back?

It still seems to have quite a few issues. For me, currently:

* git commit -a is essentially "wait forever"

* git checkout to older branches gives lots of "could not rmdir" warnings

* I seem to have quite a few untracked changes

* I lost issues associated with some branches (git cl issue gives none for branches that I uploaded CLs from)

* Rooting my branches at origin/master^ is annoying at least

(Yes, I can work around all of those, but it's kind of painful)

Rachel

Stefan

[Szymon Jakubczak]

My current gripe is that after git rebase master, git diff master shows:

index 522a3c6..d5695c2 160000
--- a/chrome/browser/resources/software_rendering_list
+++ b/chrome/browser/resources/software_rendering_list
@@ -1 +1 @@
-Subproject commit 522a3c660e35972b07350e05d50b5de9439b05df
+Subproject commit d5695c2e38a22f326a68919e0fe3df69057e21f1

and similar diff for:
chrome/tools/test/reference_build/chrome_linux
third_party/WebKit
third_party/v8-i18n

Consequently, git cl upload picks those up. Any clue how to get rid of
those changes?

[Scott Hess]

Actually... git commit a/specific/file also seems to take forever.
git commit --no-status makes it much faster, but doesn't help -a much.

-scott

[Jeffrey Yasskin]

On Wed, Jun 20, 2012 at 3:51 PM, Scott Hess <sh...@chromium.org> wrote:
> I've got a billion entries like this in .git/config:
>
> [submodule "v8"]
>    ignore = all
>
> I ran your suggested command-line without checking that file first, so
> I don't know if they were there from a previous gclient sync or not.
>
> Just ran 'git commit -a' on a client with no changes, and stopped
> counting at 30s, still hasn't brought up my editor.  Oooh, just
> finished, so 30s plus typing that previous line, call it 60s.  Only
> one untracked file (a logfile).  I use unmanaged in gclient.

`git commit -a --amend` just worked fine for me. I do *not* use
'unmanaged' in gclient.

[Antoine Labour]

Why don't we run this experiment on a different upstream branch for now, where users who want to opt in can just choose to use, say, origin/master-submodules instead of origin/master, so that you can gather the data and fix the tools?

Messing around with the upstream repository that 100s of developer use and rushing to fix bugs introduced the tools isn't a good way to proceed.

Antoine

[Daniel Cheng]

On Wed, Jun 20, 2012 at 3:51 PM, Scott Hess <sh...@chromium.org> wrote:

Just ran 'git commit -a' on a client with no changes, and stopped
counting at 30s, still hasn't brought up my editor.  Oooh, just
finished, so 30s plus typing that previous line, call it 60s.  Only
one untracked file (a logfile).  I use unmanaged in gclient.

-scott

Is this on Mac by any chance? I had no idea what perf issues you were talking about, but then I switched over to my Mac and git status still hasn't finished (it's been 2 minutes now)

Daniel 

[Scott Hess]

On Wed, Jun 20, 2012 at 5:28 PM, Daniel Cheng <dch...@chromium.org> wrote:
> On Wed, Jun 20, 2012 at 3:51 PM, Scott Hess <sh...@chromium.org> wrote:
>> Just ran 'git commit -a' on a client with no changes, and stopped
>> counting at 30s, still hasn't brought up my editor.  Oooh, just
>> finished, so 30s plus typing that previous line, call it 60s.  Only
>> one untracked file (a logfile).  I use unmanaged in gclient.
>

> Is this on Mac by any chance? I had no idea what perf issues you were
> talking about, but then I switched over to my Mac and git status still
> hasn't finished (it's been 2 minutes now)

It is on a Mac.

git version 1.7.10

-scott

[Thiago Farina]

Did anyone reach a recipe to work around this issue? I want/need to commit some work, I'm pretty sure I'm not the only one too.

My workflow that worked for years until now have been this:

# On master branch

$ git pull & gclient sync

$ git checkout my-work-branch

$ git rebase master

$ git cl dcommit

This is not working! And the tool creates git-cl-cherry-pick and git-cl-commit branches and doesn't commit my change :-(

I'm on cygwin, but that combe for Linux too.

[Ryan Sleevi]

Did the work-around from https://groups.google.com/a/chromium.org/group/chromium-dev/msg/8ee7ac3719cbdd03
not work?

$ git checkout your-work-branch
$ git rebase origin/master^
$ git cl dcommit

[Thiago Farina]

Unfortunately no,

Base branch "refs/remotes/origin/master" has 56 commits not in this branch.
Run "git merge refs/remotes/origin/master" before attempting to dcommit.

--
Thiago

[Thiago Farina]

If I do git merge origin/master

Auto-merging third_party/lighttpd
CONFLICT (submodule): Merge conflict in third_party/lighttpd
Auto-merging third_party/libsrtp
CONFLICT (submodule): Merge conflict in third_party/libsrtp
Automatic merge failed; fix conflicts and then commit the result.

$ git status
# On branch fuck-submodule
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both added: third_party/libsrtp
# both added: third_party/lighttpd
#
no changes added to commit (use "git add" and/or "git commit -a")

Hey, what is wrong?! This submodule change is not even documented in
http://code.google.com/p/chromium/wiki/UsingNewGit

--
Thiago

[Thiago Farina]

OK, after that, git cl issue, a bunch of warnings, a switch to a new
branch called git-cl-cherry-pick.
Wait the patch still NOT got committed!

--
Thiago

[Stefan Zager]

First of all, sorry to everyone for the disruption. I know it's
frustrating and unwelcome.

Some developers are having no problems with the repo changes, others
are completely stuck. I've worked one-on-one with a few developers
today, and have been able to get them working again. I'd like to keep
doing that for a bit, and see if I can't get everyone on the good
foot.

Here are a few suggestions for people having trouble:

- Run the following command:

git submodule foreach 'git config -f $toplevel/.git/config
submodule.$name.ignore all'

- Make sure your depot_tools is up-to-date. There are recent changes
that are required for the new repo layout to work.

- If you're not in the habit of running `gclient sync` frequently,
please run it at least once and see if it helps. It appears that with
the new repo layout, git is more sensitive to out-of-date versions in
dependencies. I'm investigating ways to dull that sensitivity, but
for the time being, having up-to-date dependencies is a good idea.

- Some people have recovered the old behavior by always branching from
one revision behind origin/master:

git branch work origin/master^

That's fine, but you must be consistent. If you subsequently rebase
to origin/master (without the carat), you may have trouble.


A few people have reported issues that appear to be transitional,
i.e., problems with a branch that was created from a non-submodule
commit, and later rebased onto a submodule commit. These issues don't
appear to be widespread, and the solution is typically to create new
branch from origin/master and cherry-pick the local commits from the
old working branch.

Right now, the issue of greatest concern to me is the problem with
`git commit -a`. There doesn't appear to be a way to explicitly
ignore submodules with this command. That causes performance issues,
as the submodules are scanned for changes; and it may cause
out-of-date submodules to be included in the commit. I'll be
investigating that issue tonight.

So... I'm going to hold off reverting the repository change for the
moment. I'd like to give it another day and see if I can get everyone
unstuck and working again. If a lot more people are getting stuck, or
if there are unsurmountable problems (including intolerable
performance), then I will revert.

Thanks,

Stefan

[Thiago Farina]

On Thursday, June 21, 2012 1:51:10 AM UTC-3, Stefan Zager wrote:

First of all, sorry to everyone for the disruption.  I know it's
frustrating and unwelcome.

Some developers are having no problems with the repo changes, others
are completely stuck.  I've worked one-on-one with a few developers
today, and have been able to get them working again.  I'd like to keep
doing that for a bit, and see if I can't get everyone on the good
foot.

There are developers all across the world. This would be fine for a single office. But not for people working from London, Munich, Tokyo, Moscow, etc...

 

Here are a few suggestions for people having trouble:

- Run the following command:

      git submodule foreach 'git config -f $toplevel/.git/config
submodule.$name.ignore all'

Just running this doesn't not solve anything :/

 

- Make sure your depot_tools is up-to-date.  There are recent changes
that are required for the new repo layout to work.

I have ran gclient sync many times today.

 

- If you're not in the habit of running `gclient sync` frequently,
please run it at least once and see if it helps.  It appears that with
the new repo layout, git is more sensitive to out-of-date versions in
dependencies.  I'm investigating ways to dull that sensitivity, but
for the time being, having up-to-date dependencies is a good idea.

- Some people have recovered the old behavior by always branching from
one revision behind origin/master:

      git branch work origin/master^

 Then I get Base branch "refs/remotes/origin/master" has 72 commits not in this branch.

Run "git merge refs/remotes/origin/master" before attempting to dcommit.

I said this three times I think.

  That's fine, but you must be consistent.  If you subsequently rebase
to origin/master (without the carat), you may have trouble.


A few people have reported issues that appear to be transitional,
i.e., problems with a branch that was created from a non-submodule
commit, and later rebased onto a submodule commit.  These issues don't
appear to be widespread, and the solution is typically to create  new
branch from origin/master and cherry-pick the local commits from the
old working branch.

Right now, the issue of greatest concern to me is the problem with
`git commit -a`.  There doesn't appear to be a way to explicitly
ignore submodules with this command.  That causes performance issues,
as the submodules are scanned for changes; and it may cause
out-of-date submodules to be included in the commit.  I'll be
investigating that issue tonight.

So... I'm going to hold off reverting the repository change for the
moment.

I think you should have considered reverting it today, as it may have blocked many people!

 

As there isn't seem to be CLEAR work around.

[Eric Noyau]

On Thu, Jun 21, 2012 at 8:58 AM, Thiago Farina <tfa...@chromium.org> wrote:
>
> On Thursday, June 21, 2012 1:51:10 AM UTC-3, Stefan Zager wrote:
>>
>> First of all, sorry to everyone for the disruption.  I know it's
>> frustrating and unwelcome.
>>
>> Some developers are having no problems with the repo changes, others
>> are completely stuck.  I've worked one-on-one with a few developers
>> today, and have been able to get them working again.  I'd like to keep
>> doing that for a bit, and see if I can't get everyone on the good
>> foot.
>>
> There are developers all across the world. This would be fine for a single
> office. But not for people working from London, Munich, Tokyo, Moscow,
> etc...
>

And Paris. I'm unable to push anything this morning.

-- Eric

[Bartosz Fabianowski]

This change has turned the output of gitk from a *very*, *very* useful
list of commits into a completely unreadable subway map :(.

- Bartosz

[Avi Drissman]

That's the same result I get with GitX.

I work around it by always rebasing master to origin^, and then specifying local branches only for display; I don't know if gitk has that option.

Avi

On Thu, Jun 21, 2012 at 7:53 AM, Bartosz Fabianowski <bar...@google.com> wrote:

This change has turned the output of gitk from a *very*, *very* useful list of commits into a completely unreadable subway map :(.

- Bartosz

[Mattias Nissler]

On Thu, Jun 21, 2012 at 4:19 PM, Avi Drissman <a...@chromium.org> wrote:

That's the same result I get with GitX.

I work around it by always rebasing master to origin^, and then specifying local branches only for display; I don't know if gitk has that option.

I usually pass --all to gitk intentionally to show me all my branches and their relation (which is useful if you have stuff going on that depends on other stuff you don't have committed yet). Obviously, that use case is royally broken now :)

[Ryo Hashimoto]

On Thu, Jun 21, 2012 at 1:51 PM, Stefan Zager <sza...@google.com> wrote:
> First of all, sorry to everyone for the disruption.  I know it's
> frustrating and unwelcome.
>
> Some developers are having no problems with the repo changes, others
> are completely stuck.  I've worked one-on-one with a few developers
> today, and have been able to get them working again.  I'd like to keep
> doing that for a bit, and see if I can't get everyone on the good
> foot.
>
> Here are a few suggestions for people having trouble:
>
> - Run the following command:
>
>      git submodule foreach 'git config -f $toplevel/.git/config
> submodule.$name.ignore all'

I've got stuck at r143384 and the command above (and gclient sync)
does not have any effect.
Running `svn up` in depot_tools directory doesn't help.

[Ami Fischman]

>      git submodule foreach 'git config -f $toplevel/.git/config submodule.$name.ignore all'

I've got stuck at r143384 and the command above (and gclient sync) does not have any effect.

One thing I was unclear on was where to run the git submodule command; turns out that running it in my chromium/src dir did the right thing (src/.git/config gets all the submodule ignore directives).  Note this is in contrast to "gclient sync" which must run in the _parent_ of that directory.

(if you're still having problems, might be useful to confirm that src/.git/config *doesn't* have a long list of submodule ignore directives, and describe what the problem is :))

FTR, I saw the extreme slowness of [git status], ran the submodule command above, and the slowness is gone.  Unmanaged src.

Cheers,

-a

[Greg Thompson]

On Wed, Jun 20, 2012 at 3:25 PM, Stefan Zager <sza...@google.com> wrote:

On Wed, Jun 20, 2012 at 12:13 PM, John Sheu <sh...@chromium.org> wrote:
> I'm getting a git-status (probably git submodule-related) that now is
> preventing me from doing a 'git pull'.  I'm not entirely sure what to do
> with this.

Please try running this command, and let me know if it fixes the problem:

$ git submodule foreach 'git config -f $toplevel/.git/config
submodule.$name.ignore all'

git status tells me "modified:   third_party/lighttpd (new commits)"

.git/config contains:

[submodule "third_party/lighttpd"]

        ignore = dirty

running the fix command does this:

F:\src\chrome\trunk\src>git submodule foreach 'git config -f $toplevel/.git/config submodule.$name.ignore all'

Entering 'breakpad/src'

C:\depot_tools\git_bin/libexec/git-core/git-submodule: line 297: git config -f $toplevel/.git/config submodule.$name.ignore all: No such file or directory

Stopping at 'breakpad/src'; script returned non-zero status.

Is this supposed to work on windows?  I use a rebase workflow and UsingNewGit, if it matters.

[Sigurður Ásgeirsson]

On Thu, Jun 21, 2012 at 12:57 PM, Greg Thompson <g...@chromium.org> wrote:

On Wed, Jun 20, 2012 at 3:25 PM, Stefan Zager <sza...@google.com> wrote:

On Wed, Jun 20, 2012 at 12:13 PM, John Sheu <sh...@chromium.org> wrote:
> I'm getting a git-status (probably git submodule-related) that now is
> preventing me from doing a 'git pull'.  I'm not entirely sure what to do
> with this.

Please try running this command, and let me know if it fixes the problem:

$ git submodule foreach 'git config -f $toplevel/.git/config
submodule.$name.ignore all'

git status tells me "modified:   third_party/lighttpd (new commits)"

.git/config contains:

[submodule "third_party/lighttpd"]

        ignore = dirty

running the fix command does this:

F:\src\chrome\trunk\src>git submodule foreach 'git config -f $toplevel/.git/config submodule.$name.ignore all'

Entering 'breakpad/src'

C:\depot_tools\git_bin/libexec/git-core/git-submodule: line 297: git config -f $toplevel/.git/config submodule.$name.ignore all: No such file or directory

Stopping at 'breakpad/src'; script returned non-zero status.

Is this supposed to work on windows?  I use a rebase workflow and UsingNewGit, if it matters.

I had the same thing. I managed to fix it by "git diff" which tells you the SHA1 it wants the lighttpd module at.

I then went down to third_party\lighttpd, and di "git reset --hard SHA1".

[Stefan Zager]

On Thu, Jun 21, 2012 at 9:57 AM, Greg Thompson <g...@chromium.org> wrote:

> running the fix command does this:
>
> F:\src\chrome\trunk\src>git submodule foreach 'git config -f
> $toplevel/.git/config submodule.$name.ignore all'
> Entering 'breakpad/src'
> C:\depot_tools\git_bin/libexec/git-core/git-submodule: line 297: git config
> -f $toplevel/.git/config submodule.$name.ignore all: No such file or
> directory
> Stopping at 'breakpad/src'; script returned non-zero status.
>
> Is this supposed to work on windows?  I use a rebase workflow and
> UsingNewGit, if it matters.

At windows command prompt, use double quotes:

> git submodule foreach "git config -f $toplevel submodule.$name.ignore all"

... and remember to run this from src, not from src\..

Stefan

[Greg Thompson]

Thanks, that did it.  Any idea why I (and many others) had ignore=dirty rather than ignore=all in there?

[Stefan Zager]

gclient, by default, sets those to "dirty". In my early experiments,
it seemed like "dirty" was the most appropriate setting; but I think
"all" is what most people need.

Stefan

[Rachel Blum]

So, do we want to switch our settings to all instead of dirty - given your statement that you think "all" is what most people need?

Stefan

[Stefan Zager]

On Thu, Jun 21, 2012 at 10:59 AM, Rachel Blum <gr...@chromium.org> wrote:
> So, do we want to switch our settings to all instead of dirty - given your
> statement that you think "all" is what most people need?

Yes, I think that's best. I will update this in gclient, although at
this point it probably won't have much effect, since most devs already
have the setting in their .git/config, and gclient won't overwrite it.

Stefan

[Stefan Zager]

Only 69 emails on this thread so far. If I don't get a centithread
out of this, I'll be disappointed.

[Dominic Mazzoni]

Don't assume "most". I haven't synced any of my clients since I saw this thread begin (waiting for the dust to settle), and I'm sure there are hundreds of others who haven't synced yet for all sorts of reasons. Please make our lives easier.

How about if gclient prints a warning if someone has changed their .git/config?

Also, could you please update the docs at http://code.google.com/p/chromium/wiki/UsingNewGit?

- Dominic

[Steven Bennetts]

Not to deter your centithread goals, but an FAQ at this point might be helpful, it's hard to pick out all of the tips from the tread :)

davemoore@ just had an issue that appears to be related to having had a modified WebKit checkout, which sounds like an issue that others might also run into.

On Thu, Jun 21, 2012 at 11:06 AM, Stefan Zager <sza...@google.com> wrote:

Only 69 emails on this thread so far.  If I don't get a centithread
out of this, I'll be disappointed.

[Stefan Zager]

On Thu, Jun 21, 2012 at 4:53 AM, Bartosz Fabianowski <bar...@google.com> wrote:
> This change has turned the output of gitk from a *very*, *very* useful list
> of commits into a completely unreadable subway map :(.

Try:

$ gitk --first-parent

That LGTM. Please let me know.

Thanks,

Stefan

[Stefan Zager]

On Wed, Jun 20, 2012 at 1:44 PM, Avi Drissman <a...@chromium.org> wrote:

What I'm doing is avoiding ever doing:

git rebase origin

and am sticking to

git rebase origin^

to stay off the gitdeps entries.

Unfortunately, GitX doesn't like the topology and yields the picture:

Try running:

$ gitx --first-parent

That LGTM; please let me know.

Thanks,

Stefan

[Rachel Blum]

Any closer to git commit -a fixes? (It's taking 90-180 seconds for an empty tree for me :)

Rachel

--

[Rachel Blum]

FWIW, just timed git commit after a manual add, and it's ~120 seconds until I get a text editor. It's a bit painful ;)

[Daniel Cheng]

Is there a version of the submodule command that works on msysgit? My windows git checkout is a little confused now.

Daniel

[Ryan Sleevi]

Using msysgit 1.7.6 via a Git bash shell, I was able to get things straightened out with

$ git submodules foreach 'git config -f $toplevel/.git/config submodule.$name.ignore all' 

Note the single quote (double quotes did not work from msysgit bash shell) and note the .git/config after $toplevel (which was incorrectly removed in subsequent mails referencing the command)

1.7.11 is borked at the moment due to missing some git-svn perl modules, and I've had trouble with 1.7.7 -> 1.7.10 with git-cl due to how system paths are handled (which was supposed to be fixed in 1.7.11)

[Stefan Zager]

To all who have suffered at the new behavior of `git commit -a`, I have a fix:

git config diff.ignoreSubmodules all

That should restore the old behavior -- and old performance -- of `git
commit -a`. Please let me know if you have any trouble with it.

Thanks,

Stefan

[Thiago Farina]

Seriously, can someone describe a recipe of commands that works? Yesterday Stephan did a magic in my notebook and was able to commit from my checkout, but so far I'm unable to reproduce his steps to commit my patches.

I've been using the UsingNewGit workflow and tried another workflow (see below) without lucky until now:

All I get is in the end of the git cl dcommit process.

error: could not apply 1649615... browser: Move render_view_context_menu implementations into their specific platform directories.

hint: after resolving the conflicts, mark the corrected paths

hint: with 'git add <paths>' or 'git rm <paths>'

hint: and commit the result with 'git commit'

Command "git cherry-pick 1649615b300c09bec88aff99e96835571ccdfc88" failed.

error: you need to resolve your current index first

Command "git checkout -q render-context-view-menu" failed.

third_party/lighttpd: needs merge

$ git checkout -b work -t origin/master

# Make changes

$ git commit -a -m "foo"

$ git cl upload

# LGTM

$ git fetch origin

$ git rebase origin/master

$ gclient sync

$ git cl dcommit # Boom!

[Wez]

I'm not sure what state your checkout is now in, but the command to cause the third-party submodules appears only to be run in "managed" gclient checkouts, so if you use the NewGit workflow in the (unsupported) "unmanaged" mode then things get in a mess.

Wez

--

[Stefan Zager]

I am working on updating the docs, but it the meantime: I think your
refs/heads/master is out of sync again. After running `gclient sync`,
your refs/heads/master and refs/remotes/origin/master should point to
the same revision. If that's not happening, try:

$ git update-ref refs/heads/master origin/master
$ git checkout mywork
$ git rebase master

Stefan

[Mattias Nissler]

That works, but obviously only assuming you don't have any merge commits other than the "SVN changes up to revision XYZ" commits. For me, that's a fair assumption, but it might not be for everybody, and it definitely feels like cheating :)

Thanks,

Stefan

[Stefan Zager]

On Fri, Jun 22, 2012 at 1:27 AM, Mattias Nissler <mnis...@chromium.org> wrote:
> On Thu, Jun 21, 2012 at 11:13 PM, Stefan Zager <sza...@google.com> wrote:
>>
>> On Thu, Jun 21, 2012 at 4:53 AM, Bartosz Fabianowski <bar...@google.com>
>> wrote:
>> > This change has turned the output of gitk from a *very*, *very* useful
>> > list
>> > of commits into a completely unreadable subway map :(.
>>
>> Try:
>>
>> $ gitk --first-parent
>>
>> That LGTM.  Please let me know.
>
>
> That works, but obviously only assuming you don't have any merge commits
> other than the "SVN changes up to revision XYZ" commits. For me, that's a
> fair assumption, but it might not be for everybody, and it definitely feels
> like cheating :)

I am not above cheating, if it works for people. I'm going to assume
that's the case until I hear otherwise.

[Szymon Jakubczak]

On Thu, Jun 21, 2012 at 9:21 PM, Stefan Zager <sza...@google.com> wrote:
> git config diff.ignoreSubmodules all

This fixes git commit -a, but git cl upload still complains "Cannot
upload with a dirty tree. You must commit locally first." git status
shows:
# modified: native_client (new commits)
# modified: third_party/WebKit (new commits)
# modified: third_party/skia/include (new commits)
# modified: third_party/skia/src (new commits)
# modified: tools/gyp (new commits)
# modified: v8 (new commits)
(Never actually touched those directories)
git checkout -- doesn't seem to be doing anything.
Any suggestions?

[Szymon Jakubczak]

Does anyone have any idea at all how to suppress "(new commits)"
status so that git cl upload works?

[Szymon Jakubczak]

The solution to my problem:

git submodule foreach "git config -f $toplevel submodule.$name.ignore all"

(Thanks rsleevi for the pointer.)

[Luigi Semenzato]

I am not sure if this is the same problem, but my chromium tree got
"polluted" with a number of subproject diffs such as this one:

diff --git a/third_party/angle b/third_party/angle
--- a/third_party/angle
+++ b/third_party/angle
@@ -1 +1 @@
-Subproject commit 001470bb5bff47d1f3f68943a45bf53803a2b623
+Subproject commit 001470bb5bff47d1f3f68943a45bf53803a2b623-dirty

(This happened either after I ran cros_chrome_make, or emerge-<board>
chromeos-chrome.)

They don't go away with git reset --hard.

They are (correctly, I presume) ignored when I do a git commit -a, but
they prevent git cl upload from working ("cannot upload with a dirty
tree").

Any suggestions? I am unable to upload my CL.



On Jun 20, 7:46 pm, Scott Hess <sh...@chromium.org> wrote:
> On Wed, Jun 20, 2012 at 4:28 PM, Scott Hess <sh...@chromium.org> wrote:
> > On Wed, Jun 20, 2012 at 4:25 PM, dominic <domi...@google.com> wrote:
> >> On Wed, Jun 20, 2012 at 4:23 PM, Eric Uhrhane <er...@chromium.org> wrote:
> >>> On Wed, Jun 20, 2012 at 4:17 PM, Stefan Zager <sza...@google.com> wrote:
> >>> > On Wed, Jun 20, 2012 at 3:51 PM, Scott Hess <sh...@chromium.org> wrote:
> >>> >> I've got a billion entries like this in .git/config:
>
> >>> >> [submodule "v8"]
> >>> >>    ignore = all
>
> >>> >> I ran your suggested command-line without checking that file first, so
> >>> >> I don't know if they were there from a previous gclient sync or not.
>
> >>> >> Just ran 'git commit -a' on a client with no changes, and stopped
> >>> >> counting at 30s, still hasn't brought up my editor.  Oooh, just
> >>> >> finished, so 30s plus typing that previous line, call it 60s.  Only
> >>> >> one untracked file (a logfile).  I use unmanaged in gclient.
>
> >>> > `git commit -a` might be broken now.  I didn't think people actually did
> >>> > that :)
>
> >>> One data point: I use it all the time.
>
> >> +1
>
> > I'm still trying to figure out how else anyone would commit :-).
>
> Actually... git commit a/specific/file also seems to take forever.
> git commit --no-status makes it much faster, but doesn't help -a much.
>
> -scott

[Szymon Jakubczak]

I had the same problem. Try

git submodule foreach "git config -f $toplevel submodule.$name.ignore all"

[Marc-Antoine Ruel]

Or the brute-force approach:

gclient recurse -s git -j 1 git clean -f -d

or

git submodule foreach git clean -f -d

M-A

2012/6/22 Szymon Jakubczak <sz...@google.com>

[Thiago Farina]

On Thu, Jun 21, 2012 at 10:26 PM, Stefan Zager <sza...@google.com> wrote:
> I am working on updating the docs

Could you update it as soon as possible?

Thanks,

--
Thiago

[Stefan Zager]

On Fri, Jun 22, 2012 at 11:33 AM, Luigi Semenzato
<seme...@chromium.org> wrote:
> I am not sure if this is the same problem, but my chromium tree got
> "polluted" with a number of subproject diffs such as this one:
>
> diff --git a/third_party/angle b/third_party/angle
> --- a/third_party/angle
> +++ b/third_party/angle
> @@ -1 +1 @@
> -Subproject commit 001470bb5bff47d1f3f68943a45bf53803a2b623
> +Subproject commit 001470bb5bff47d1f3f68943a45bf53803a2b623-dirty
>
> (This happened either after I ran cros_chrome_make, or emerge-<board>
> chromeos-chrome.)
>
> They don't go away with git reset --hard.
>
> They are (correctly, I presume) ignored when I do a git commit -a, but
> they prevent git cl upload from working ("cannot upload with a dirty
> tree").
>
> Any suggestions?  I am unable to upload my CL.

I have seen this exactly twice, and haven't yet been able to
root-cause it. My suspicion is that if you run git-cl upload when
refs/heads/master is not caught up to refs/remotes/origin/master, then
git-cl squashes down your changes along with changes between master
and origin/master.

If you still have your working copy in that state, I'd appreciate a
chance to poke at it in a chromoting session. Please contact me off
this thread (chat or email).

Thanks,

Stefan

[Scott Byer]

Ok, another workflow that hits glitches. Usually on in my main workdir, to update, I would do:

git pull --rebase ; git svn rebase -l

Well, the git svn rebase -l part is failing on the Mac right now, complaining third_party/lighttpd needs an update. It's got a proper ignore line in .git/config.

Is this line even needed anymore? I figured that as long as the backing database was SVN, it was. I know I don't need to do it manually, that the svn rebase will get taken care up by dcommit, but I'd rather be surprised earlier rather than later.

git rebase origin^ seems to take care of it, but seems a bit heavyweight.

[Stefan Zager]

On Fri, Jun 22, 2012 at 11:59 AM, Stefan Zager <sza...@google.com> wrote:
> On Fri, Jun 22, 2012 at 11:33 AM, Luigi Semenzato
> <seme...@chromium.org> wrote:

>> I am not sure if this is the same problem, but my chromium tree got
>> "polluted" with a number of subproject diffs such as this one:
>>
>> diff --git a/third_party/angle b/third_party/angle
>> --- a/third_party/angle
>> +++ b/third_party/angle
>> @@ -1 +1 @@
>> -Subproject commit 001470bb5bff47d1f3f68943a45bf53803a2b623
>> +Subproject commit 001470bb5bff47d1f3f68943a45bf53803a2b623-dirty

> I have seen this exactly twice, and haven't yet been able to
> root-cause it.  My suspicion is that if you run git-cl upload when
> refs/heads/master is not caught up to refs/remotes/origin/master, then
> git-cl squashes down your changes along with changes between master
> and origin/master.
>
> If you still have your working copy in that state, I'd appreciate a
> chance to poke at it in a chromoting session.  Please contact me off
> this thread (chat or email).

OK, I'm pretty sure I have this root-caused. It happens when your
working copy looks like this:

O
|
|
O <- refs/heads/master
|
|
O <- A commit with DEPS roll
|
|
O
| \
| \
O O <- refs/heads/work
|
|
O <- refs/remotes/origin/master


That can happen with a sequence like this:

$ gclient sync
# Everything cool now; master == origin/master

$ git checkout -b work

# Do some work; time passes

$ git fetch origin
$ git rebase origin

At this point, the 'work' branch is rebased to the new origin, but the
'master' branch is behind. If you dcommit in this state, then you'll
wind up with a submodule change squashed into your commit.

Or so goes my theory; I'll reply again after running some experiments.
But for the time being, please make certain that the master branch is
properly fast-forwarded to origin/master before running dcommit.

Thanks,

Stefan

[Kenneth Russell]

I just checked out a completely fresh repository via the new git
workflow; checked out a clean TOT WebKit; made sure chrome builds; did
a fake DEPS update; and tried "cd src ; git checkout -b [branchname]".

Result:

M DEPS
M seccompsandbox
M third_party/WebKit
M third_party/angle
M third_party/ffmpeg
M third_party/flac
M third_party/hunspell
M third_party/icu
M third_party/libjpeg_turbo
M third_party/libsrtp
M third_party/libvpx
M third_party/libyuv
M third_party/mozc/chrome/chromeos/renderer
M third_party/openssl
M third_party/ots
M third_party/speex
M third_party/undoview
M third_party/v8-i18n
M third_party/webrtc
M tools/grit


It looks to me like something is wrong.

-Ken

[Stefan Zager]

On Fri, Jun 22, 2012 at 12:26 PM, Scott Byer <scot...@chromium.org> wrote:
> Ok, another workflow that hits glitches. Usually on in my main workdir, to
> update, I would do:
>
> git pull --rebase ; git svn rebase -l
>
> Well, the git svn rebase -l part is failing on the Mac right now,
> complaining third_party/lighttpd needs an update. It's got a proper ignore
> line in .git/config.
>
> Is this line even needed anymore? I figured that as long as the backing
> database was SVN, it was. I know I don't need to do it manually, that the
> svn rebase will get taken care up by dcommit, but I'd rather be surprised
> earlier rather than later.

I believe this falls into the broad category of "master branch is not
up-to-date". If you `gclient sync`, it will take care of
fast-forwarding the master branch. But if you fetch/pull/merge/rebase
only from your working branch, without updating the master branch,
then you will likely get into a bad state.

Stefan

[Scott Byer]

Sorry, this is in an 'unmanaged' situation (thus gclient sync won't take care of it), and from the master branch. I always keep one working directory on master, and it's the only place I pull from origin from.

Get version on the Mac is currently 1.7.5.4

[Jeremy Apthorp]

FTR, this has made git log --graph --all unreadable too. (And I frequently use merge commits, so --first-parent isn't really an option).

What are those "SVN revisions up to XXX" commits doing?

I also use an unmanaged solution, as I like to keep "update dependencies" separate from "git pull" as I often jump back and forward between revisions to work on patches.

[Stefan Zager]

I have added a few bits of accumulated wisdom here:

http://code.google.com/p/chromium/wiki/UsingNewGit#Troubleshooting_tips_for_the_git_submodule_transition

I am working on more comprehensive docs that illustrate the new
repository layout.

Thanks,

Stefan

[Jeremy Apthorp]

Even with `git config diff.ignoreSubmodules all` and submodule.*.ignore in my git config, `git add -p` is still super slow :(

[Stefan Zager]

On Fri, Jun 22, 2012 at 5:05 PM, Jeremy Apthorp <jer...@google.com> wrote:
> Even with `git config diff.ignoreSubmodules all` and submodule.*.ignore in
> my git config, `git add -p` is still super slow :(

Another first! I will look into it.

Stefan

[Jeremy Apthorp]

(Perhaps a false alarm: it's not actually that slow. I'm going to go ahead and blame NTFS.)

Still, something to keep in mind :)

[Thiago Farina]

What I'm doing is ugly. But is the only I way I get to land my patches.

# On master branch
$ git pull

$ git checkout -b work

$ git cl patch #issue-number
$ git cl dcommit

Doing a git rebase master on any work branches after git pull/git
checkout does not work. :/

--
Thiago

[Isaac Levy]

Jeremy,

I set up aliases checkout and rebase to origin^, and then you can do a
git log --graph --decorate --pretty=oneline --abbrev-commit

(i.e. omit the --all). Granted this isn't exactly the same though.

Isaac

[Tom Finegan]

Sorry to drop in so late on the thread, but I think I could possibly be suffering from results of this change. I just finished a clean checkout with the UsingNewGit instructions, and things are broken the same way they were in a tree that worked fine until Friday evening.

I'm working on Windows, btw.

Nearing end of day Friday, I ran gclient sync because I wanted to rebase a patchset before upload. I ran the sync, and then switched back to my work branch, which resulted in many lines of "warning: unable to rmdir directory: Directory not empty." Since then I can not use git_cl to upload changes. It always tells me I have a dirty tree. 

Is there a quick fix for this? All I want to do is upload a patchset.

[Thiago Farina]

On Sun, Jun 24, 2012 at 1:03 PM, Tom Finegan <tomfi...@chromium.org> wrote:
> Sorry to drop in so late on the thread, but I think I could possibly be
> suffering from results of this change. I just finished a clean checkout with
> the UsingNewGit instructions, and things are broken the same way they were
> in a tree that worked fine until Friday evening.
>
> I'm working on Windows, btw.
>
> Nearing end of day Friday, I ran gclient sync because I wanted to rebase a
> patchset before upload. I ran the sync, and then switched back to my work
> branch, which resulted in many lines of "warning: unable to rmdir directory:
> Directory not empty." Since then I can not use git_cl to upload changes. It
> always tells me I have a dirty tree.
>
> Is there a quick fix for this? All I want to do is upload a patchset.
>

Yes, git submodule foreach "git config -f $toplevel/.git/config
submodule.$name.ignore all"

--
Thiago

[Tom Finegan]

Interesting. I tried that in the checkout that existed before the change, and it made no difference. I ran it in the new checkout and it seems to have fixed things. Very weird, but thanks! 

(still have no idea why src/chromium is dead, but long live src/chromium2)

 

--
Thiago

[Matt Mueller]

One more casualty of this change:

I used to base all my branches directly off origin/master.  Now that the recommendation is to use origin/master^, upstream tracking no longer works.  Branches created this way do not show the "N different commits" message in git status.  Trying to manually set the upstream fails with:

$ git branch --set-upstream testtracking  origin^

fatal: Cannot setup tracking information; starting point is not a branch.

On Fri, Jun 15, 2012 at 3:12 PM, Stefan Zager <sza...@chromium.org> wrote:

I'm going to be rolling out the previously-announced changes to src.git this afternoon, shortly.  Friday afternoon turns out to be a pretty good time, because if developers run into trouble, they tend to be quite willing to pack in early and start drinking.

A brief recap:

- When this change takes effect, the HEAD revision of git.chromium.org/chromium/src.git will be a merge commit.

- To see the svn-only commit history, run `git log HEAD^`

- The repository will have registered (invisible) submodules and a (visible) .gitmodules file.

- dcommit will work this time!

Thanks,

[Stefan Zager]

On Tue, Jun 26, 2012 at 1:16 PM, Matt Mueller <ma...@chromium.org> wrote:

One more casualty of this change:

I used to base all my branches directly off origin/master.  Now that the recommendation is to use origin/master^, upstream tracking no longer works.  Branches created this way do not show the "N different commits" message in git status.  Trying to manually set the upstream fails with:

$ git branch --set-upstream testtracking  origin^

fatal: Cannot setup tracking information; starting point is not a branch.

That recommendation has been retracted:

http://code.google.com/p/chromium/wiki/UsingNewGit#Troubleshooting_tips_for_the_git_submodule_transition

If you have a reason to use origin/master^ which hasn't been addressed, I'd like to know about it.

Thanks,

Stefan

[Daniel Cheng]

I ran into a weird problem with a merge-based workflow today. git merge origin/master is complaining about conflicts in third_party/WebKit... I have the submodules supposedly ignored and such. How do I make the conflict go away? I manage third_party/WebKit myself so it's supposed to be ignored...

Daniel

[Stefan Zager]

I suspect that in your work branch, you inadvertently committed a different version of the third_party/WebKit submodule.  That's not hard to do if you haven't set the diff.ignoreSubmodules git config (details).

Try this:

$ git diff --ignore-submodules=none work `git merge-base work origin/master` | grep 'Subproject commit'

If you get any matching output, that would confirm the theory, and I can help you unwind it.

Thanks,

Stefan

[Daniel Cheng]

I indeed have some output. Blah.

Daniel

[Bartosz Fabianowski]

I am wondering whether these instructions [1] still apply:

cd src
pwd # Make sure you are in the src directory!
git svn init --prefix=origin/ -T trunk/src svn://svn.chromium.org/chrome
git config svn-remote.svn.fetch trunk/src:refs/remotes/origin/master
git svn fetch

I recently became a committer, followed these instructions in my git
tree - and it seems to have messed things up. Managed git no longer
fetches deps properly, svn-git gets out of sync...

I just wiped my entire tree and ran a fresh "git sync". This seems to
have automatically produced a tree that is aware of SVN revisions.
Should I still run the above commands or is git-svn set up automatically
now?

- Bartosz

[1] http://code.google.com/p/chromium/wiki/UsingNewGit

[Chase Phillips]

Hi Bartosz, the git svn setup instructions are still necessary for full committers and should not break managed git checkouts.  The issue you're describing sounds similar to what's been reported in http://code.google.com/p/chromium/issues/detail?id=134858.  Be sure to star that issue to follow along for any updates there.

If you think that's not the case, can you provide more details?  I'm curious about which deps don't get updated, whether running git fetch and git rebase in those deps fixes things, and whether there is any error output for updating the main src.git repo.  Thanks!

Chase

[Ryan Sleevi]

If you plan to commit via 'git cl dcommit' (eg: not CQ), then I believe you still need to run 'git svn init', since cl dcommit still works via svn dcommit under the hood. 'git svn init' ensures that the metadata necessary exists within your checkout/.git/svn directory. The information about git-svn-id available in the git-log is used to significantly optimize this (local) generation, but it is not a replacement for it.

The "gclient sync" not fetching properly is/was a different bug.

On Thu, Jun 28, 2012 at 5:08 AM, Bartosz Fabianowski <bar...@google.com> wrote:

[Bartosz Fabianowski]

After discussing this with Chase off-list, I can confirm that git-svn is
not getting in the way here. It was crosbug.com/134858 that bit me.

- Bartosz

[Stefan Zager]

Yes, the instructions for git-svn almost certainly need updating.  Looking at that ASAP today.

Stefan

[Vincent Scheib]

I'm back to being disrupted.

I've run the steps from http://code.google.com/p/chromium/wiki/UsingNewGit#Troubleshooting_tips_for_the_git_submodule_transition and had been fixed and working for a while.

git submodule foreach 'git config -f $toplevel/.git/config submodule.$name.ignore all'

git config diff.ignoreSubmodules all

But now the following commands result in an error:

$ git checkout -b test origin/master

$ git cl upload

Cannot upload with a dirty tree.  You must commit locally first.

Wat? git status shows I'm clean. git clean -fd doesn't do anything.

[unmanaged git repo]

[Stefan Zager]

On Thu, Jun 28, 2012 at 3:04 PM, Vincent Scheib <sch...@chromium.org> wrote:

I'm back to being disrupted.

I've run the steps from http://code.google.com/p/chromium/wiki/UsingNewGit#Troubleshooting_tips_for_the_git_submodule_transition and had been fixed and working for a while.

git submodule foreach 'git config -f $toplevel/.git/config submodule.$name.ignore all'

git config diff.ignoreSubmodules all

But now the following commands result in an error:

$ git checkout -b test origin/master

$ git cl upload

Cannot upload with a dirty tree.  You must commit locally first.

 

Wat? git status shows I'm clean. git clean -fd doesn't do anything.

[unmanaged git repo]

That message suggests that you have files in your index (from `git add`), but haven't yet committed.  Does `git status` show files staged for commit?

Stefan

[Vincent Scheib]

git status is clean