PSA: Chromium Git migration happening now

[Chase Phillips]

Hi Chromium Developers,

We've started the Chromium Git migration. The tree has been closed and we're taking systems offline.

We'll send another email when we've completed the maintenance.

Thanks!

Chase

[Chase Phillips]

Things went well tonight.  Thanks everyone for your contributions to the Git migration so far.

Before re-opening the Chromium tree and sending the all-clear, we want to make sure enough people are around and awake to deal with any issues that show up after that.  We'll re-open the tree later on around noon on Saturday once we have that coverage.

[Chase Phillips]

I am very pleased to announce that the Chromium src tree is now 100% Git.  Read on for more info:

- Chromium committers can now land changes using git cl land.  Use this command to commit instead of git cl dcommit.

- If you haven't done so already, please read and follow Vadim's PSA about setting up your .netrc file.  git cl land will not work for you until you do this.

- The Chromium tree is green.  We spot-checked and fixed any issues we found that came up as a result of the migration.

- Chromium's CQ has been working post-Git migration as early as Friday evening.  Today we opened the tree to let a bunch of changes in from the CQ to verify its operation.  The CQ continues to work as expected.

- We're confident most things are either working normally or are normal priority known issues that we are prepared to fix in the upcoming week.  In case you see an issue and want to let us know, please use this link to file a bug:

>>>>  https://code.google.com/p/chromium/issues/entry?template=GitMigration  <<<<

We'll watch for incoming issues over the weekend and respond to any high priority problems quickly or triage issues to handle during the upcoming week.

A huge thanks to all of you that made this effort possible.  You all spent an extraordinary amount of time and effort upfront and over the past couple of days to ensure this migration goes as smoothly as possible for everyone.  Congratulations to you all for completing this successfully!

For all of you Chromium developers, please us know right away if you see any problems by filing a bug in our ticket queue.  Thanks!

Chase

[Nico Weber]

Congrats, looks like this went very smoothly :-)

The cs.chromium.org "View In>Annotate" and "View In>Revision log" links still point to ViewVC (example: https://code.google.com/p/chromium/codesearch#chromium/src/ash/accessibility_delegate.h&sq=package:chromium&type=cs -> http://src.chromium.org/viewvc/chrome/trunk/src/ash/accessibility_delegate.h?view=log#revHEAD ). The ViewVC data is now out-of-date and doesn't have any changes newer than last Friday, right?

[Chase Phillips]

On Sun, Aug 24, 2014 at 8:16 PM, Nico Weber <tha...@chromium.org> wrote:

Congrats, looks like this went very smoothly :-)

On behalf of everyone involved so far, thanks!

 

The cs.chromium.org "View In>Annotate" and "View In>Revision log" links still point to ViewVC (example: https://code.google.com/p/chromium/codesearch#chromium/src/ash/accessibility_delegate.h&sq=package:chromium&type=cs -> http://src.chromium.org/viewvc/chrome/trunk/src/ash/accessibility_delegate.h?view=log#revHEAD ). The ViewVC data is now out-of-date and doesn't have any changes newer than last Friday, right?

This is https://code.google.com/p/chromium/issues/detail?id=406911.  Adrian should be able to look at it early this week.

[PhistucK]

omahaproxy.appspot.com shows None or N/A under the various base revision columns (other than the WebKit one, which is weird, given that WebKit is not under Git and it shows a hash!)... :(

☆PhistucK

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

[Chase Phillips]

Yes, that is a known issue from before the migration.  Dan and Robert plan to work on this early this week.

[Primiano Tucci]

Huge congrats guy! Finally the day has come!

> Chromium committers can now land changes using git cl land.

There has been a recent internal question about how to actually use git cl land. 

For the one who didn't realize, there is an exhaustive usage example in man git-drover

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAKcCwFOayHO0ftU4mWyNLwHrPwARo1%2BmkZ-t54vK%3DA25a-fFWw%40mail.gmail.com.

[Parisa Tabriz]

On Mon, Aug 25, 2014 at 8:17 AM, Primiano Tucci <prim...@chromium.org> wrote:

Huge congrats guy! Finally the day has come!

Hooray! A huge congrats and thanks from the security team :)

 

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

[Daniel Bratell]

On Mon, 25 Aug 2014 07:12:03 +0200, 'Chase Phillips' via infra-dev <infr...@chromium.org> wrote:

Yes, that is a known issue from before the migration.  Dan and Robert plan to work on this early this week.

On Sunday, August 24, 2014, PhistucK <phis...@gmail.com> wrote:

omahaproxy.appspot.com shows None or N/A under the various base revision columns (other than the WebKit one, which is weird, given that WebKit is not under Git and it shows a hash!)... :(

Is there a bug to follow for the omahaproxy work, or something I can do to help? I have scripts that use the "Revision Lookup" functionality (which right now returns "unknown") so just checking that it is not lost by accident.

/Daniel

[Jiang Jiang]

On Tue, Aug 26, 2014 at 10:47 AM, Daniel Bratell <bra...@opera.com> wrote:
> Is there a bug to follow for the omahaproxy work, or something I can do to
> help? I have scripts that use the "Revision Lookup" functionality (which
> right now returns "unknown") so just checking that it is not lost by
> accident.

crbug.com/402605 was marked as a duplicate of crbug.com/406874, but
406874 is not visible outside of Google I suppose.

- Jiang

[Primiano Tucci]

FYI you don't actually need omahaproxy for the revision lookup.

Now that everything is gitorious, one of the good sides of a DVCS is that you can access all the knowledge you want at the speed of your SSD :)

If you want to get the SHA of a given release (in the snapshot release branch), just

$ git rev-list  -1 36.0.1985.125 (or  git log 36.0.1985.125 for the full history)

If you want to get the branch point's SHA (in trunk) of a given release:

$ git merge-base 36.0.1985.125 origin/master

If you want to get the log of changes cherry-picked into the release branch (for the main project):

$ git log origin/master..36.0.1985.125

Provided that you have pulled the branch heads and tags (gclient sync --with_branch_heads && git remote update)

Essentially there is a Git tag named after the release number for each release build, and a remotes/branch-heads/NNN for every regular branch attempt (the one that become eventually promoted to be the branch point).

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/op.xk6yp4dmrbppqq%40cicero.linkoping.osa.

[Daniel Bratell]

On Tue, 26 Aug 2014 11:58:26 +0200, Primiano Tucci <prim...@chromium.org> wrote:

FYI you don't actually need omahaproxy for the revision lookup.

Now that everything is gitorious, one of the good sides of a DVCS is that you can access all the knowledge you want at the speed of your SSD :)

If you want to get the SHA of a given release (in the snapshot release branch), just

$ git rev-list  -1 36.0.1985.125 (or  git log 36.0.1985.125 for the full history)

If you want to get the branch point's SHA (in trunk) of a given release:

$ git merge-base 36.0.1985.125 origin/master

If you want to get the log of changes cherry-picked into the release branch (for the main project):

$ git log origin/master..36.0.1985.125

Provided that you have pulled the branch heads and tags (gclient sync --with_branch_heads && git remote update)

Essentially there is a Git tag named after the release number for each release build, and a remotes/branch-heads/NNN for every regular branch attempt (the one that become eventually promoted to be the branch point).

Very good! I did need to do a "git fetch -t" to get the tags though. They didn't appear by themselves.

/Daniel

[Primiano Tucci]

> Very good! I did need to do a "git fetch -t" to get the tags though. They didn't appear by themselves.

Yeah me and johnme@ were just looking at this.

Apparently if you do just a git clone today, the googlesource server sends you more than you requested and you get the tags for free (not sure if this is WAI, but we just checked that it happens) .

However if you have an old checkout, you need and explicit git fetch -t.

Wish I had a reasonable explanation for this. In the meantime, you're right, do git fetch -t instead of remote update. 

[Jiang Jiang]

On Tue, Aug 26, 2014 at 4:19 PM, Primiano Tucci <prim...@chromium.org> wrote:
>> Very good! I did need to do a "git fetch -t" to get the tags though. They
>> didn't appear by themselves.
>
> Yeah me and johnme@ were just looking at this.
> Apparently if you do just a git clone today, the googlesource server sends
> you more than you requested and you get the tags for free (not sure if this
> is WAI, but we just checked that it happens) .
> However if you have an old checkout, you need and explicit git fetch -t.
> Wish I had a reasonable explanation for this. In the meantime, you're right,
> do git fetch -t instead of remote update.

Regarding tags, is it normal that dev releases such as 39.0.2136.1
still contains SVN DEPS while gclient sync doesn't handle this
anymore, I ended up getting tons of:

WARNING: subprocess '"git" "-c" "core.deltaBaseCacheLimit=2g" "clone"
"--no-checkout" "--progress"
"https://chromium.googlesource.com/chromium/trunk/tools/depot_tools"
"/Users/jjgod/chromium/_gclient_depot_tools_h7lN91"' in
/Users/jjgod/chromium failed; will retry after a short nap...

WARNING: subprocess '"git" "-c" "core.deltaBaseCacheLimit=2g" "clone"
"--no-checkout" "--progress"
"https://chromium.googlesource.com/chromium/trunk/tools/build"
"/Users/jjgod/chromium/_gclient_build_wIqGww"' in
/Users/jjgod/chromium failed; will retry after a short nap...

when I checkout a tag and do gclient sync:

$ git fetch origin tag 39.0.2136.1
$ git checkout 39.0.2136.1
$ gclient sync

however, release branches works if I do:

$ git fetch origin refs/branch-heads/2136
$ git checkout FETCH_HEAD
$ gclient sync

There seems to still have some discrepancy between tags and release
branches in that regards. Can it be clarified that until when we can
rely on pure git tools + gclient for getting a specific release
version and build?

- Jiang

[Aaron Gable]

Tagged releases should contain .DEPS.git public buildspec files... +mmoss for more.

Aaron

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

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

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAKVx%2B1pcTk4nwqMOvgXBvR8QHMjLMio3WKwE1DL3Zyx6hso_5A%40mail.gmail.com.

[Michael Moss]

Yes, tagged releases still have .DEPS.git files. Is the problem that gclient is no longer configured to use .DEPS.git? That could be a problem. Even if we update current releases to put all git entries into DEPS, there are still thousands of old releases that have DEPS mirrored from svn which have all svn entries. What happens when someone tries to checkout one of those?

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

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAH58R2fi_rfsPgsKVRtUzHR9fj8N02O8V4-r8dUuszyow8DMGg%40mail.gmail.com.

[Michael Moss]

And after some testing, it looks like recent depot_tools have broken release tag checkouts. Even though I have "deps_file": ".DEPS.git" in my .gclient, when I checkout a version tag and then 'gclient sync', it appears to be forcing use of the DEPS file, with the svn entries, and thus making a mess of the git configs. If I revert depot_tools to a version from last week (I chose 3fd325b2f051e6430ab258f1e616e8be2ea11e95), the checkout uses the .DEPS.git file and works as expected.

[Primiano Tucci]

Dumb question: what is the reason why gclient can't look for .DEPS.git first and then DEPS (in this order), when deps_file is not specified? That should cover both current release tags that have both DEPS(svn) and .DEPS.git and future ones which, probably, will just have only a DEPS with git entries.

Or is there anything that would be broken by this behavior?

[Michael Moss]

I have the same dumb question. And I would add, why ever ignore the .DEPS.git file when it exists and .DEPS.git actually is specified?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CA%2ByH71cK1EoPwDk8rt-dS6ND-pVW2LuEsk_65hXygMLL7H0iBA%40mail.gmail.com.

[Michael Moss]

Discussion with infra devs indicates that ignoring .DEPS.git is a bug and not the intended behavior. Fixing.

[Matt Giuca]

Umm, I just noticed that every submitted CL seems to have two Git commits: a "fake" one referenced from Reitveld, and a "real" one which comes through in the actual checkout. Filed a bug here:

https://code.google.com/p/chromium/issues/detail?id=407925

[Michael Moss]

On Tue, Aug 26, 2014 at 11:47 AM, Michael Moss <mm...@chromium.org> wrote:

Discussion with infra devs indicates that ignoring .DEPS.git is a bug and not the intended behavior. Fixing.

Should be fixed in current depot_tools.