Re: Bare repository fetch/push race condition
Sorry for misleading subject. It should be "Race condition between pushing to and pushing from a bare repository"
Bare repository fetch/push race condition
It looks like there is a race condition between fetch and push in a
bare repository in the following setup. There is a bare git repository
on a local file system. Some process pushes to this repository via
jgit. There is a cron task which pushes this repository to the backup
remote repo over ssh. We observe the following in the reflog:
6932a831843f4dbe3b394acde9adc9a8269b6cf1
57b77b8c2a04029e7f5af4d3b7e36a3ba0c7cac9 XXX 1505903078 +0200push:
forced-update
57b77b8c2a04029e7f5af4d3b7e36a3ba0c7cac9
44a221b0271b9abc885dd6e54f691d5248c4171f XXX 1505905206 +0200push:
forced-update
44a221b0271b9abc885dd6e54f691d5248c4171f
57b77b8c2a04029e7f5af4d3b7e36a3ba0c7cac9 YYY1505905217 +0200
update by push
Where XXX is the process pushing via jgit and YYY is the cron task. It
looks like the cron task started a push when the ref was pointing to
57b77b8c2a04029e7f5af4d3b7e36a3ba0c7cac9 and push finished when the
ref was already updated to 44a221b0271b9abc885dd6e54f691d5248c4171f.
The push unconditionally updated the local tracking branch back to the
commit 57b77b8c2a04029e7f5af4d3b7e36a3ba0c7cac9 and we lost the commit
44a221b0271b9abc885dd6e54f691d5248c4171f since the next push from the
local process created a new commit with
57b77b8c2a04029e7f5af4d3b7e36a3ba0c7cac9 as a parent.
Shouldn't the update_ref at transport.c:308 specify the expected
old hash, like this:
update_ref("update by push", rs.dst, ref->new_oid.hash,
ref->old_oid.hash, 0, 0);
at least for bare repositories?
'git submodules update' ignores credential.helper config of the parent repository
I'm checking out a repository in a non-interactive environment and would like to disable interactive credential helpers. According to [1] it can be done by specifying an empty helper in a local config: [credential] helper = But the submodule update command ignores the helper specified in the config of the parent repository. To reproduce it, fetch a repository with submodules requiring authentication and run: git submodule init; git submodule sync; git submodule update; the 'git submodule update' runs a default credential helper. The only way to disable it is specify helper in command-line: git -c credential.helper= submodule update Is it by design? [1] http://marc.info/?l=git=147136396024768=2
Credential helpers processing order
Hi, I wonder why credential helpers are called in the order: system, global, local, command-line and not in the reverse order? This make it impossible to provide a custom helper and disable default ones via command-line parameter. My use-case is to clone a repository in a non-interactive environment where a system-level GUI helper is configured: clone hangs since system-level helper called first and there is no input from the user. Also if a system-level helper sets quit=true, then lower-level helpers won't be called at all. Is it by design? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
submodule.$name.url is ignored during submodule update
Hi, I've noticed that the 'submodule.$name.url' config parameter from the main repository is ignored when a submodule needs to be updated, the submodule's 'remote.origin.url' is used instead. Is there any way to customize the submodule url for both the initial clone and for updates? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: submodule.$name.url is ignored during submodule update
I want to use a custom url for both initial submodule clone and submodule update. Git submodule man page states that if I run 'git submodule init' and then change the 'submodule.$name.url' in the main repository config, git will use this url instead of url in .gitmodules. Git does use the custom url for initial submodule clone, but doesn't use it when cloned submodule needs to be updated. Is that by design? On Thu, Mar 19, 2015 at 2:09 PM, Doug Kelly dougk@gmail.com wrote: On Thu, Mar 19, 2015 at 4:27 AM, Dmitry Neverov dmitry.neve...@gmail.com wrote: Hi, I've noticed that the 'submodule.$name.url' config parameter from the main repository is ignored when a submodule needs to be updated, the submodule's 'remote.origin.url' is used instead. Is there any way to customize the submodule url for both the initial clone and for updates? That's what git submodule sync is for. It will synchronize the url in .gitmodules with to the remote.origin.url for each submodule. I'm not sure about the second part of your question: are you talking about using different URLs for the initial clone and updates? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: submodule.$name.url is ignored during submodule update
Sorry, my bad. I thought 'git submodule sync' changes only 'submodule.$name.url' in main repository config, but it also changes the 'remote.origin.url' in submodule's config. I indeed ran 'git submodule sync', that's why the default url was used even though 'submodule.$name.url' had a different value. On Thu, Mar 19, 2015 at 2:16 PM, Dmitry Neverov dmitry.neve...@gmail.com wrote: I want to use a custom url for both initial submodule clone and submodule update. Git submodule man page states that if I run 'git submodule init' and then change the 'submodule.$name.url' in the main repository config, git will use this url instead of url in .gitmodules. Git does use the custom url for initial submodule clone, but doesn't use it when cloned submodule needs to be updated. Is that by design? On Thu, Mar 19, 2015 at 2:09 PM, Doug Kelly dougk@gmail.com wrote: On Thu, Mar 19, 2015 at 4:27 AM, Dmitry Neverov dmitry.neve...@gmail.com wrote: Hi, I've noticed that the 'submodule.$name.url' config parameter from the main repository is ignored when a submodule needs to be updated, the submodule's 'remote.origin.url' is used instead. Is there any way to customize the submodule url for both the initial clone and for updates? That's what git submodule sync is for. It will synchronize the url in .gitmodules with to the remote.origin.url for each submodule. I'm not sure about the second part of your question: are you talking about using different URLs for the initial clone and updates? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git gc removes all packs
I followed your advice and removed a symlink ref from my repository. But didn't help.. automatic GC has just removed all packs again. May alternates cause such a behavior? Are any ways to make gc log somewhere why it removes packs? On Thu, Feb 5, 2015 at 9:03 PM, Jeff King p...@peff.net wrote: On Thu, Feb 05, 2015 at 04:13:03PM +0100, Dmitry Neverov wrote: I'm using git p4 for synchronization with perforce. Sometimes after 'git p4 rebase' git starts a garbage collection. When gc finishes a local repository contains no pack files only loose objects, so I have to re-import repository from perforce. It also doesn't contain a temporary pack git gc was creating. It sounds like git didn't find any refs; it will pack only objects which are reachable. Unreachable objects are either: 1. Exploded into loose objects if the mtime on the pack they contain is less than 2 weeks old (and will eventually expire when they become 2 weeks old). 2. Dropped completely if older than 2 weeks. One more thing about my setup: since git p4 promotes a use of a linear history I use a separate repository for another branch in perforce. In order to be able to cherry-pick between repositories I added this another repo objects dir as an alternate and also added a ref which is a symbolic link to a branch in another repo (so I don't have to do any fetches). You can't symlink refs like this. The loose refs in the filesystem may be migrated into the packed-refs file, at which point your symlink will be broken. That is a likely reason why git would not find any refs. So your setup will not ever work reliably. But IMHO, it is a bug that git does not notice the broken symlink and abort an operation which is computing reachability in order to drop objects. As you noticed, it means a misconfiguration or filesystem error results in data loss. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git gc removes all packs
Hi, I'm experiencing a strange behavior of automatic git gc which corrupts a local repository. Git version 2.2.2 on Mac OS X 10.10.1. I'm using git p4 for synchronization with perforce. Sometimes after 'git p4 rebase' git starts a garbage collection. When gc finishes a local repository contains no pack files only loose objects, so I have to re-import repository from perforce. It also doesn't contain a temporary pack git gc was creating. Command line history looks like this: git p4 rebase Performing incremental import into refs/remotes/p4/master git branch Depot paths: //XXX/YYY/ Import destination: refs/remotes/p4/master Importing revision 352157 (100%) Rebasing the current branch onto remotes/p4/master First, rewinding head to replay your work on top of it... Fast-forwarded master to remotes/p4/master. Auto packing the repository in background for optimum performance. See git help gc for manual housekeeping. ps aux | grep git nd 14335 95.0 1.4 4643292 114788 ?? R 8:52PM 0:05.79 git pack-objects --keep-true-parents --honor-pack-keep --non-empty --all --reflog --indexed-objects --unpack-unreachable=2.weeks.ago --local --delta-base-offset /path/to/repo/.git/objects/pack/.tmp-14333-pack nd 14333 0.0 0.0 2452420920 ?? S 8:52PM 0:00.00 git repack -d -l -A --unpack-unreachable=2.weeks.ago nd 14331 0.0 0.0 2436036744 ?? Ss8:52PM 0:00.00 git gc --auto After the 14331 process termination all packs are gone. One more thing about my setup: since git p4 promotes a use of a linear history I use a separate repository for another branch in perforce. In order to be able to cherry-pick between repositories I added this another repo objects dir as an alternate and also added a ref which is a symbolic link to a branch in another repo (so I don't have to do any fetches). How do I troubleshoot the problem? Is there any way to enable a some kind of logging for automatic git gc? Can use of alternates or symbolic links in refs cause such a behavior? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: submodule update and core.askpass
BTW, a workaround is to pass a path to askpass script in the GIT_ASKPASS environment variable. Jens Lehmann jens.lehm...@web.de writes: Am 16.11.2013 22:42, schrieb Thomas Rast: Dmitry Neverov dmitry.neve...@jetbrains.com writes: git -c core.askpass=pass.sh clone main-repo cd main-repo git submodule init git submodule sync git -c core.askpass=pass.sh submodule update The last command asks for a password interactively. I've run bisect, it seems like it started failing from commit be8779f7ac9a3be9aa783df008d59082f4054f67. I've checked: submodule update works fine in 1.8.5.rc2 with removed call to clear_local_git_env. Aside from GIT_CONFIG_PARAMETERS, which this needs ... Yes, if I understand GIT_CONFIG_PARAMETERS correctly we should not clean it as the user explicitly asked us to use that setting. ..., I wonder if we should also let other variables pass through. For example, if the user went out of their way to set GIT_ALTERNATE_OBJECT_DIRECTORIES, shouldn't we also respect that? Hmm, I'm not so sure. Does the user really want the setting of GIT_ALTERNATE_OBJECT_DIRECTORIES to be honored inside the submodule too or would he want a different setting (including none)? I suspect different users would give different answers. And wouldn't a working GIT_CONFIG_PARAMETERS (or configuring the submodule after the initial clone) be the solution for that? The list of variables that is unset by clear_local_git_env is $(git rev-parse --local-env-vars), currently GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_CONFIG GIT_CONFIG_PARAMETERS GIT_OBJECT_DIRECTORY GIT_DIR GIT_WORK_TREE GIT_IMPLICIT_WORK_TREE GIT_GRAFT_FILE GIT_INDEX_FILE GIT_NO_REPLACE_OBJECTS GIT_PREFIX -- Dmitry Neverov JetBrains http://www.jetbrains.com Develop with pleasure! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
submodule update and core.askpass
Hi, it seems like git submodule update command doesn't respect the core.askpass option specified in a command line. I have a repository with a submodule, I serve it over http which requires an authorization and both main repository and submodule require the same credentials. I run the following commands (pass.sh is a script which prints a password to stdout): git -c core.askpass=pass.sh clone main-repo cd main-repo git submodule init git submodule sync git -c core.askpass=pass.sh submodule update The last command asks for a password interactively. I've run bisect, it seems like it started failing from commit be8779f7ac9a3be9aa783df008d59082f4054f67. I've checked: submodule update works fine in 1.8.5.rc2 with removed call to clear_local_git_env. Is there any way to make git submodule update respect core.askpass option, so one can use it in scripts? -- Dmitry Neverov -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
