| Summary: | Fetcher: grabs way more than it should (via one's .gitconfig) | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Saul Wold <sgw> |
| Component: | bitbake | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | josh, poky.bs.watcher, poky.watcher, richard.purdie |
| Version: | 1.0 | ||
| Target Milestone: | 1.1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | Patch our for review on mailing list | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Saul Wold
2011-06-01 11:34:44 UTC
Hi Saul, could you elaborate more on how to reproduce this issue step by step? i tried fetching the uboot, and it works in my side. It looks like this could be a result of hitting Ctrl+C at an inopportune moment such that the cwd is not as expected. See this log snippet from #poky: zecke: i also had another funny issue... I CTRL+C in the wrong momemt... zecke: so the git fetch2 changed the 'origin' of the git repo that contains the poky checkout bluelightning: zecke: ctrl+c once, or multiple times? incandescant: ah, we've seen that reported before but didn't know it was when cancelling a build zecke: i assume it is hard to reproduce, so something must be doing a chdir when I hit CTRL+C... zecke: i would think a good start would be to check the return of os.chdir in bitbake Here is my .gitconfig. In response to the comment above, I have not hit ^C in my build, so I am not sure they are related. [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true #[branch "master"] # remote = origin # merge = refs/heads/master # #[branch "contrib"] # remote = contrib # merge = refs/heads/sgw/master [remote "poky"] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://git@git.yoctoproject.org/poky.git [remote "contrib"] fetch = +refs/heads/*:refs/remotes/contrib/* url = ssh://git@git.yoctoproject.org/poky-contrib.git push = +refs/heads/contrib:refs/heads/sgw/master [remote "intel"] url=ssh://git@git.yoctoproject.org/meta-intel.git fetch = +refs/heads/*:refs/remotes/intel/* [remote "home"] url=ssh://sgw@bigsur.com//intel/poky2/git/sgw.git fetch = +refs/heads/*:refs/remotes/intel/* [remote "oe-core"] url=git://git.openembedded.org/openembedded-core.git [remote "oe-contrib"] fetch = +refs/heads/*:refs/remotes/oe-contrib/* url=ssh://git@git.openembedded.org/openembedded-core-contrib.git [user] name = Saul Wold email = sgw@linux.intel.com [sendemail] from = Saul Wold <sgw@linux.intel.com> smtpserver = smtp.intel.com suppressfrom = true Some notes on reproducing this. This bug only occurs upon updating an existing repo, not when doing a fresh clone. It occurs with the "git fetch --all -t" command. Also, you need to uncomment the commented lines in Sauls .gitconfig. I've sent email to the git list about this as it appears impossible to stop git looking at ~/.gitconfig without patching it. I have a patch which we could use but lets see what they say first: diff --git a/config.c b/config.c index d06fb19..19e7565 100644 --- a/config.c +++ b/config.c @@ -860,6 +860,8 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config) int ret = 0, found = 0; const char *home = NULL; + config_exclusive_filename = getenv(CONFIG_ENVIRONMENT); + /* Setting $GIT_CONFIG makes git read _only_ the given config file. */ if (config_exclusive_filename) return git_config_from_file(fn, config_exclusive_filename, data); (where we'd need to ensure we set GIT_CONFIG to point at the config file in the checkout directory). |