New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 624178 link

Starred by 6 users
Status: Fixed
Owner:
█ phajdan.jr@chromium.org
Last visit > 30 days ago
Closed: Sep 2017
Cc:
█ benhenry@chromium.org
█ smut@chromium.org
aga...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Blocking:
issue 623762
issue 643346



Sign in to add a comment

Ensure gclient can fetch arbitrary refs/hashes and check out FETCH_HEAD

Project Member Reported by aga...@chromium.org, Jun 28 2016 
When a DEPS file specifies a dependency like "foo/bar.git@some/refish", gclient currently bails unless "some/refish" is already present in the local fetch config. That's silly. Git can do "git fetch origin some/refish" just fine, delivering it right into FETCH_HEAD. gclient should take advantage of that functionality to ensure it can check out arbitrary refs (and hashes!) without needing any special refspec configured in remote.origin.fetch.


There's a small chance gclient can already do this, at least with a flag or some black magic. So first confirm that this needs to be added, then actually add it.

Comment 1 by s...@google.com, Jun 29 2016 

All right I just did a fresh build which rm -rf'ed the entire checkout before starting and without specifying --with_branch_heads during gclient sync, and it looks like we do not fetch into FETCH_HEAD first:
https://uberchromegw.corp.google.com/i/internal.bling.tryserver/builders/beta-cherry-picker/builds/811

Error: Command 'git checkout --quiet refs/remotes/branch-heads/2743' returned non-zero exit status 1 in /b/build/slave/beta-cherry-picker/build/src
error: pathspec 'refs/remotes/branch-heads/2743' did not match any file(s) known to git.

We should fetch the revision or ref after the @ before running git checkout during gclient sync, and also before running git reset during gclient revert.

Comment 2 by s...@google.com, Jul 6 2016

Cc: benhenry@chromium.org
Anyone familiar with gclient that can take a look at this? This is very important to get Bling's branch builders working again. For context, see the blocking bug.

+cc benhenry for triage

Comment 3 by sdefresne@chromium.org, Jul 18 2016 

This will soon be blocking the migration to GN (as I need those bots to validate that I can create an official build using GN, prerequisite of shutting down gyp support). Can this bug get some love?

Comment 4 by aga...@chromium.org, Jul 18 2016 

The bling/GN issue has been resolved via a rollback, so this issue is no longer a high priority. Apologies for being on vacation while it caused issues. I still plan to fix it, because this is the only sane way for gclient to behave anyway.

Comment 5 by aga...@chromium.org, Nov 22 2016

Blocking: 643346
Status: Started (was: Assigned)
I've started this work: https://codereview.chromium.org/2448303002

It's a long slog.

Comment 6 by benhenry@chromium.org, Jan 18 2017 

Ping - please provide an update to your high priority bug. This bug is stale. Is it really P-1?

Comment 7 by aga...@chromium.org, Jul 7 2017

Cc: aga...@chromium.org
 Issue 738706  has been merged into this issue.

Comment 8 by aga...@chromium.org, Sep 6 2017 

Issue 605268 has been merged into this issue.

Comment 10 by phajdan.jr@chromium.org, Sep 7 2017

Owner: phajdan.jr@chromium.org

Comment 11 by phajdan.jr@chromium.org, Sep 14 2017

Status: Fixed (was: Started)
►

Sign in to add a comment