rebase-update takes forever on linux

[Rachel Weinstein Petterson]

Recently (at least the past 2 weeks) "git rebase-update" takes forever O(hours) on my linux box but finishes O(minutes) on my Windows machine. On my linux machine, it does eventually finish, but I often have to come back the next day. "gclient sync" is acting normally. In addition, the machine is mostly unusable while it's doing this and top shows that git is taking up nearly all the cpu.

I'm on Trusty, but it was working fine until a couple weeks ago. Any thoughts on what could be causing this behavior?

Thanks,

Rachel

[Marc-Antoine Ruel]

Try the following and look if it makes sense:

git branch -avv

git log --graph --decorate --pretty=format:"%Cgreen%d %Cred%ad %Creset%s" --branches --date-order --date=short

git remote -v

# It should be https://chromium.googlesource.com/a/chromium/src.git with or without /a/

You can remove any git svn info if still present in .git/config and rm -rf .git/svn

Otherwise, maybe you have a custom hook or something else slowing the process down.

M-A

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

[Rob Wu]

Have you submitted any a CL and deleted it afterwards? A while back chased down slowness, and attributed it to an overzealous retry timer in the depot tools.

Run git cl issue and see if it completes swiftly. If not, edit .git/config and remove the defunct issue number from the affected branch (or use git checkout [branch] and reset the issue using git cl issue 0).

Kind regards,

 Rob

 https://robwu.nl

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Rachel Weinstein Petterson]

Running those commands yields expected results from "git branch -avv" and "git remote -v". I'm not quite sure what to expect from the git log command -- the output is quite long. Is that expected?

I don't have any residual svn stuff hanging around. If I have a custom hook somewhere, where would it be defined?

[Daniel Bratell]

On Thu, 04 Dec 2014 02:31:52 +0100, Rachel Weinstein Petterson <r...@chromium.org> wrote:

Running those commands yields expected results from "git branch -avv" and "git remote -v". I'm not quite sure what to expect from the git log command -- the output is quite long. Is that expected?

I don't have any residual svn stuff hanging around. If I have a custom hook somewhere, where would it be defined?

Can you check what processes (with what command lines) are run when your computer semi-hangs? Often you can see what git is up to because it spawns a subprocess with a commandline that reveals it.

Your symptoms remind me of what happens when git enters an infinite gc loop (it thinks it needs to gc, runs gc, nothing improves, do one step of the initial operation, goto start) but then many other git commands (and gclient sync?) should also be very slow. That can often be fixed with a git gc --prune=now (anything that makes it prune things so that it no longer thinks it has to run a gc).

/Daniel

[Primiano Tucci]

Sounds like at least one of your branches is tracking an obsolete upstream, so everytime you ask it to rebase it has to shelve out ~thousands commits and replay them.

Can you paste the output of git branch -vv (without the -a, which would otherwise show thousands of branch-heads)?

You want to be in a situation where every line (branch) in the output of branch branch -vv tracks either origin/master or another branch

[Rachel Weinstein Petterson]

Hi, Primiano & Daniel,

Thanks for your help. 

A grep for git processes didn't yield anything unusual, no gc processes although I did run "git gc --prune=now".

However, the result of "git branch -vv" led me to me figure out the problem. Here's the output:

* (no branch, rebasing (null)) 99cd209 webcrypto: Change more errors to OperationErrors

  branch1                   0d5f2da [origin/master: ahead 10] actually remove test

  branch2                      eea8797 [origin/master: ahead 1, behind 628] FREEZE.unindexed

It looks like everything is pointing to origin/master, but the one which it hangs on is has the commit listed as FREEZE.unindexed. In searching for FREEZE.unindexed (because that looked odd), I found crbug.com/376099 which looks like the same issue.

I realized that some special set up that I have for building Chrome and ChromeOS side by side is probably what's causing this. I added '/*_out' to my exclude file as suggested in the bug and that seemed to fix it

Thank you to everyone for your help!

Rachel