1543872 - [mozversioncontrol] vcs.base_ref fails on windows repos with many heads/remotes due to command that is too long

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Daosheng Mu[:daoshengmu]]

Typing ./mach try chooser in Windows mozilla-build, it gets failure as below:

The details of the failure are as follows:

WindowsError: [Error 206] The filename or extension is too long

File "c:\Projects\mozilla\gecko-dev\tools/tryselect/mach_commands.py", line 292, in try_chooser
return self.run(**kwargs)
File "c:\Projects\mozilla\gecko-dev\tools/tryselect/mach_commands.py", line 180, in run
return mod.run(**kwargs)
File "c:\Projects\mozilla\gecko-dev\tools\tryselect\selectors\chooser_init_.py", line 31, in run
tg = generate_tasks(parameters, full, root=vcs.path)
File "c:\Projects\mozilla\gecko-dev\tools\tryselect\tasks.py", line 89, in generate_tasks
tg = getattr(TaskGraphGenerator(root_dir=root, parameters=params), attr)
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\generator.py", line 160, in target_task_set
return self._run_until('target_task_set')
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\generator.py", line 342, in _run_until
k, v = self._run.next()
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\generator.py", line 263, in _run
new_tasks = kind.load_tasks(parameters, list(all_tasks.values()))
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\generator.py", line 77, in load_tasks
for task_dict in transforms(trans_config, inputs)]
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1911, in check_run_task_caches

Comment 1

[Andrew Halberstadt [:ahal]]

You're hitting a problem in the taskgraph generation. You can likely reproduce with mach taskgraph full.

Comment 2

[Daosheng Mu[:daoshengmu]]

(In reply to Andrew Halberstadt [:ahal] from comment #1)

You're hitting a problem in the taskgraph generation. You can likely reproduce with mach taskgraph full.

Although the taskgraph is generated, the try chooser server is still not running due to the same error as comment 0.

Comment 3

[Daosheng Mu[:daoshengmu]]

Is there any solution so far? I have to forward my patch to a non-Windows environment to help me push to try.
Thanks.

Comment 4

[Tom Prince [:tomprince]]

I'm not sure exactly where there error is coming from[1], but this is the only place that seems to interact with the filesystem in check_run_task_caches. It looks like GECKO causes that path to be longer than necessary. It might also be that we are naturally hitting that limit, in which case I'm not sure there is anything we can do.

[1] The traceback in comment 1 doesn't include the code from the line raising the error and line 1911 isn't in check_run_task_caches in current m-c.

Comment 5

[Tom Prince [:tomprince]]

Attachment: Bug 1543872: [taskgraph] Simplify the calculated path to the root of mozilla-central; r?dustin

On windows, the generated path will be close to the path length limits, which
causes mach try to fail.

Comment 6

[Daosheng Mu[:daoshengmu]]

More detailed log:

$ ./mach try chooser
Task configuration changed, generating target task set
Error running mach:

['try', 'chooser']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.
You can invoke |./mach busted| to check if this issue is already on file. If it
isn't, please use |./mach busted file| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

WindowsError: [Error 206] The filename or extension is too long

File "c:\Projects\mozilla\gecko-dev\tools/tryselect/mach_commands.py", line 292, in try_chooser
return self.run(**kwargs)
File "c:\Projects\mozilla\gecko-dev\tools/tryselect/mach_commands.py", line 180, in run
return mod.run(**kwargs)
File "c:\Projects\mozilla\gecko-dev\tools\tryselect\selectors\chooser_init_.py", line 31, in run
tg = generate_tasks(parameters, full, root=vcs.path)
File "c:\Projects\mozilla\gecko-dev\tools\tryselect\tasks.py", line 89, in generate_tasks
tg = getattr(TaskGraphGenerator(root_dir=root, parameters=params), attr)
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\generator.py", line 160, in target_task_set
return self.run_until('target_task_set')
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\generator.py", line 342, in run_until
k, v = self.run.next()
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\generator.py", line 263, in run
new_tasks = kind.load_tasks(parameters, list(all_tasks.values()))
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\generator.py", line 77, in load_tasks
for task_dict in transforms(trans_config, inputs)]
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1962, in check_run_task_caches
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1903, in check_task_dependencies
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1891, in check_task_identifiers
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1874, in chain_of_trust
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1716, in build_task
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1686, in add_index_routes
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1399, in validate
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1376, in task_name_from_label
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\task.py", line 1335, in set_defaults
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\coalesce.py", line 29, in enable_coalescing
for job in jobs:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\job_init.py", line 239, in make_task_description
for job in jobs:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\job_init.py", line 168, in use_fetches
for job in jobs:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\job_init.py", line 135, in set_implementation
for job in jobs:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\job_init.py", line 115, in rewrite_when_to_optimization
for job in jobs:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\base.py", line 75, in call
for task in tasks:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1212, in make_job_description
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1153, in set_worker_type
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1139, in single_stylo_traversal_tests
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1128, in set_test_type
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1120, in set_tag
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1108, in set_profile
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1097, in set_retry_exit_status
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1080, in enable_webrender
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1065, in allow_software_gl_layers
for test in tests:
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\transforms\tests.py", line 1032, in split_chunks
test['test-name'])
File "c:\Projects\mozilla\gecko-dev\python/mozbuild\mozbuild\util.py", line 938, in call
self[args] = self.func(*args)
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\util\perfile.py", line 58, in perfile_number_of_chunks
changed_files.update(files_changed.get_locally_changed_files(GECKO))
File "c:\Projects\mozilla\gecko-dev\python/mozbuild\mozbuild\util.py", line 938, in call
self[args] = self.func(*args)
File "c:\Projects\mozilla\gecko-dev\taskcluster\taskgraph\files_changed.py", line 88, in get_locally_changed_files
return set(vcs.get_outgoing_files('AM'))
File "c:\Projects\mozilla\gecko-dev\python/mozversioncontrol\mozversioncontrol_init_.py", line 421, in get_outgoing_files
upstream = self.base_ref
File "c:\Projects\mozilla\gecko-dev\python/mozversioncontrol\mozversioncontrol_init_.py", line 383, in base_ref
return self.run('merge-base', 'HEAD', *refs).strip()
File "c:\Projects\mozilla\gecko-dev\python/mozversioncontrol\mozversioncontrol_init.py", line 103, in _run
universal_newlines=True)
File "c:\mozilla-build\python\lib\subprocess.py", line 216, in check_output
process = Popen(stdout=PIPE, *popenargs, **kwargs)
File "c:\mozilla-build\python\lib\subprocess.py", line 394, in init
errread, errwrite)
File "c:\mozilla-build\python\lib\subprocess.py", line 644, in _execute_child
startupinfo)

Comment 7

[Tom Prince [:tomprince]]

Moving to general, since this appears to be hitting a limitation of mozversioncontrol on windows.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f04be3819486
[taskgraph] Simplify the calculated path to the root of mozilla-central; r=dustin

Comment 9

[Daosheng Mu[:daoshengmu]]

My GECKO is c:\Projects\mozilla\gecko-dev. Even though applying this patch, I still get the same path. It looks like not be very long, IMHO.

I guess the problem is caused by _subprocess.CreateProcess(executable, args, # no special security None, None, int(not close_fds), creationflags, env, cwd, startupinfo) in "c:\mozilla-build\python\lib\subprocess.py", line 646, in _execute_child
startupinfo)

The args is as below

"c:\Program Files\Git\bin\git.exe" merge-base HEAD b26dc9418c8d70b9187375f23971e72f93d94c6f 19c1633df3aa81a1e294a3c83c9ff586e079ef81 4ee4cc813c4af014e8e91bbb1ef43d9731af80ea a1ad4ba3f7a25113331b17aaf16b962fcae8a00f 76c6301c8f85f7d56c20ee78bd02fada70d3a86c a75c145db385e5469f6c3bb82d1219e1d2f352df d17d2697d04b8b749143b8b0a73bf0d3b51b5c03 972628e97ef1d28df0cccf499e5a89496127ff1c 344c42a68905320c7cad1716022e52d6eb53cfac c2fea10d9bf33908977086e752e199d1aff3f562 4c8d926a6c7da00f1fa7654c8b6ee54465191db9 900aa0075567f28c96deb7a42ab3e38f6bc34e8c dda423806caf3e4811fceda5a81a6827bc34d5e0 f9faf51404feab24e49f3f26b084f57adf03c305 197b2b2e59c39a9f0ab77956711f02276a3d2579 be479a57f292f94e8d2ae04284018503ba7d6742 23f3acf6624e3d59cf5c793d813b8b03f55a8690 a35904034536f78904f1e969f9bd5a92272c0fcd a9888802dd1b3f90cebdd37f649808d5a71198f3 dc24ff103739a19b5baf9344e5fb8c81e96c88aa a17c204277f7e2ca050fd08e9ad1d1983407cee2 775cba3e26dfe185d23dfe3becf8884c1c1e9225 015ac3d585635800236319f72757e6ada06cf3ab 9f5196eff2073de09a5a593f04e549e72e199c7f fffbbf615405116164df7b6c94a1b05b9d425743 d3b9f33ff348a28369af1fe48bddb297e8ea633e 6fa32e190b71fda3469d31eb8cad1ce7a310d720 cf15462d77d783b9972fa2e220cbe4aebb614576 dac9e9253a9a1ddfb2a432439c735b087d4a93d5 828f126da22b4dd86d346795fc3b6b45bb7b37a9 d4fd4c543f2843a280995a61f6b5bda54248a6a9 9e59e3ad869127e8474aced6aea458d279de47ce c08fec3a141e054bec3cba2069cc6a4b0dea38ae a34aa7e2e9239c7186a61d34152d0ea205a6afc9 5f68c1a46dfc2f7ce718650b9f1c8ee0768844e0 75c93951e9772833885d950192cc545355947f7a 096966003080ac1b2411181649a7debb3b9bc09a 26d0cb6b054f1f43ca46d9a95877c84e7c96b234 e33db4b7711007135d80b7400d4ce95b134e9056 051e6dffb6814d81821e44c1aba7e387bd30c290 85c8c02729fdbebdfd5d0cecedcdedbc01588bab 7873f12bb76ea87caec20b39ef07af517d9190f4 4c66e355a0f91ec286c981acb605aba15a430abb 890e65a32e3422774c4fd503fa02014db76c957b 7a7167af268dc6584e3f5490c6b4110c20c9235c cf07a3414efee6fd548b192beb781a9a92955663 748903213aa3c63a930268a34ff93c46e1c6fb44 15fb6795968ddeca906256e02d56c0d50a9a62b7 6fe8faf83806eef4bf09c85c75b757b63f65bff9 7593aecafd345a408104c00243dcecbbc8038f56 2f201489d7cd727b1a842ca492caa228de0aef22 81af09d02889c4c9d6abae71c8049b9573a0c387 ec01b58dd86d42069ed478223c24bf044dc0efe6 0ae0848106b6671b4b890f0789c0cec6e08fd3f3 ca1dfcd306ab017af608470d5f67ec17b6e4d112 106f55f071c8dee04fb7c770f2d6f1fe337fd56e 27a37026327f9fa31efe09c3efcb9cfe6116cca1 57fa92b07b5f674280723594faa6776962382a45 82398519ef5343d1cc58f8380d3eebad6aad017a acba3b82df4c370aafaa4c6b5fd632bcaf941dd6 61b66193a230027dbf8d116d0588d99c4a0a2c10 98b385750422502b646c52a2ddfdf37842a4254c b41b1c60f951aeaaeaa6c404e6a77d495ca979da f2a3d036ef32cf0ef6354218b2afb621f693519a 506941da5646f36cc14d910b98a352d6a4f15772 a3ee191921227a74e258eb7cf4b74f34a260fc9c 07a04222109d212aca2b61801a5c036501f13bcc 89f1a1fbc5ad471e5b4d485525ddb186704de12b b2c2efa602494b92d40c13c0fb97afcc5747f1f4 2a57ecd1b1439b52b1772530bd48ecb9f65ed1f3 76487408674a3e01b931c3a68947767b12b0d921 0d1a59da077d7fa96526504eddf01bb7a77503c0 cb0b2fe80ff521875d55eefe91e16ec17a884bc8 e3dbbf3a250688bd55b5d70bf083a0e19fbd2303 cf6e96f632360905947037c58c61f696f89be227 ebf0662b752dd55398d8b94ab1210ed352e6d61d 2db324353fccb0cf5d7c059d73000ea94f04ef58 7af7061e26247ea60105257e83ff1de7203dabc9 e8ef82b4fa40927ff8c93f4965292dfaad79a8d6 a2d510529170baf3a8654d1d13185dc68848eb0c c3718de62484640ac4f1b6100b049dec4b6921cc c1aee2229ff5699c68f3163b37d9c8e8e9f14222 b69ecbc577683300802f38a8b3df31521dad25df 9d0ab8e3e66ed87bac2212d62c18e3ebd669065e 052137a3f4f66442dbc685e1de2bc8e6dc6b47f9 f52ebf4b73a5b896f668680febae256b041a3aaa 9add80b38bb4b82ea0ed3948663cb8153531844d cbe9c89090b4617aae2bf447ed51fc727a54d4da cd3bf67980862930b2720614c527605b0c59de97 d9b93215af7098a306f0bfa09a5f443161bffe43 e0c75057161369be1464110d571a5b336382bb73 74a508c5d365e168ceb953cb02df99a8436b0ea3 6179344e1334c8d2e7866d0167d8301fbfc26d6f b5c3df1a71c6989fee0ba3b4bec0744c9ebeb1bf 3f4d314902c63de3ec0db268d57afb5c59d12e67 8e060c18df0fcec989a46e00906f3a6ce99dea24 7d242fe2407b6cff36bdda22fd1f034d93390f96 64d1a7d41a5fddfde1758ce3b3487c30d5d508ff a10ae2bbd710174158b558db8e98a0f5e09b9f77 970441534da1d48853786572a5830b1d916ef3d8 8fe9fd43012068406b94a0f898ab4c380f491d0e 4ae1269554519020e868b839e3887f44bc4d6cde 02478086b7abce4cd68228a38247b7aff6311d25 8ff5592b24064b09b924421b94090724e34c67d6 1a9092ca1db74e44db3e2460ffa5833e146b0526 843e46d74bbabd0bfc28143cd722fb0bf636db73 ad7bce761f1798451e62cec1a4f5ab8b8c075c33 9859f4db9f396557d252cce37274a9a7778f1f86 f077d8986bea335815f4850d1ba307168811c42c a5ff57acc346b8053d81925da9a3897dc05b099d b8faaccc5aa567854f145160f6bb58d50aab7bbd c9c7f3430f9c608d89014f41e72ad70a0c8bbfe9 f8dc4aff1fdd403160a36bb761e89e7ac4896bd9 8a9fbdacb7ab6a898d229aa5c99cec034b1b5ee3 7ba8082ca2e1a0b9b6cd4aba4abb2221af060bc8 8547faa747d3521858eb361d11868568bf58bb0a c0048cc0f8b8177ecc4b805c00fa9a929844f364 b369ed0e2dafd3572fa627a3169d4b5155ba4b20 bbc624da9d0a23b84ef87c7e98b5db68149f3ba0 9d0967878f68063458aa8d8282916d3c98690fe6 81098c6d246c646d39684e736168275f0908c47b c44d53af2c12cc2fac36b5830a9e3ca11ee1a2a8 eea8137324a5d00bcfe6f01f880897ecff14be1a ac1528f4fd60ad42a5123039c09298be1c7a7ae7 2a75932c6daf664c38237fdbb7cb9571ae0fa748 2d12090449553e49e9db339a26e30218b7b2cbae 4a69f7befe788e440ba961787d3de8b7449beccb 659e0b603c38949471522ed0c8a4490cd7327f18 748bfa5a13088be3f70d45c03190364a1928e9a3 fde21780d888bd99576a964249826bc7c9ac4b2f e83f5190c05278771afc3ce404021f3e46f830e3 2be34e25e12ac1d0b0101f2a3c91026efac8ac86 c70c32149e9f839b4c42852c0046df988222c3ff 65725a900e1349eb6d97d5f8546d6059f0b3047c d90413953758933df01cc1fd54aff29214798eb6 80a0994348e37742d8ca7ed9ae1128f64628b4bc 9980e1052e5b0a2dc44482a76cfcc31a3287b275 87227a18c18ba1c9423f76ced5b8eeceff36433d 9df63f6351bcb54010ca8d14184cfcd694f36b36 e96c9fe67add4f0122ca84fb6204a56690b14510 1102484ec594b938eb12b2dd915a3eae9f5f92c8 7a9910bc2f3e79ef2194ae90c5fd74fb864688b0 417d56e755b05b7d555bb571388b8813eadaf1cf 7ddee97b2607e593699e7bd6c8205d045586ce8a d3d8aad99bba1475e78e226ba99f1082cdd35bd3 8ee3308e5276ee43a64f4617dc183d0212c8619f 38f6f457cb9ac0404faf8ccd46d8073e60e9243c 5ea8358e4f478161ff7fc6efca2079325c54d0ca 918d004f1624867fc7377a93ed84da59c543e825 dae2c8e162da30c877f7165110fdc2add6cad15e 61860f25f5d703d53977bc47a9a0ce2650f36949 0e0f19a15b949bb6e572b6944762248d67a546d3 4c7f7e14ea80deebbdb8e4f04cfe8f3bfb2835d2 0e27ea8ca985f4b878a9ba2bebfe71fd5497e5c1 3dc287884d443d6b522e22ba4dd6c871f40e6410 2e4d995ebdd259a234a9320561a0dcc2e3b8c413 24d6e6dc7c6a5b9441bdb43da9670e6c565cacaa a4903564274f4d5d755cf7c3a9d439da476ccb83 9d9a5ba123f6b6ec6ac4509c73218718a8371408 af478981c4615d49a8b81b62bbb1dad6d47c71f3 babe741be8b63e024ec45cc644bf7786e8f63ba8 791da791a0adbe8c152bebda512279b8b5b4a4a6 4f27529fb48c3a9498eae76e10eb5a6f286b3318 78855fdc6f8a44ea7a1a3d1281f2fef9ba370a75 c62f7715782a41ad8aeae233cda846051eddb22d d677e22aacf080f7d7995361c3b396ae2433d497 3761b64b9792d40d98d06614ec0a45ed93a05319 8d46c49f4c93eadb7aa1422824c414762027e0b8 841b4645b3cef8deb6a48d5eac2b481671a9b929 ebc8318a51f377ec878e69e232685a5ef86348ee 4966c724e2134aa8e46f4097e5e15d6f95e37a59

As you can see, there are lots of changeset ids. Is it possible just sending "c:\\Program Files\\Git\\bin\\git.exe" merge-base HEAD~N instead of giving a bunch of changeset ids?

Comment 10

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/f04be3819486

Comment 11

[Daosheng Mu[:daoshengmu]]

Per Comment 9.

Comment 12

[Andrew Halberstadt [:ahal]]

Oh I guess you just have a lot of refs in your repo.

Unlike mercurial, git doesn't have a concept of draft/public states. So we need to somehow figure out what parent of HEAD is shared. Since we don't know where HEAD is based off of, we just grab every possible ref and use git merge-base to find the most likely candidate. This function is implementing all of this.

I suspect you have a lot of unused branches lying around, so one workaround here would be to clean them up. Try running git for-each-ref refs/heads refs/remotes to see what all those revisions refer to. Then git branch -D / git push <remote> :<branch> the ones you don't need anymore.

Otherwise I'm not sure how to solve this properly. Maybe we don't need to look at refs/heads and only using refs/remotes is good enough? I'm not confident that would be correct though. Hopefully someone more familiar with git than myself can come up with a clever solution here.

For context, :chmanchester originally wrote this years and years ago and I just refactored it into mozversioncontrol.

Comment 13

[Daosheng Mu[:daoshengmu]]

After removing other remotes like Beta, Inbound and only keeping Central and Try remotes, it works for me. I am curious if we can just compare with the refs in Central or Try remotes instead of looking into all remotes.

Comment 14

[Andrew Halberstadt [:ahal]]

Possibly? I'm not entirely sure how git merge-base works, and reading the man page just confused me further :). I'm not even sure that the current implementation is 100% correct tbh.

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

Try running git for-each-ref refs/heads refs/remotes to see what all those revisions refer to. Then git branch -D / git push <remote> :<branch> the ones you don't need anymore.

Cloning gecko-dev by default fetches all the old branches e.g. GECKO100_2011122113_RELBRANCH, does this mean fuzzy is broken by default? 🤔

Comment 17

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1543872 - Use `git log --not --remotes`

The current way to get base commit in Git passes every branch to merge-base, which generates a way too long command that fails on Windows. This patch tries getting HEAD on remote so that the command can be short enough.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/852d8b0aedc0
Use `git log --not --remotes` r=glandium

Comment 19

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/852d8b0aedc0