Re: What's cooking in git.git (Mar 2016, #04; Wed, 23)
"Philip Oakley" writes: > This was just clarifying that if a variant of the bundle format (# > V3?) was used, that it must, if the name was retained(*), still work > as a sneakernet transfer option. In that case the user would need to > be told, or be able to find out via (e.g.) the 'verify' sub-command, > where the other half of the split bundle (the pack) was located so > that both halves could be copied for sneakernet transfer. I was sort-of expecting that users are intelligent enough to not even imagine to use split-bundle for sneakernetting, as it would be obvious that there is no upside for doing so. -- 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: What's cooking in git.git (Mar 2016, #04; Wed, 23)
From: "Junio C Hamano" "Philip Oakley" writes: The beginning of "split bundle", which could be one of the ingredients to allow "git clone" traffic off of the core server network to CDN. ... Hi Junio, I think there may be a concept clash between the ideals of a sneakernet bundle' and the 'resumable clone'. Notice the "could" above ;-) Read the original thread and notice that the inclination is for the first one the primary "clone priming" mechanism would likely to be a packfile, not a bundle, even though use of "bundle" is not ruled out. I'd seen the thread ($gmane/288380), and that it had developed toward a bare pack-file. This was just clarifying that if a variant of the bundle format (# V3?) was used, that it must, if the name was retained(*), still work as a sneakernet transfer option. In that case the user would need to be told, or be able to find out via (e.g.) the 'verify' sub-command, where the other half of the split bundle (the pack) was located so that both halves could be copied for sneakernet transfer. Then on reaching the destination, the user would need to appreciate where the two halves are to go (side by side?), and the code would need a way of knowing that it should use the local copy of the split pack, rather seeking to transfer a fresh copy (which obviously fails in an air-gapped scenario). (*) Changing the user facing names for the new resumable transfers to avoid the potential user confusion is a simple solution, which could just be a tweak to the final patch 4/4 c34c9a9db65 "bundle v3: the beginning". Perhaps explicitly use "split-bundle", though choosing a good alternative isn't easy ;-) As you say that all could become academic if the independent pack transfer works as a better resumable clone. -- Philip -- 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: What's cooking in git.git (Mar 2016, #04; Wed, 23)
"Philip Oakley" writes: >> >> The beginning of "split bundle", which could be one of the >> ingredients to allow "git clone" traffic off of the core server >> network to CDN. >> > ... > Hi Junio, > > I think there may be a concept clash between the ideals of a > sneakernet bundle' and the 'resumable clone'. Notice the "could" above ;-) Read the original thread and notice that the inclination is for the first one the primary "clone priming" mechanism would likely to be a packfile, not a bundle, even though use of "bundle" is not ruled out. -- 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: What's cooking in git.git (Mar 2016, #04; Wed, 23)
- Original Message - From: "Junio C Hamano" Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Three more minor fix-up topics are to be merged by 2.8 final, but we are almost there. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- ... [Cooking] * jc/bundle (2016-03-03) 6 commits - index-pack: --clone-bundle option - Merge branch 'jc/index-pack' into jc/bundle - bundle v3: the beginning - bundle: keep a copy of bundle file name in the in-core bundle header - bundle: plug resource leak - bundle doc: 'verify' is not about verifying the bundle (this branch uses jc/index-pack and jc/maint-index-pack-keep; is tangled with jc/index-pack-clone-bundle.) The beginning of "split bundle", which could be one of the ingredients to allow "git clone" traffic off of the core server network to CDN. ... Hi Junio, I think there may be a concept clash between the ideals of a 'sneakernet bundle' and the 'resumable clone'. The bundle capability still needs to work easily in sneakernet mode, and my reading of the proposed code for V3 (split-bundle) left the impression that it would be very hard for the user to do the manual transport of the files and place the split bundle in the right places such that a local clone from the bundle would still work. Part of the issue is getting the naming right so so that there is no confusion between the two opposing capabilities (on-line vs off-line transfer). There were a few other lesser point that I'll address when I have the right moment to reply to their respective messages. -- Philip -- 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
What's cooking in git.git (Mar 2016, #04; Wed, 23)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Three more minor fix-up topics are to be merged by 2.8 final, but we are almost there. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * jk/check-repository-format (2016-03-11) 10 commits - verify_repository_format: mark messages for translation - setup: drop repository_format_version global - setup: unify repository version callbacks - init: use setup.c's repo version verification - setup: refactor repo format reading and verification - config: drop git_config_early - check_repository_format_gently: stop using git_config_early - lazily load core.sharedrepository - wrap shared_repository global in get/set accessors - setup: document check_repository_format() The repository set-up sequence has been streamlined (the biggest change is that there is no longer git_config_early()), so that we do not attempt to look into refs/* when we know we do not have a Git repository. * mj/pull-rebase-autostash (2016-03-21) 2 commits (merged to 'next' on 2016-03-23 at ebf1afa) + pull --rebase: add --[no-]autostash flag + git-pull.c: introduce git_pull_config() "git pull --rebase" learned "--[no-]autostash" option, so that the rebase.autostash configuration variable set to true can be overridden from the command line. Will merge to 'master' after 2.8 final. * pb/commit-verbose-config (2016-03-14) 1 commit - commit: add a commit.verbose config variable (this branch uses pb/t7502-drop-dup.) "git commit" learned to pay attention to "commit.verbose" configuration variable and act as if "--verbose" option was given from the command line. * pb/t7502-drop-dup (2016-03-11) 1 commit (merged to 'next' on 2016-03-15 at 037c877) + t/t7502 : drop duplicate test (this branch is used by pb/commit-verbose-config.) Code clean-up. Will merge to 'master' after 2.8 final. * ss/commit-squash-msg (2016-03-21) 1 commit (merged to 'next' on 2016-03-23 at 0b72631) + commit: do not lose SQUASH_MSG contents When "git merge --squash" stopped due to conflict, the concluding "git commit" failed to read in the SQUASH_MSG that shows the log messages from all the squashed commits. Will merge to 'master' after 2.8 final. * ls/p4-map-user (2016-03-15) 1 commit (merged to 'next' on 2016-03-23 at 9e0a4f5) + git-p4: map a P4 user to Git author name and email address Will merge to 'master' after 2.8 final. * jc/merge-refuse-new-root (2016-03-23) 1 commit (merged to 'next' on 2016-03-23 at d7da4cf) + merge: refuse to create too cool a merge by default "git merge" used to allow merging two branches that have no common base by default, which led to a brand new history of an existing project created and then get pulled by an unsuspecting maintainer, which allowed an unnecessary parallel history merged into the existing project. The command has been taught not to allow this by default, with an escape hatch "--allow-unrelated-histories" option to be used in a rare event that merges histories of two projects that started their lives independently. Will merge to 'master' after 2.8 final. * jc/rerere-multi-wip (2016-03-21) 1 commit . WIP forget (this branch uses jc/rerere-multi.) * jk/credential-cache-comment-exit (2016-03-18) 1 commit (merged to 'next' on 2016-03-23 at d2b8cc7) + credential-cache--daemon: clarify "exit" action semantics Will merge to 'master' after 2.8 final. * jk/send-email-rtrim-mailrc-alias (2016-03-18) 1 commit (merged to 'next' on 2016-03-23 at 74f1f44) + send-email: ignore trailing whitespace in mailrc alias file Will merge to 'master' after 2.8 final. * jk/test-httpd-config-nosystem (2016-03-18) 1 commit (merged to 'next' on 2016-03-23 at 245263b) + t/lib-httpd: pass through GIT_CONFIG_NOSYSTEM env Will merge to 'master' after 2.8 final. * lt/pretty-expand-tabs (2016-03-17) 4 commits - pretty-print: add --pretty=noexpand - pretty-print: further abstract out pp_handle_indent() - pretty-print: simplify the interaction between pp_handle_indent() and its caller - pretty-print: de-tabify indented logs to make things line up properly Needs a UI rework. * sb/clone-shallow-passthru (2016-03-23) 3 commits - clone: add t5614 to test cloning submodules with shallowness involved - submodule clone: pass along `local` option - clone: add `--shallow-submodules` flag (this branch uses sb/submodule-parallel-update; is tangled with sb/submodule-init.) "git clone" learned "--shallow-submodules" option. Needs review. * sb/clone-t57-t56 (2016-03-16) 1 commit (merged to 'next' on 2016-03-23 at 5df850d)
