Contributing to git: cleaner git -rm & add configuration options
Hello everyone, I'm Mathieu LIENARD--MAYOR, a french student at Ensimag - Grenoble INP, and together with my fellow student Jorge GARCIA we will try to contribute to git as our school project. As of now, we are considering the implementation of the following two features: -Cleaner error message when "git rm" fails with multiple files (https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Cleaner_error_message_when_.22git_rm.22_fails_with_multiple_files) -Add configuration options for some commonly used command-line options (https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Add_configuration_options_for_some_commonly_used_command-line_options) Please let us know if you think those features are interesting choices, or if you have some ideas about how we should do it, or even if you have any comment at all. Best regards, Mathieu LIENARD--MAYOR & Jorge GARCIA -- 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
[PATCH 2/2] remote-hg: fix order of configuration comments
The other configurations were added in the wrong place. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-hg | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 88db7c4..198b962 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -25,9 +25,6 @@ import atexit import urlparse, hashlib # -# If you want to switch to hg-git compatibility mode: -# git config --global remote-hg.hg-git-compat true -# # If you are not in hg-git-compat mode and want to disable the tracking of # named branches: # git config --global remote-hg.track-branches false @@ -38,6 +35,9 @@ import urlparse, hashlib # If you want the equivalent of hg's clone/pull--insecure option: # git config --global remote-hg.insecure true # +# If you want to switch to hg-git compatibility mode: +# git config --global remote-hg.hg-git-compat true +# # git: # Sensible defaults for git. # hg bookmarks are exported as git branches, hg branches are prefixed -- 1.8.3.rc3.1.gf11a2b7.dirty -- 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
[PATCH 1/2] remote-hg: trivial configuration note cleanup
Follow the style of the previous configurations. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-hg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index beb864b..88db7c4 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -36,7 +36,7 @@ import urlparse, hashlib # git config --global remote-hg.force-push false # # If you want the equivalent of hg's clone/pull--insecure option: -# git config remote-hg.insecure true +# git config --global remote-hg.insecure true # # git: # Sensible defaults for git. -- 1.8.3.rc3.1.gf11a2b7.dirty -- 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
[PATCH 0/2] remote-hg: fix configuration notes
Hi, For 'master'. Felipe Contreras (2): remote-hg: trivial configuration note cleanup remote-hg: fix order of configuration comments contrib/remote-helpers/git-remote-hg | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 1.8.3.rc3.1.gf11a2b7.dirty -- 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
Fw:จับได้ว่า Ambranews ใช้ศาสนาเป็นอาวุธ
จับได้ว่า Ambranews ใช้ศาสนาเป็นอาวุธ
เมื่อต้นเดือนพฤษภาคมที่ผ่านมานี้ เวปไซต์ ambranews จัดตั้งและดำเนินงานอยู่
ในประเทศมาเลเซีย ได้นำเสนอข่าวเป็นภาษามาเลเซียโจมตีการทำงานของเจ้าหน้าที่ไทย
โดยใช้คำว่า คนมาลายู แทนคนไทยมุสลิมในจังหวัดชายแดนภาคใต้ต่อกรณียิงกราด 6
ศพว่าเป็นการกระทำของเจ้าหน้าที่ เพียงเพราะคนร้ายสวมกางเกงลายพรางแบบที่ทหาร
ใช้กันอยู่เท่านั้นเอง นอกจากนี้ยังได้เสนอบทความที่สร้างความแตกแยกระหว่างคนไทย
มุสลิมกับคนไทยพุทธว่า งานประเพณีของคนไทยขัดต่อหลักศาสนาอิสลาม โดย
ยกตัวอย่างงานกาชาดว่า ทำให้ คนมาลายู ไม่สบายใจเนื่องจากงานกาชาดมีดนตรีและ
การเต้นรำ มีผู้หญิงนุ่งสั้นขัดต่อหลักศาสนาอิสลาม ในพุทธศาสนาก็เช่นเดียวกัน
เห็นว่า
สถานที่ไม่ควรเข้าใกล้จัดอยู่ในประเภท อโคจร เหมือนกันก็แค่การเตือนสติไม่ได้นำไป
สร้างความแตกแยก เวปไซต์ ambranews นี้ อาศัยศาสนามาโฆษณาชวนเชื่อสร้างความ
แตกแยกให้กับคนไทยด้วยกัน เป้าหมายเดียวคือแบ่งแยกดินแดน จังหวัดชายแดนภาคใต้
ต้องปกครองด้วยหลักการของศาสนาอิสลามเท่านั้น แต่อย่าลืมไปซิว่าประเทศมาเลเซียเอง
ก็มีบ่อนคาสิโนถูกกฎหมาย มีสปาร์ คลับบาร์ มีเหล้ามีไวน์ขาย
ทำไมเวปไซต์นี้ไม่เสนอข่าว
ที่เรื่องเหล่านี้ของมาเลเซียว่าขัดต่อหลักศาสนา
หรือว่าเขาให้คุณกินอยู่แล้วมานั่งด่า
ประเทศไทยตามันมืดมองไม่เห็น
เป็นที่น่าเสียใจเป็นอย่างยิ่งที่ประเทศเป็นตัวกลางในการ
เจรจาแก้ปัญหาภาคใต้อย่างมาเลเซียยังปล่อยให้เวปไซต์นี้ นำเสนอข่าวสร้างความ
แตกแยกของคนไทยด้วยกันต่อไป
Nงฒๆ์rธy๚ุ่bฒXฌถวงvุ^)�บ{.nว+ท ุงถก�จ}ฉฒฦ
zฺ&j:+vจพซ๊็zZ+ส+zfฃขทhง~ญ�i�๛เzน ฎwฅขธ?จ่ญฺ&ข)฿ขf
[PATCH v2] transport-helper: check if the dry-run is supported
Certain remote-helpers (the ones with 'export') would try to push
regardless.
Obviously this is not what the user wants.
Also, add a check for the 'dry-run' option, so remote-helpers can
implement it.
Signed-off-by: Felipe Contreras
---
transport-helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/transport-helper.c b/transport-helper.c
index 522d791..c8c39fc 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -789,6 +789,11 @@ static int push_refs_with_export(struct transport
*transport,
struct string_list revlist_args = STRING_LIST_INIT_NODUP;
struct strbuf buf = STRBUF_INIT;
+ if (flags & TRANSPORT_PUSH_DRY_RUN) {
+ if (set_helper_option(transport, "dry-run", "true") != 0)
+ die("helper %s does not support dry-run", data->name);
+ }
+
helper = get_helper(transport);
write_constant(helper->in, "export\n");
--
1.8.3.rc3.1.gf11a2b7.dirty
--
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: [PATCH] transport-helper: barf when user tries --dry-run
On Mon, May 20, 2013 at 8:09 PM, Felipe Contreras
wrote:
> Certain remote-helpers (the ones with 'export') would try to push
> regardless.
>
> Obviously this is not what the user wants.
>
> Signed-off-by: Felipe Contreras
> ---
> transport-helper.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/transport-helper.c b/transport-helper.c
> index 522d791..daebdd9 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -789,6 +789,9 @@ static int push_refs_with_export(struct transport
> *transport,
> struct string_list revlist_args = STRING_LIST_INIT_NODUP;
> struct strbuf buf = STRBUF_INIT;
>
> + if (flags & TRANSPORT_PUSH_DRY_RUN)
> + die("helper %s does not support dry-run", data->name);
> +
> helper = get_helper(transport);
>
> write_constant(helper->in, "export\n");
> --
Actually, looking to the future, there's nothing that prevents
remote-helpers with 'export' to support dry-run, except this patch,
so:
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -789,6 +789,11 @@ static int push_refs_with_export(struct transport
*transport,
struct string_list revlist_args = STRING_LIST_INIT_NODUP;
struct strbuf buf = STRBUF_INIT;
+ if (flags & TRANSPORT_PUSH_DRY_RUN) {
+ if (set_helper_option(transport, "dry-run", "true") != 0)
+ die("helper %s does not support dry-run", data->name);
+ }
+
helper = get_helper(transport);
write_constant(helper->in, "export\n");
--
Felipe Contreras
--
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 (May 2013, #05; Mon, 20)
On Tue, May 21, 2013 at 2:15 AM, Junio C Hamano wrote: > * jh/shorten-refname (2013-05-07) 4 commits > - t1514: refname shortening is done after dereferencing symbolic refs > - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to > origin > - t1514: Demonstrate failure to correctly shorten "refs/remotes/origin/HEAD" > - t1514: Add tests of shortening refnames in strict/loose mode > > When remotes/origin/HEAD is not a symbolic ref, "rev-parse > --abbrev-ref remotes/origin/HEAD" ought to show "origin", not > "origin/HEAD", which is fixed with this series (if it is a symbolic > ref that points at remotes/origin/something, then it should show > "origin/something" and it already does). > > I think this is being rerolled using strbuf_expand(). Actually, that was not on my TODO. Sure, my other series ([PATCHv2 00/10] Prepare for alternative remote-tracking branch location) builds on top of this one, and changes a lot of the same code, but I considered jh/shorten-refname a good set of changes in its own right, and I didn't want it to be held up by the much longer (and probably much longer-running) series. The strbuf_expand refactoring is nice, but not really necessary until we start using multi-wildcard patterns. ...Johan -- Johan Herland, www.herland.net -- 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
[PATCH] transport-helper: barf when user tries --dry-run
Certain remote-helpers (the ones with 'export') would try to push
regardless.
Obviously this is not what the user wants.
Signed-off-by: Felipe Contreras
---
transport-helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/transport-helper.c b/transport-helper.c
index 522d791..daebdd9 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -789,6 +789,9 @@ static int push_refs_with_export(struct transport
*transport,
struct string_list revlist_args = STRING_LIST_INIT_NODUP;
struct strbuf buf = STRBUF_INIT;
+ if (flags & TRANSPORT_PUSH_DRY_RUN)
+ die("helper %s does not support dry-run", data->name);
+
helper = get_helper(transport);
write_constant(helper->in, "export\n");
--
1.8.3.rc3.dirty
--
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
[PATCH] transport-helper: barf when user tries old:new
Otherwise with certain remote helpers (the ones that support 'export'),
the users will be pushing to the wrong branch:
git push topic:master
Will push the topic branch, as if the user typed:
git push topic
Signed-off-by: Felipe Contreras
---
I did fix this properly, but was beaten by shoots from the hip[1]. I won't
bother rationalizing if this makes sense for 'master', or writing tests. This
patch can't possibly make anything worst. If somebody is interested, there's
proper fix: [1], with explanation, tests, and everything.
[1] http://article.gmane.org/gmane.comp.version-control.git/223706
transport-helper.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 522d791..a782a9b 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -813,9 +813,11 @@ static int push_refs_with_export(struct transport
*transport,
die("remote-helpers do not support ref deletion");
}
- if (ref->peer_ref)
+ if (ref->peer_ref) {
+ if (strcmp(ref->peer_ref->name, ref->name))
+ die("remote-helpers do not support old:new
syntax");
string_list_append(&revlist_args, ref->peer_ref->name);
-
+ }
}
if (get_exporter(transport, &exporter, &revlist_args))
--
1.8.3.rc3.1.gf572ce5.dirty
--
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
Workflow Help
Hi, I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successful-git-branching-model, with a few exceptions. We would like to create our release-* branches from the last release tag. From there, we would like the ability to cherry pick (or take the complete diff) commits from the develop branch. So, we are after is: 1) Create topic (feature) branches from develop, and merge back into develop when complete. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. 4) Merge the new release-* branch into master and tag it. Repeat as necessary. At the moment I am a little stuck on how exactly we can cherry pick stuff from develop into a release-* branch. I'm not even sure this approach is exactly what we should be doing. Our main concern is that at this stage, there is no guarantee that all commits within develop can be pulled into a release. In regards to how we can achieve the above results any input would be much appreciated. Or if there are any other better options available, I'm all ears. Thanks, Tony Quilkey -- 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: [PATCH] completion: trivial fix for zsh
On Mon, May 20, 2013 at 7:33 PM, Felipe Contreras wrote: > zsh completion wrapper doesn't reimplement __gitcompadd(). Although it > should be trivial to do that, let's use __gitcomp_nl() which achieves > exactly the same thing, specially since the suffix ($4) has to be empty. > > Signed-off-by: Felipe Contreras This is probably v1.8.3 material, I just noticed it's probably a regression introduced by 1ce23aa (completion: add new __gitcompadd helper). -- Felipe Contreras -- 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
[PATCH] completion: trivial fix for zsh
zsh completion wrapper doesn't reimplement __gitcompadd(). Although it
should be trivial to do that, let's use __gitcomp_nl() which achieves
exactly the same thing, specially since the suffix ($4) has to be empty.
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index a98c2fd..1c35eef 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1831,7 +1831,7 @@ _git_config ()
local remote="${prev#remote.}"
remote="${remote%.fetch}"
if [ -z "$cur" ]; then
- __gitcompadd "refs/heads/" "" "" ""
+ __gitcomp_nl "refs/heads/" "" "" ""
return
fi
__gitcomp_nl "$(__git_refs_remotes "$remote")"
--
1.8.3.rc3.286.g3d43083
--
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 (May 2013, #05; Mon, 20)
On Mon, May 20, 2013 at 7:15 PM, Junio C Hamano wrote:
> * fc/at-head (2013-05-08) 13 commits
> - sha1_name: compare variable with constant, not constant with variable
> - Add new @ shortcut for HEAD
> - sha1_name: refactor reinterpret()
> - sha1_name: check @{-N} errors sooner
> - sha1_name: reorganize get_sha1_basic()
> - sha1_name: don't waste cycles in the @-parsing loop
> - sha1_name: remove unnecessary braces
> - sha1_name: remove no-op
> - tests: at-combinations: @{N} versus HEAD@{N}
> - tests: at-combinations: increase coverage
> - tests: at-combinations: improve nonsense()
> - tests: at-combinations: check ref names directly
> - tests: at-combinations: simplify setup
>
> Instead of typing four capital letters "HEAD", you can say "@"
> instead.
This is not ready for next? Note that I specifically split the two
commits that were needed, the rest can wait.
--
Felipe Contreras
--
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 (May 2013, #05; Mon, 20)
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 final version of 1.8.3 is expected to be tagged late this week. While applying a few regression hot-fix patches, a couple of benign doc updates have also been merged to 'master'. 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 -- [Graduated to "master"] * dw/asciidoc-sources-are-dot-txt-files (2013-05-10) 1 commit - CodingGuidelines: Documentation/*.txt are the sources * fc/doc-style (2013-05-09) 1 commit - documentation: trivial style cleanups -- [New Topics] * fc/remote-bzr (2013-05-16) 6 commits - remote-bzr: trivial cleanups - remote-bzr: change global repo - remote-bzr: delay cloning/pulling - remote-bzr: simplify get_remote_branch() - remote-bzr: fix for files with spaces - remote-bzr: recover from failed clones The ones near the tip conflicted with the hotfix for 1.8.3 so I discarded them for now. * jx/clean-interactive (2013-05-20) 15 commits - test: add t7301 for git-clean--interactive - git-clean: add documentation for interactive git-clean - git-clean: add ask each interactive action - git-clean: add select by numbers interactive action - git-clean: add filter by pattern interactive action - git-clean: use a git-add-interactive compatible UI - git-clean: add colors to interactive git-clean - git-clean: show items of del_list in columns - git-clean: add support for -i/--interactive - git-clean: refactor git-clean into two phases - Refactor write_name_quoted_relative, remove unused params - Refactor quote_path_relative, remove unused params - quote.c: remove path_relative, use relative_path instead - path.c: refactor relative_path(), not only strip prefix - test: add test cases for relative_path * tr/test-v-and-v-subtest-only (2013-05-16) 6 commits - test-lib: support running tests under valgrind in parallel - test-lib: allow prefixing a custom string before "ok N" etc. - test-lib: valgrind for only tests matching a pattern - test-lib: verbose mode for only tests matching a pattern - test-lib: refactor $GIT_SKIP_TESTS matching - test-lib: enable MALLOC_* for the actual tests Allows N instances of tests run in parallel, each running 1/N parts of the test suite under Valgrind, to speed things up. The tip one may be useful in practice but is a tad ugly ;-) * rh/merge-options-doc-fix (2013-05-16) 1 commit - Documentation/merge-options.txt: restore `-e` option Even though it is not all that urgent, this can be merged to 'master' before the final, * rr/zsh-color-prompt (2013-05-17) 3 commits - prompt: colorize ZSH prompt - prompt: factor out gitstring coloring logic - prompt: introduce GIT_PS1_STATESEPARATOR * an/diff-index-doc (2013-05-20) 1 commit - Documentation/diff-index: mention two modes of operation * fc/contrib-related (2013-05-20) 1 commit - Add new git-related helper to contrib * mc/describe-first-parent (2013-05-20) 1 commit - describe: Add --first-parent option * rs/tar-tests (2013-05-20) 6 commits - t5000: test long filenames - t5000: simplify tar-tree tests - t5000: use check_tar for prefix test - t5000: factor out check_tar - t5000, t5003: create directories for extracted files lazily - t5000: integrate export-subst tests into regular tests -- [Stalled] * mh/multimail (2013-04-21) 1 commit - git-multimail: a replacement for post-receive-email Waiting for the initial history to pull from. $gmane/223564 * jc/format-patch (2013-04-22) 2 commits - format-patch: --inline-single - format-patch: rename "no_inline" field A new option to send a single patch to the standard output to be appended at the bottom of a message. I personally have no need for this, but it was easy enough to cobble together. Tests, docs and stripping out more MIMEy stuff are left as exercises to interested parties. Not ready for inclusion. * jk/gitweb-utf8 (2013-04-08) 4 commits - gitweb: Fix broken blob action parameters on blob/commitdiff pages - gitweb: Don't append ';js=(0|1)' to external links - gitweb: Make feed title valid utf8 - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch Various fixes to gitweb. Waiting for a reroll after a review. * jk/commit-info-slab (2013-04-19) 3 commits - commit-slab: introduce a macro to define a slab for new type - commit-slab: avoid large realloc - commit: allow associating auxiliary info on-demand (this branch is used by jc/show-branch.) Technology demonstration to show a way we could use unbound number of flag bits on commit objects. * jn/config-ignore-inaccessible (2013-04-15) 1 commit (merged to 'next' on 2013-05
Re: [PATCH 0/2] remote-helpers: test fixes
On Mon, May 20, 2013 at 6:13 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Mon, May 20, 2013 at 5:47 PM, Junio C Hamano wrote: >>> Felipe Contreras writes: >>> Hi, I've setup a project in Travis CI for continuous integration with very good results, however, I had to apply a couple of fixes. I'm not sure if this is v1.8.3 material, but here they are. >>> >>> Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon >>> after 1.8.3, then. >> >> No, they should be graduated first. The tip of fc/remote-hg is in pu, >> no? I have rebased that branch and squashed some fixes so every commit >> works on all versions of Mercurial. I will resend all the patches, the >> only reason I haven't done so is that I didn't want to create more >> noise before v1.8.3, and you said I was the one taking the decision >> when to merge remote-helper stuff to master. > > Then is this v1.8.3 material? Please do not stay "I'm not sure" for > very long. I do not think we want -rc4 only for a contrib/ stuff. I think this could very well fit into v1.8.3, but there's no rush, it can wait until after. > For today's integration run I didn't want to wait so tentatively > they are queued at the tip of fc/remote-hg, and it is too late to > redo everything I did today, but I can requeue them for 'master' in > the tomorrow's cycle if you want. I think 'next' is fine, they could go into 'master' to improve the testing of what's already there, but it probably won't matter much. Moreover, it's not fixing test regressions; the issues have been there pretty much since day one, and if nobody has found them by now it probably won't change anything for v1.8.3. My main motivation is that with these patches I could test a pristine 'master' branch directly into travis-ci. -- Felipe Contreras -- 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: [PATCH 0/2] remote-helpers: test fixes
Felipe Contreras writes: > On Mon, May 20, 2013 at 5:47 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> >>> Hi, >>> >>> I've setup a project in Travis CI for continuous integration with very good >>> results, however, I had to apply a couple of fixes. >>> >>> I'm not sure if this is v1.8.3 material, but here they are. >> >> Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon >> after 1.8.3, then. > > No, they should be graduated first. The tip of fc/remote-hg is in pu, > no? I have rebased that branch and squashed some fixes so every commit > works on all versions of Mercurial. I will resend all the patches, the > only reason I haven't done so is that I didn't want to create more > noise before v1.8.3, and you said I was the one taking the decision > when to merge remote-helper stuff to master. Then is this v1.8.3 material? Please do not stay "I'm not sure" for very long. I do not think we want -rc4 only for a contrib/ stuff. For today's integration run I didn't want to wait so tentatively they are queued at the tip of fc/remote-hg, and it is too late to redo everything I did today, but I can requeue them for 'master' in the tomorrow's cycle if you want. -- 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: [PATCH v2] git-svn: introduce --parents parameter for commands branch and tag
Eric Wong writes: > Junio C Hamano wrote: >> Thanks; is it a good time for me to pull? > > Yes, I think so. Thanks! > > The following changes since commit de3a5c6da194928868b5eee4a9c4d538b4194727: > > Git 1.8.3-rc3 (2013-05-17 12:19:20 -0700) > > are available in the git repository at: > > git://git.bogomips.org/git-svn.git master > > for you to fetch changes up to f4f4c7fc00e8acf91150c717cf005fc36c1dd120: > > git-svn: introduce --parents parameter for commands branch and tag > (2013-05-20 22:05:54 +) Will pull; it looked somewhat funny that the two commits from others are both from Dec 2011, but I see Jonathan reminded us of them about a week ago, so all look kosher ;-) Thanks. > > > Jonathan Nieder (1): > git-svn: clarify explanation of --destination argument > > Nathan Gray (1): > git-svn: multiple fetch/branches/tags keys are supported > > Tobias Schulte (1): > git-svn: introduce --parents parameter for commands branch and tag > > Documentation/git-svn.txt| 36 > git-svn.perl | 19 - > t/t9167-git-svn-cmd-branch-subproject.sh | 48 > > 3 files changed, 97 insertions(+), 6 deletions(-) > create mode 100755 t/t9167-git-svn-cmd-branch-subproject.sh -- 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 (May 2013, #04; Wed, 15)
On Wed, May 15, 2013 at 6:42 PM, Junio C Hamano wrote: > * fc/completion (2013-04-27) 9 commits > - completion: remove __git_index_file_list_filter() > - completion: add space after completed filename > - completion: add hack to enable file mode in bash < 4 > - completion: refactor __git_complete_index_file() > - completion: refactor diff_index wrappers > - completion: use __gitcompadd for __gitcomp_file > - completion; remove unuseful comments > - completion: document tilde expansion failure in tests > - completion: add file completion tests > > I saw this discussed somewhat. Is everybody happy with this > version? This is its v2, in the $gmane/222682 thread. I think we've waited long enough for feedback. I already demonstrated that this fixes regressions, and I tested that works on all relevant versions of bash. -- Felipe Contreras -- 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: [PATCH 0/2] remote-helpers: test fixes
On Mon, May 20, 2013 at 5:47 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Hi, >> >> I've setup a project in Travis CI for continuous integration with very good >> results, however, I had to apply a couple of fixes. >> >> I'm not sure if this is v1.8.3 material, but here they are. > > Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon > after 1.8.3, then. No, they should be graduated first. The tip of fc/remote-hg is in pu, no? I have rebased that branch and squashed some fixes so every commit works on all versions of Mercurial. I will resend all the patches, the only reason I haven't done so is that I didn't want to create more noise before v1.8.3, and you said I was the one taking the decision when to merge remote-helper stuff to master. So this should go to master, the rest of fc/remote-hg should be dropped, I can resend any time, and I suppose after v1.8.3 is the best time. -- Felipe Contreras -- 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: [PATCH v8 0/3] Begin replacing OpenSSL with CommonCrypto
Thanks, will replace da/darwin with this round. -- 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: [PATCH v12 00/15] Interactive git-clean
Will replace what has been queued on 'pu' with trivial style fixups (haven't had a chance to make time to read it through). Thanks. -- 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: [PATCH 0/6] t5000: add test for pax extended header generation
Thanks, will queue. -- 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-diff-index man page
Jonathan Nieder writes: > Thanks and hope that helps, > Jonathan Thanks, the result reads much better, I think. Albert? > diff --git i/Documentation/git-diff-index.txt > w/Documentation/git-diff-index.txt > index 58308e15..a86cf62e 100644 > --- i/Documentation/git-diff-index.txt > +++ w/Documentation/git-diff-index.txt > @@ -3,7 +3,7 @@ git-diff-index(1) > > NAME > > -git-diff-index - Compare a tree and the working tree or the index > +git-diff-index - Compare a tree to the working tree or index > > > SYNOPSIS > @@ -13,12 +13,11 @@ SYNOPSIS > > DESCRIPTION > --- > - > -Compare the content and mode of the blobs found in a tree object > -with the corresponding tracked file in the working tree, or with the > -corresponding paths in the index. When paths are specified, > -compares only those named paths. Otherwise all entries in the index > -are compared. > +Compares the content and mode of the blobs found in a tree object > +with the corresponding tracked files in the working tree, or with the > +corresponding paths in the index. When arguments are present, > +compares only paths matching those patterns. Otherwise all tracked > +files are compared. > > OPTIONS > --- -- 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: [PATCH v2] describe: Add --first-parent option
Thanks, will queue. -- 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: [PATCH 0/2] remote-helpers: test fixes
Felipe Contreras writes: > Hi, > > I've setup a project in Travis CI for continuous integration with very good > results, however, I had to apply a couple of fixes. > > I'm not sure if this is v1.8.3 material, but here they are. Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon after 1.8.3, then. > > https://travis-ci.org/felipec/git/builds/7262886 > > Felipe Contreras (2): > remote-helpers: tests: use python directly > remote-hg: tests: fix hg merge > > contrib/remote-helpers/test-bzr.sh | 2 +- > contrib/remote-helpers/test-hg-bidi.sh | 2 +- > contrib/remote-helpers/test-hg-hg-git.sh | 11 ++- > contrib/remote-helpers/test-hg.sh| 2 +- > 4 files changed, 9 insertions(+), 8 deletions(-) -- 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: [PATCH v2] git-svn: introduce --parents parameter for commands branch and tag
Junio C Hamano wrote: > Thanks; is it a good time for me to pull? Yes, I think so. Thanks! The following changes since commit de3a5c6da194928868b5eee4a9c4d538b4194727: Git 1.8.3-rc3 (2013-05-17 12:19:20 -0700) are available in the git repository at: git://git.bogomips.org/git-svn.git master for you to fetch changes up to f4f4c7fc00e8acf91150c717cf005fc36c1dd120: git-svn: introduce --parents parameter for commands branch and tag (2013-05-20 22:05:54 +) Jonathan Nieder (1): git-svn: clarify explanation of --destination argument Nathan Gray (1): git-svn: multiple fetch/branches/tags keys are supported Tobias Schulte (1): git-svn: introduce --parents parameter for commands branch and tag Documentation/git-svn.txt| 36 git-svn.perl | 19 - t/t9167-git-svn-cmd-branch-subproject.sh | 48 3 files changed, 97 insertions(+), 6 deletions(-) create mode 100755 t/t9167-git-svn-cmd-branch-subproject.sh -- Eric Wong -- 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: [PATCH v2] git-svn: introduce --parents parameter for commands branch and tag
Eric Wong writes: > Tobias Schulte wrote: >> This parameter is equivalent to the parameter --parents on svn cp commands >> and is useful for non-standard repository layouts. >> >> Signed-off-by: Tobias Schulte > > Signed-off-by: Eric Wong > > Applied and pushed, thanks. Thanks; is it a good time for me to pull? -- 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: [PATCH] contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
Dmitry Marakasov writes: > Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree: > it's required for systems which don't use bash by default (for example, > FreeBSD), while there seem to be no bashisms in the script (confirmed > by looking through the source and tesing subtree functionality with > FreeBSD's /bin/sh) to require specifically bash and not the generic > posix shell. Has anybody audited to make sure that the script itself is free of bash-isms? I somehow had an impression that in the past it was littered with bash-isms like function local variables and array variables and assumed that the #!/bin/bash was necessary. I did a quick eyeballing and did not see anything glaringly bash-only, but I may have missed something (the coding style is so different from the core part of Git Porcelains and distracting for me to efficiently do a good job of scanning). > > Signed-off-by: Dmitry Marakasov > --- > contrib/subtree/git-subtree.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh > index 8a23f58..5701376 100755 > --- a/contrib/subtree/git-subtree.sh > +++ b/contrib/subtree/git-subtree.sh > @@ -1,4 +1,4 @@ > -#!/bin/bash > +#!/bin/sh > # > # git-subtree.sh: split/join git repositories in subdirectories of this one > # -- 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: [RFC/PATCH 1/2] Doc rebase: Describe rebase as excluding merge commits
"Philip Oakley" writes: > From: "Junio C Hamano" > Sent: Monday, May 20, 2013 5:43 AM >> Jonathan Nieder writes: >> >>> Philip Oakley wrote: >>> Describe rebase in the description section. >>> >>> It already does that. :) I think you mean "start with a summary", >>> which is a valuable improvement. >> >> It indeed is a good idea to give the "high-level introduction" at >> the very beginning, but I do not think it should describe only one >> of the three major modes of "git rebase" (i.e. no -m, no -i), like >> the proposed patch text does. We should instead say what it is used >> for and why the user would want to use it that is common across >> these modes at a very high level. > > That would repeat the NAME issue (of trying too hard to be exact & > precise). This introductory text is that "summary". If that is "summary", it should never talk about "skips merges", which only applies to the mode without -m, no? The highest level view of what the command is for (the motivation why the user would want to consider learning how to use the command) is "You have a history built on top of some commit, and you want to rebuild the history on top of another commit, e.g. you earlier built on the tip of a branch that has some other work, and you want to rebuild the history on top of the updated tip of that other branch". The details of how the history is "rebuilt" can differ while using various modes of operation. Some may skip merges, some may try to preserve the topology, some may even let you insert new commits by letting you tell it to stop in the middle. That is not "summary" but is part of mode specific description. -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
"Philip Oakley" writes:
> So we can have a branch whose remote is '.'
> _and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
"git fetch" while on "mywork" branch with this:
[branch "mywork"]
remote = git://git.k.org/pub/scm/git/git.git
merge = refs/heads/master
without having any named remote whose remote.$name.url is set to
that URL may happen to work but it is by accident as far as I know.
As you do not copy to any remote tracking branches, @{u} would not
work, so it is not something useful. But on the other hand
[branch "mywork"]
remote = .
merge = refs/heads/master
works _as if_ you have
[remote "."]
url = "."
;; no fetch refspec like +refs/heads/*:refs/heads/*
;; no push refspec like +refs/heads/*:refs/heads/*
so in that sense, you _could_ think of branch.$name.remote as a
(generic) URL or a name of a (special) remote, but it is easier to
think about it as the latter.
And remote.$name.url = "." for any name, e.g.
[remote "here"]
url = "."
is a special case of local repository that is named with a relative
filesystem path.
> Can there be a clash with a named remote that is actually '.', where
> the push/fetch is actually a no-op?
Nobody sane would do it in the first place, 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: [PATCH v2] git-svn: introduce --parents parameter for commands branch and tag
Tobias Schulte wrote: > This parameter is equivalent to the parameter --parents on svn cp commands > and is useful for non-standard repository layouts. > > Signed-off-by: Tobias Schulte Signed-off-by: Eric Wong Applied and pushed, thanks. -- 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: [RFC/PATCH 1/2] Doc rebase: Describe rebase as excluding merge commits
From: "Junio C Hamano" Sent: Monday, May 20, 2013 5:43 AM Jonathan Nieder writes: Philip Oakley wrote: Describe rebase in the description section. It already does that. :) I think you mean "start with a summary", which is a valuable improvement. It indeed is a good idea to give the "high-level introduction" at the very beginning, but I do not think it should describe only one of the three major modes of "git rebase" (i.e. no -m, no -i), like the proposed patch text does. We should instead say what it is used for and why the user would want to use it that is common across these modes at a very high level. That would repeat the NAME issue (of trying too hard to be exact & precise). This introductory text is that "summary". The patch 2/2 should be the one for the extra detail of the various whys and wherefores - at least that was my intent. DESCRIPTION --- token mention of *why* a user would want to use it (e.g., "so that the patches apply cleanly to their new base").> Exactly. -- -- 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: [RFC 16/17] object_array_entry: copy name before storing in name field
On 05/20/2013 06:44 PM, Jeff King wrote:
> On Mon, May 20, 2013 at 04:42:38PM +0200, Michael Haggerty wrote:
>
* Many callers store the empty string ("") as the name; for example,
most of the entries created during a run of rev-list have "" as
their name. This means that lots of needless copies of "" are being
made. I think that the best solution to this problem would be to
store NULL rather than "" for such entries, but I haven't figured
out all of the places where the name is used.
>>>
>>> Use strbufs?
>>>
>>> No allocation (except for the strbuf object itself) is needed for
>>> empty strings, and string ownership and be transferred to and from it
>>> to prevent extra copies.
>>
>> That would cost two extra size_t per object_array_entry. I have the
>> feeling that this structure is used often enough that the extra overhead
>> would be a disadvantage, but I'm not sure.
>>
>> The obvious alternative would be to teach users to deal with NULL and
>> either add another constructor alternative that transfers string
>> ownership or *always* transfer string ownership and change the callers
>> to call xstrdup() if they don't already own the name string. I think I
>> will try that approach first.
>
> You could use the same trick that strbuf does: instead of NULL, point to
> a well-known empty string literal. Readers do not have to care about
> this optimization at all; only writers need to recognize the well-known
> pointer value. And since we do not update in place but only eventually
> free, it really is just that anyone calling free() would do "if (name !=
> well_known_empty_string)".
Yes, that sounds like the best solution. Ultimately there is only one
writer, add_object_array_with_mode(), and it can do
if (!name)
entry->name = NULL;
else if (!*name)
entry->name = well_known_empty_string;
else
entry->name = xstrdup(name);
This should be a lot less intrusive than what I was trying: to change
callers who wrote name="" to write name=NULL instead. But it is a
nightmare to find all of the code that reads name and decide whether
they need to do
entry->name ? entry->name : ""
because that in turn depends on whether the code that wrote into the
same object_array always/never/sometimes wrote strings vs. NULL to the
name field. Blech, encapsulation is tough in C.
While I was chasing down callers, I came across other gems like
builtin/checkout.c:
add_pending_object(&revs, object, sha1_to_hex(object->sha1));
revision.c:
add_pending_object(revs, object, sha1_to_hex(object->sha1));
submodule.c:
add_pending_object(rev, &list->item->object,
sha1_to_hex(list->item->object.sha1));
so apparently I wasn't the only one befuddled by the lifetime and
ownership of the name field of object_array_entry.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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: [RFC/PATCH 1/2] config doc: add dot-repository note
From: "Junio C Hamano"
Sent: Monday, May 20, 2013 6:50 PM
Jonathan Nieder writes:
Philip Oakley wrote:
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -734,6 +734,8 @@ branch..remote::
overridden by `branch..pushremote`. If no remote is
configured, or if you are not on any branch, it defaults to
`origin` for fetching and `remote.pushdefault` for pushing.
+ Additionally, a `.` (period) means the current local repository
+ (a dot-repository), see `branch..merge`'s final note below.
Does this accept an arbitrary git URL, or only remote names?
The branch..remote variable refers to remote names, and '.'
often appears as a special name to refer to the local repository.
Initially I thought that the '.' wasn't going to be acceptable as a URL,
and that the '.' would only apply to the defined of the remote
within the branch section.
I think you can define it as URL and your "git fetch" (no args) will
do the right thing in that it would:
(1) fetch the history leading to the tip branch..merge branch
from there; and
(2) leave the result in FETCH_HEAD, so that "git merge FETCH_HEAD"
can conclude the "git pull" you split into two manually by
running "git fetch" first,
but I do not think there is a "while we create this branch" side
effect UI like "--set-upstream-to" for doing so, except for setting
it to '.' when you set upstream to a branch in the local repository.
I.e.
git checkout -t -b mywork master
git branch --set-upstream-to master mywork
Also I think setting it to arbitrary URL would mean that you would
not see any remote tracking ref (they are to be defined as a
property of named remote with remote..fetch refspecs), so it
is unclear how @{u} would work. @{u} works when the variable is set
to '.', though.
For the above reasons, describing '.' as a special value for the
variable that the end users are likely to see is a reasonable "white
lie" for this part of the documentation.
OK.
--
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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
From: "Junio C Hamano" Sent: Monday, May 20, 2013 6:55 PM Jonathan Nieder writes: --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm hello.c`, you will _not_ see `hello.c` in your working tree with the former, but with the latter you will. +Just as, by convention, the filesystem '.' refers to the current directory, +using a '.' (period) as a repository name in Git (a dot-repository) refers +to your local repository. Good idea, but I fear that no one would find it there. Also I think it would be better without ", by convention,". If you say '.' == current directory is "a convention", you have to start saying that "by convention", "hello.c" refers to the file in the current directory of that name, which may be technically correct but make the phrase "by convention" meaningless. A dot "." is *the* name for the current directory, just like "hello.c" is the name for that file. The part I had previously needed clearing up was if the '.' was in some way expanded by the shell, or whether the file system commands interpreted it by themselves for that specific purpose. So in this case Git sees the single character and has to decide what to do with it. Just like '.' refers to the current directory in the filesystem, '.' refers to the current repository. would be sufficient. Would it make sense to put this in Documentation/urls.txt (aka the "GIT URLS" section of git-fetch(1) and git-clone(1)), where other URL schemes are documented? Yes, the '.' described above is a special case of giving a repository URL as a relative-path on the filesystem. So we can have a branch whose remote is '.' _and_ a remote whose URL is '.' Hence we/one/I could declare a remote called 'home' whose URL is '.' (with my 'away' remote on Github - just thinking aloud of the upstream / downstream / across-stream discussions!) Can there be a clash with a named remote that is actually '.', where the push/fetch is actually a no-op? 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
[PATCH] contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree: it's required for systems which don't use bash by default (for example, FreeBSD), while there seem to be no bashisms in the script (confirmed by looking through the source and tesing subtree functionality with FreeBSD's /bin/sh) to require specifically bash and not the generic posix shell. Signed-off-by: Dmitry Marakasov --- contrib/subtree/git-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 8a23f58..5701376 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/bin/sh # # git-subtree.sh: split/join git repositories in subdirectories of this one # -- 1.8.2.3 -- 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: [PATCH 3/6] t5000: factor out check_tar
Am 20.05.2013 21:54, schrieb Eric Sunshine:
On Mon, May 20, 2013 at 5:58 AM, René Scharfe
wrote:
+check_tar() {
+ tarfile=$1.tar
+ listfile=$1.lst
+ dir=$1
+ dir_with_prefix=$dir/$2
+
+ test_expect_success ' extract tar archive' '
s/' extract/'extract/
It might be a bit hackish, but I added that single space here and in the
three other cases intentionally in order to designate sub-tests.
René
--
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: [PATCH 1/6] t5000: integrate export-subst tests into regular tests
Am 20.05.2013 21:53, schrieb Eric Sunshine: On Mon, May 20, 2013 at 5:58 AM, René Scharfe wrote: Instead of creating extra archives for testing substitutions, set the attribute export-subst and overwrite the marked file with the expected (expanded) content right between commiting and archiving. Thus s/commiting/committing/ placeholder expansion based on the committed content is performed with each archive creation and the comparision with the contents of directory s/comparision/comparison/ My spelling is getting worse and worse. René -- 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
[no subject]
unsubscribe git -- 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: [PATCH 6/6] t5000: test long filenames
On Mon, May 20, 2013 at 5:58 AM, René Scharfe
wrote:
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index a1f35d2..c2023b1 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -40,6 +66,24 @@ check_tar() {
> (mkdir $dir && cd $dir && "$TAR" xf -) <$tarfile
> '
>
> + test_expect_success TAR_NEEDS_PAX_FALLBACK ' interpret pax headers' '
s/' interpret/'interpret/
> + (
> + cd $dir &&
> + for header in *.paxheader
> + do
> + data=${header%.paxheader}.data &&
> + if test -h $data -o -e $data
> + then
> + path=$(get_pax_header $header path) &&
> + if test -n "$path"
> + then
> + mv "$data" "$path"
> + fi
> + fi
> + done
> + )
> + '
> +
> test_expect_success ' validate filenames' '
> (cd ${dir_with_prefix}a && find .) | sort >$listfile &&
> test_cmp a.lst $listfile
> @@ -54,6 +98,8 @@ test_expect_success \
> 'populate workdir' \
> 'mkdir a &&
> echo simple textfile >a/a &&
> + ten=0123456789 && hundred=$ten$ten$ten$ten$ten$ten$ten$ten$ten$ten &&
> + echo long filename >a/four$hundred &&
> mkdir a/bin &&
> cp /bin/sh a/bin &&
> printf "A\$Format:%s\$O" "$SUBSTFORMAT" >a/substfile1 &&
> diff --git a/t/t5000/pax.tar b/t/t5000/pax.tar
> new file mode 100644
> index
> ..d91173714991fded560fcd6a8aaec6aa6ec7f5e8
> GIT binary patch
> literal 10240
> zcmeIy%?g4*5Ww+0_Y^*X&3@?Sp?k+(L29F*2+YXGPl*s(6d@sk|6W#S)Sdakm@c zvkB!sRJT<7LN5=eb5OG`X;h^Yh?xL+x+Gv-HHCB5i+IVkN(#%@Lz{l>lx~$rg
> z2GWzmuipCRCcpUG2dyNR`g93vZSz%O3b*p9Sn-k>pDo&KIhx%KXMfulr%w}@f7;`7
> zyU`e%|L&jgG5=zmO1_@SxRf~Zp8x84t>bJTc^pGH_qWm2pU!{O2LS{SKmY**5I_I{
> l1Q0*~0R#|0009ILKmY**5I_I{1Q0*~0R#|00D->}cmml}KZ5`O
>
> literal 0
> HcmV?d1
--
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: [PATCH 3/6] t5000: factor out check_tar
On Mon, May 20, 2013 at 5:58 AM, René Scharfe
wrote:
> Create a helper function that extracts a tar archive and checks its
> contents, modelled after check_zip in t5003.
>
> Signed-off-by: René Scharfe
> ---
> t/t5000-tar-tree.sh | 35 ++-
> 1 file changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index 41cd609..8337a1f 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -30,6 +30,26 @@ GUNZIP=${GUNZIP:-gzip -d}
>
> SUBSTFORMAT=%H%n
>
> +check_tar() {
> + tarfile=$1.tar
> + listfile=$1.lst
> + dir=$1
> + dir_with_prefix=$dir/$2
> +
> + test_expect_success ' extract tar archive' '
s/' extract/'extract/
> + (mkdir $dir && cd $dir && "$TAR" xf -) <$tarfile
> + '
> +
> + test_expect_success ' validate filenames' '
s/' validate/'validate/
> + (cd ${dir_with_prefix}a && find .) | sort >$listfile &&
> + test_cmp a.lst $listfile
> + '
> +
> + test_expect_success ' validate file contents' '
s/' validate/'validate/
> + diff -r a ${dir_with_prefix}a
> + '
> +}
> +
> test_expect_success \
> 'populate workdir' \
> 'mkdir a &&
> @@ -81,6 +101,8 @@ test_expect_success \
> 'git archive' \
> 'git archive HEAD >b.tar'
>
> +check_tar b
> +
> test_expect_success \
> 'git tar-tree' \
> 'git tar-tree HEAD >b2.tar'
> @@ -125,19 +147,6 @@ test_expect_success \
> test_cmp .git/$(git symbolic-ref HEAD) b.commitid'
>
> test_expect_success \
> -'extract tar archive' \
> -'(mkdir b && cd b && "$TAR" xf -) -
> -test_expect_success \
> -'validate filenames' \
> -'(cd b/a && find .) | sort >b.lst &&
> - test_cmp a.lst b.lst'
> -
> -test_expect_success \
> -'validate file contents' \
> -'diff -r a b/a'
> -
> -test_expect_success \
> 'git tar-tree with prefix' \
> 'git tar-tree HEAD prefix >c.tar'
>
> --
> 1.8.2.3
>
> --
> 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
--
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: [PATCH 1/6] t5000: integrate export-subst tests into regular tests
On Mon, May 20, 2013 at 5:58 AM, René Scharfe wrote: > Instead of creating extra archives for testing substitutions, set the > attribute export-subst and overwrite the marked file with the expected > (expanded) content right between commiting and archiving. Thus > placeholder expansion based on the committed content is performed with > each archive creation and the comparision with the contents of directory s/comparision/comparison/ > a yields the correct result. We can then remove the special tests for > export-subst. > > Signed-off-by: René Scharfe -- 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: English/German terminology, git.git's de.po, and pro-git
Thanks for the update. I would like to add some comments on this G+E glossary and I hope you are interested in reading those, even though it is known that I prefer a "pure Ger" translation. However, as I wrote in my other message I agree that for the command line tool the criteria for choosing the translation approach are different from those for a GUI tool. So I can very well envision a good G+E translation for git core and subsequently all related books. Am Sonntag, 19. Mai 2013, 18:53:18 schrieb Ralf Thielow: > Basic repository objects: > > blob = Blob > tree = Baum, Baum-Objekt (bevorzugt), "Tree"-Objekt > submodule = Submodul > pack(noun) = Pack-Datei > pack(verb) = packen (ggf. Pack-Datei erstellen) > ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt) Yes. Does the "Pack-Datei" appear anywhere in the book? I wouldn't understand the term, but then again, this is probably because I don't understand the semantic of this thingy as a repository object regardless of the language... > Content in a repository: > > file(s)= Datei(en) > tracked file = beobachtete Datei > track file = beobachte Datei > untracked file = unbeobachtete Datei > directory = Verzeichnis Yes. > Repositories / tracking concepts: > > clone (verb) = klonen > clone (noun) = der Klon > repository = Repository > bare repository= Bare Repository Yes. After some evaluation of the git-gui translation I think using "Repository" there as well is probably the better choice. > working directory = Arbeitsverzeichnis > working tree = -||- > > remote branch = Remote-Branch > remote-tracking branch = Remote-Tracking-Branch > upstream branch= Upstream-Branch Yes. What's the main reason for using "Branch" in the German text? Consistency with the commands, or assumed familiarity of the term within the target audience? "Zweig" is available. > remote repository = Remote-Repository > remote(noun) = -||- > remote(adj)= extern, entfernt liegend > > Authorship: > > author= Autor > committer = Commit-Ersteller > tagger= Tag-Ersteller Yes. > Commits, tags and other references: > > HEAD = HEAD > Konzept aus der Git-Welt, daher nicht zu übersetzen. > detached HEAD = losgelöster HEAD > > commit(noun) = Commit > commit(verb) = committen > commit the result = das Ergebnis committen > parent commit = Eltern-Commit > child commit = Kind-Commit > commit message= Commit-Beschreibung Yes, for the G+E approach. > stash(noun) = der Stash > stash(verb) = "stashen", "stash" benutzen (bevorzugt) > unstash(verb) = "unstashen", "zurückladen", "aus 'stash' > zurückladen" (bevorzugt) Using "Stash" in G+E is quite ugly, but the noun is probably unavoidable because the feature is pretty much unique to git. I'd suggest to use only the noun and use the verbs as "stash benutzen" and "aus stash zurückladen" as proposed. > reference = Referenz > revision = Commit > branch = Branch > tag(noun) = Tag > tag(verb) = taggen, Tag erstellen > annotated tag = annotierter Tag > tag message= Tag-Beschreibung I've commented on "Branch" above. As for "Tag": Yes, the term is familiar among the target audience. However, do you really want this noun which is the same word as "Tag wie in Datum"? Some more disambiguation between the tag and the date would be helpful, wouldn't it? The derived forms are fine, and also here I'd suggest to use only the G+E noun but construct the verbs with other German words: "Tag erstellen". > stage/index (noun) = Staging-Area, Index > stage/index (verb) = (für einen | zum) Commit vormerken > (bevorzugt), zur Staging Area hinzufügen, dem Index hinzufügen > unstage (verb) = aus Staging Area entfernen, aus Index entfernen I'd strongly suggest not to use "Index". I've never understood why this term showed up in the English wording to begin with. It took me years until I got the point that from the user's point of view, this thingy has nothing to do with a book's index or a database's index, which is where I go to look up more information about a keyword. It is a big improvement to use "staging area" on the English side. If it has to be an English word due to consistency with the commands, I'd suggest "Staging-Area" or "Staging-Bereich". For the verb I'd agree to keep only the noun in English but construct the verb with German verbs, like already proposed here. > Moving data around: > > fetch = anfordern > pull = zusammenführen > push = versenden > > fast-forward = vorspulen > non-fast-forward = nicht vorspulen IMHO yes, and the German terms make me even u
Re: Storing refs in the odb
On Mon, May 20, 2013 at 8:28 PM, Junio C Hamano wrote: > Johan Herland writes: > >> I wasn't considering disallowing _anything_, rather open up to the >> idea that a tree object might refer to tag objects as well as >> commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted >> scheme, I was considering whether the tree entry at the "virtual" path >> "refs/tags/v1.0" should look like this: >> >> 100644 blob 123456... v1.0 >> >> where the blob at 123456... contains the object id of the v1.0 tag >> object, or whether we should allow the crazyness that is: >> >> ?? tag 987654... v1.0 >> >> Just a thought experiment... > > I was reacting to this part of your earlier message: > Of course in either case we couldn't use a tree object directly, because these new "reference tree" objects would refer not only to blobs and other trees but also to commits and tags. >>> >>> Indeed. I don't know if the best solution would be to actually _allow_ >>> that (which would complicate the object parsing code somewhat; a tree > > You cannot disambiguate, with the thought-experiment in your message > I am responding to, between these two: > > ?? tree 987654... v2.6.11-tree > ?? tree 987654... sub > > where the former is a light-weight tag for that tree, while the > latter is merely a subhierarchy in refs/sub/hier/archy, but if you > disallow v2.6.11-tree, and if you know this kind of tree is only to > express the ref hierarchy, then everything is unambiguous (a commit > is not a submodule but is a ref that points at a commit, a blob is a > ref that points at a blob like refs/tags/junio-gpg-pub, and tag is a > ref that points at the tag). > > So it was "workable" alternative implementation of refs (I am not > saying it is an "improvement", with the atomicity and performance > implications we already discussed), if we did not have to worry > about a light-weight tag that directly point at a tree. True, unless we were to abuse the mode bits to differentiate between regular-subtree and ref-to-tree cases... ...Johan -- Johan Herland, www.herland.net -- 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: Storing refs in the odb
Johan Herland writes: > I wasn't considering disallowing _anything_, rather open up to the > idea that a tree object might refer to tag objects as well as > commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted > scheme, I was considering whether the tree entry at the "virtual" path > "refs/tags/v1.0" should look like this: > > 100644 blob 123456... v1.0 > > where the blob at 123456... contains the object id of the v1.0 tag > object, or whether we should allow the crazyness that is: > > ?? tag 987654... v1.0 > > Just a thought experiment... I was reacting to this part of your earlier message: >>> Of course in either case we couldn't use a tree object directly, because >>> these new "reference tree" objects would refer not only to blobs and >>> other trees but also to commits and tags. >> >> Indeed. I don't know if the best solution would be to actually _allow_ >> that (which would complicate the object parsing code somewhat; a tree You cannot disambiguate, with the thought-experiment in your message I am responding to, between these two: ?? tree 987654... v2.6.11-tree ?? tree 987654... sub where the former is a light-weight tag for that tree, while the latter is merely a subhierarchy in refs/sub/hier/archy, but if you disallow v2.6.11-tree, and if you know this kind of tree is only to express the ref hierarchy, then everything is unambiguous (a commit is not a submodule but is a ref that points at a commit, a blob is a ref that points at a blob like refs/tags/junio-gpg-pub, and tag is a ref that points at the tag). So it was "workable" alternative implementation of refs (I am not saying it is an "improvement", with the atomicity and performance implications we already discussed), if we did not have to worry about a light-weight tag that directly point at a tree. -- 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: [PATCH] remote-hg: set stdout to binary mode on win32
Felipe Contreras writes: > On Sun, May 19, 2013 at 6:53 AM, Felipe Contreras > wrote: >> From: Amit Bakshi >> >> git clone hangs on windows, and file.write would return errno 22 inside >> of mercurial's windows.winstdout wrapper class. This patch sets stdout's >> mode to binary, fixing both issues. > > Forgot: > [fc: cleaned up] > >> Signed-off-by: Felipe Contreras Thanks, sounds like this is meant for 'master'? -- 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: [PATCH 00/17] Remove assumptions about refname lifetimes
Jeff King writes: > But more importantly, it introduces contention between two unrelated > refs that are being updated. Even if we reconcile the differences > automatically (e.g., with a "merge-and-retry" strategy), that is going > to be a serious performance regression for a busy repository, as we > repeatedly try to reconcile the serialized updates to the refs/ root > tree. I think we are on the same page. > Any transactional solution needs to have the equivalent of ref-level > locking (i.e., row-level locking in a relational setting). Not necessarily if we can exploit assumptions such as deletion is far rare compared to update and creation which in turn are far rare compared to lookup. I've been wondering if we can find a cheap reader-writer lock mechanism, use a single instance of it to govern the whole repository, and have everybody but ref deleters and "git pack-ref" take the read side of the lock. Then only while ref deletion or ref packing is going on, everybody need to stall, but otherwise the most common "read or update recently touched refs (aka loose refs)" will be taking the reader side of that cheap read-write lock and reading a single loose ref file. Perhaps such a "cheap on reader side" reader-write lock is hard to come by? -- 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Jonathan Nieder writes: >> --- a/Documentation/gitcli.txt >> +++ b/Documentation/gitcli.txt >> @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm >> hello.c`, you will _not_ >> see `hello.c` in your working tree with the former, but with the latter >> you will. >> >> +Just as, by convention, the filesystem '.' refers to the current directory, >> +using a '.' (period) as a repository name in Git (a dot-repository) refers >> +to your local repository. > > Good idea, but I fear that no one would find it there. Also I think it would be better without ", by convention,". If you say '.' == current directory is "a convention", you have to start saying that "by convention", "hello.c" refers to the file in the current directory of that name, which may be technically correct but make the phrase "by convention" meaningless. A dot "." is *the* name for the current directory, just like "hello.c" is the name for that file. Just like '.' refers to the current directory in the filesystem, '.' refers to the current repository. would be sufficient. > Would it make sense to put this in Documentation/urls.txt (aka the > "GIT URLS" section of git-fetch(1) and git-clone(1)), where other URL > schemes are documented? Yes, the '.' described above is a special case of giving a repository URL as a relative-path on the filesystem. -- 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: [RFC/PATCH 1/2] config doc: add dot-repository note
Jonathan Nieder writes:
> Philip Oakley wrote:
>
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -734,6 +734,8 @@ branch..remote::
>> overridden by `branch..pushremote`. If no remote is
>> configured, or if you are not on any branch, it defaults to
>> `origin` for fetching and `remote.pushdefault` for pushing.
>> +Additionally, a `.` (period) means the current local repository
>> +(a dot-repository), see `branch..merge`'s final note below.
>
> Does this accept an arbitrary git URL, or only remote names?
The branch..remote variable refers to remote names, and '.'
often appears as a special name to refer to the local repository.
I think you can define it as URL and your "git fetch" (no args) will
do the right thing in that it would:
(1) fetch the history leading to the tip branch..merge branch
from there; and
(2) leave the result in FETCH_HEAD, so that "git merge FETCH_HEAD"
can conclude the "git pull" you split into two manually by
running "git fetch" first,
but I do not think there is a "while we create this branch" side
effect UI like "--set-upstream-to" for doing so, except for setting
it to '.' when you set upstream to a branch in the local repository.
I.e.
git checkout -t -b mywork master
git branch --set-upstream-to master mywork
Also I think setting it to arbitrary URL would mean that you would
not see any remote tracking ref (they are to be defined as a
property of named remote with remote..fetch refspecs), so it
is unclear how @{u} would work. @{u} works when the variable is set
to '.', though.
For the above reasons, describing '.' as a special value for the
variable that the end users are likely to see is a reasonable "white
lie" for this part of the documentation.
--
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: Storing refs in the odb
On Mon, May 20, 2013 at 7:21 PM, Junio C Hamano wrote: > Johan Herland writes: > >>> Of course in either case we couldn't use a tree object directly, because >>> these new "reference tree" objects would refer not only to blobs and >>> other trees but also to commits and tags. >> >> Indeed. I don't know if the best solution would be to actually _allow_ >> that (which would complicate the object parsing code somewhat; a tree >> entry pointing to a commit is usually interpreted as a submodule, but >> that is not what we'd want for the ref tree, and a tree entry pointing >> at a tag has AFAIK not yet been done), or whether it means we need to >> come up with a different kind of structure. > > You can disallow that only by giving up on being able to express > Linus's kernel repository, which has an oddball v2.6.11-tree tag. > > I do not think that that particular tag in the particular repository > is too big a show-stopper; if it is only Linus, we can ask him to > drop that tag (he has v2.6.11 tag object that points at the tree, so > the users do not lose anything) and be done with it. > > But if there are other repositories that tag trees in a similar way, > that would be a real regression. We cannot just go ask people to > change their workflow that depended on using refs that directly > point at trees overnight. I wasn't considering disallowing _anything_, rather open up to the idea that a tree object might refer to tag objects as well as commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted scheme, I was considering whether the tree entry at the "virtual" path "refs/tags/v1.0" should look like this: 100644 blob 123456... v1.0 where the blob at 123456... contains the object id of the v1.0 tag object, or whether we should allow the crazyness that is: ?? tag 987654... v1.0 Just a thought experiment... ...Johan -- Johan Herland, www.herland.net -- 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: Storing refs in the odb
Johan Herland writes: >> Of course in either case we couldn't use a tree object directly, because >> these new "reference tree" objects would refer not only to blobs and >> other trees but also to commits and tags. > > Indeed. I don't know if the best solution would be to actually _allow_ > that (which would complicate the object parsing code somewhat; a tree > entry pointing to a commit is usually interpreted as a submodule, but > that is not what we'd want for the ref tree, and a tree entry pointing > at a tag has AFAIK not yet been done), or whether it means we need to > come up with a different kind of structure. You can disallow that only by giving up on being able to express Linus's kernel repository, which has an oddball v2.6.11-tree tag. I do not think that that particular tag in the particular repository is too big a show-stopper; if it is only Linus, we can ask him to drop that tag (he has v2.6.11 tag object that points at the tree, so the users do not lose anything) and be done with it. But if there are other repositories that tag trees in a similar way, that would be a real regression. We cannot just go ask people to change their workflow that depended on using refs that directly point at trees overnight. -- 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: [PATCH 00/17] Remove assumptions about refname lifetimes
On Mon, May 20, 2013 at 6:59 PM, Jeff King wrote: > On Mon, May 20, 2013 at 09:37:30AM -0700, Junio C Hamano wrote: >> Johan Herland writes: >> >> > For server-class installations we need ref storage that can be read >> > (and updated?) atomically, and the current system of loose + packed >> > files won't work since reading (and updating) more than a single file >> > is not an atomic operation. Trivially, one could resolve this by >> > dropping loose refs, and always using a single packed-refs file, but >> > that would make it prohibitively expensive to update refs (the entire >> > packed-refs file must be rewritten for every update). >> > >> > Now, observe that we don't have these race conditions in the object >> > database, because it is an add-only immutable data store. >> > >> > What if we stored the refs as a tree object in the object database, >> > referenced by a single (loose) ref? >> >> What is the cost of updating a single branch with that scheme? > > Yeah, I had the same thoughts as you here; I don't think this is really > much better than updating a single packed-refs file. You may only > have to touch log(N) of the entries to update the trees along the path > to your ref (assuming you have a bushy refs/ tree; in practice, of > course, you have a lot of entries in refs/heads/, so you do not quite > get log behavior). So algorithmically it may be slightly better, but you > pay a much higher constant, in that you are creating many tree objects > along the path (and reading them on lookup). True. > But more importantly, it introduces contention between two unrelated > refs that are being updated. Even if we reconcile the differences > automatically (e.g., with a "merge-and-retry" strategy), that is going > to be a serious performance regression for a busy repository, as we > repeatedly try to reconcile the serialized updates to the refs/ root > tree. > > Any transactional solution needs to have the equivalent of ref-level > locking (i.e., row-level locking in a relational setting). It is OK for > two simultaneous updates to different rows to happen in random order; we > don't care about that level of atomicity. The important thing is that > the _readers_ see transactions in consistent order; if we know that > update B started after update A finished, then we must never see update > A without update B reflected. And I think that is more or less a solved > problem in the database world. > > That is what prevents: > > git update-ref A B > git update-ref -d B > > from creating a view where the reader sees neither A nor B (which is > what can happen with the current filesystem view). All true. Just a last spasm from the dying notion that we could solve this in the filesystem, without using "proper" database... ...Johan -- Johan Herland, www.herland.net -- 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: [PATCH 00/17] Remove assumptions about refname lifetimes
On Mon, May 20, 2013 at 6:37 PM, Junio C Hamano wrote: > Johan Herland writes: >> For server-class installations we need ref storage that can be read >> (and updated?) atomically, and the current system of loose + packed >> files won't work since reading (and updating) more than a single file >> is not an atomic operation. Trivially, one could resolve this by >> dropping loose refs, and always using a single packed-refs file, but >> that would make it prohibitively expensive to update refs (the entire >> packed-refs file must be rewritten for every update). >> >> Now, observe that we don't have these race conditions in the object >> database, because it is an add-only immutable data store. >> >> What if we stored the refs as a tree object in the object database, >> referenced by a single (loose) ref? > > What is the cost of updating a single branch with that scheme? > > Doesn't it end up recording roughly the same amount of information > as updating a single packed-refs file that is flat, but with the > need to open a few tree objects (top-level, refs/, and refs/heads/), > writing out a blob that stores the object name at the tip, computing > the updated trees (refs/heads/, refs/ and top-level), and then > finally doing the compare-and-swap of that single loose ref? Yes, except that when you update packed-refs, you have to write out the _entire_ file, whereas with this scheme you only have to write out the part of the refs hierarchy you actually touched (e.g. rewriting refs/heads/foo would not have to write out anything inside refs/tags/*). If you have small number of branches, and a huge number of tags, this scheme might end up being cheaper than writing the entire packed-refs. But in general, it's probably much more expensive to go via the odb. > You may guarantee atomicity but it is the same granularity of > atomicity as a single packed-refs file. Yes, as I argued elsewhere in this thread: It seems that _any_ filesystem-based solution must resort to having all updates depend on a single file in order to guarantee atomicity. > When you are updating a > branch while somebody else is updating a tag, of course you do not > have to look at refs/tags/ in your operation and you can write out > your final packed-refs equivalent tree to the object database > without racing with the other process, but the top-level you come up > with and the top-level the other process comes up with (which has > an up-to-date refs/tags/ part, but has a stale refs/heads/ part from > your point of view) have to race to update that single loose ref, > and one of you have to back out. True. > That "backing out" can be made more intelligently than just dying > with "compare and swap failed--please retry" message, e.g. you at > that point notice what you started with, what the other party did > while you were working on (i.e. updating refs/tags/), and three-way > merge the refs tree, and in cases where "all refs recorded as loose > refs" scheme wouldn't have resulted in problematic conflict, such a > three-way merge would resolve trivially (you updated refs/heads/ and > the update by the other process to refs/tags/ would not conflict > with what you did). But the same three-way merge scheme can be > employed with the current flat single packed-refs scheme, can't it? Yes. (albeit without reusing the machinery we already have for doing three-way merges) > Even worse, what is the cost of looking up the value of a single > branch? You would need to open a few tree objects and the leaf blob > that records the object name the ref points at, wouldn't you? Yes. Probably a showstopper, although single branch/ref lookup might not be so common on server side, as it is on the user side. > Right now, such a look-up is either opening a single small file and > reading the first 41 bytes off of it, and falling back (when the ref > in question is packed) to read a single packed-refs file and finding > the ref you want from it. > > So... Yep... ...Johan -- Johan Herland, www.herland.net -- 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: [PATCH 00/17] Remove assumptions about refname lifetimes
On Mon, May 20, 2013 at 09:37:30AM -0700, Junio C Hamano wrote: > Johan Herland writes: > > > For server-class installations we need ref storage that can be read > > (and updated?) atomically, and the current system of loose + packed > > files won't work since reading (and updating) more than a single file > > is not an atomic operation. Trivially, one could resolve this by > > dropping loose refs, and always using a single packed-refs file, but > > that would make it prohibitively expensive to update refs (the entire > > packed-refs file must be rewritten for every update). > > > > Now, observe that we don't have these race conditions in the object > > database, because it is an add-only immutable data store. > > > > What if we stored the refs as a tree object in the object database, > > referenced by a single (loose) ref? > > What is the cost of updating a single branch with that scheme? Yeah, I had the same thoughts as you here; I don't think this is really much better than updating a single packed-refs file. You may only have to touch log(N) of the entries to update the trees along the path to your ref (assuming you have a bushy refs/ tree; in practice, of course, you have a lot of entries in refs/heads/, so you do not quite get log behavior). So algorithmically it may be slightly better, but you pay a much higher constant, in that you are creating many tree objects along the path (and reading them on lookup). But more importantly, it introduces contention between two unrelated refs that are being updated. Even if we reconcile the differences automatically (e.g., with a "merge-and-retry" strategy), that is going to be a serious performance regression for a busy repository, as we repeatedly try to reconcile the serialized updates to the refs/ root tree. Any transactional solution needs to have the equivalent of ref-level locking (i.e., row-level locking in a relational setting). It is OK for two simultaneous updates to different rows to happen in random order; we don't care about that level of atomicity. The important thing is that the _readers_ see transactions in consistent order; if we know that update B started after update A finished, then we must never see update A without update B reflected. And I think that is more or less a solved problem in the database world. That is what prevents: git update-ref A B git update-ref -d B from creating a view where the reader sees neither A nor B (which is what can happen with the current filesystem view). -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
Re: [RFC 16/17] object_array_entry: copy name before storing in name field
On Mon, May 20, 2013 at 04:42:38PM +0200, Michael Haggerty wrote:
> >> * Many callers store the empty string ("") as the name; for example,
> >> most of the entries created during a run of rev-list have "" as
> >> their name. This means that lots of needless copies of "" are being
> >> made. I think that the best solution to this problem would be to
> >> store NULL rather than "" for such entries, but I haven't figured
> >> out all of the places where the name is used.
> >
> > Use strbufs?
> >
> > No allocation (except for the strbuf object itself) is needed for
> > empty strings, and string ownership and be transferred to and from it
> > to prevent extra copies.
>
> That would cost two extra size_t per object_array_entry. I have the
> feeling that this structure is used often enough that the extra overhead
> would be a disadvantage, but I'm not sure.
>
> The obvious alternative would be to teach users to deal with NULL and
> either add another constructor alternative that transfers string
> ownership or *always* transfer string ownership and change the callers
> to call xstrdup() if they don't already own the name string. I think I
> will try that approach first.
You could use the same trick that strbuf does: instead of NULL, point to
a well-known empty string literal. Readers do not have to care about
this optimization at all; only writers need to recognize the well-known
pointer value. And since we do not update in place but only eventually
free, it really is just that anyone calling free() would do "if (name !=
well_known_empty_string)".
-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
Re: [PATCH 00/17] Remove assumptions about refname lifetimes
Johan Herland writes: > For server-class installations we need ref storage that can be read > (and updated?) atomically, and the current system of loose + packed > files won't work since reading (and updating) more than a single file > is not an atomic operation. Trivially, one could resolve this by > dropping loose refs, and always using a single packed-refs file, but > that would make it prohibitively expensive to update refs (the entire > packed-refs file must be rewritten for every update). > > Now, observe that we don't have these race conditions in the object > database, because it is an add-only immutable data store. > > What if we stored the refs as a tree object in the object database, > referenced by a single (loose) ref? What is the cost of updating a single branch with that scheme? Doesn't it end up recording roughly the same amount of information as updating a single packed-refs file that is flat, but with the need to open a few tree objects (top-level, refs/, and refs/heads/), writing out a blob that stores the object name at the tip, computing the updated trees (refs/heads/, refs/ and top-level), and then finally doing the compare-and-swap of that single loose ref? You may guarantee atomicity but it is the same granularity of atomicity as a single packed-refs file. When you are updating a branch while somebody else is updating a tag, of course you do not have to look at refs/tags/ in your operation and you can write out your final packed-refs equivalent tree to the object database without racing with the other process, but the top-level you come up with and the top-level the other process comes up with (which has an up-to-date refs/tags/ part, but has a stale refs/heads/ part from your point of view) have to race to update that single loose ref, and one of you have to back out. That "backing out" can be made more intelligently than just dying with "compare and swap failed--please retry" message, e.g. you at that point notice what you started with, what the other party did while you were working on (i.e. updating refs/tags/), and three-way merge the refs tree, and in cases where "all refs recorded as loose refs" scheme wouldn't have resulted in problematic conflict, such a three-way merge would resolve trivially (you updated refs/heads/ and the update by the other process to refs/tags/ would not conflict with what you did). But the same three-way merge scheme can be employed with the current flat single packed-refs scheme, can't it? Even worse, what is the cost of looking up the value of a single branch? You would need to open a few tree objects and the leaf blob that records the object name the ref points at, wouldn't you? Right now, such a look-up is either opening a single small file and reading the first 41 bytes off of it, and falling back (when the ref in question is packed) to read a single packed-refs file and finding the ref you want from it. 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 (May 2013, #04; Wed, 15)
Duy Nguyen writes: > On Thu, May 16, 2013 at 6:42 AM, Junio C Hamano wrote: >> * nd/warn-ambiguous-object-name (2013-05-07) 1 commit >> - get_sha1: improve ambiguity warning regarding SHA-1 and ref names >> >> "git cmd ", when happens to be a 40-hex string, >> directly uses the 40-hex string as an object name, even if a ref >> "refs//" exists. This disambiguation order >> is unlikely to change, but we should warn about the ambiguity just >> like we warn when more than one refs/ hierachies share the same >> name. >> >> The message needs to be fixed up, as this is not "refname is >> ambiguous". > > hm.. how should the message be rephrased? ambiguity of 40-hex string > and a ref path? At that point, the user gave us a full object name and we are going to treat it as a full object name, no? Wouldn't it be necessary to let the user know that it is different from having two ambiguous refs? Think why the user has such a hard to type ref in the first place. The user may have done this previously, thinking that he is detaching the HEAD to fix an earlier mistake in a branch: $ BAD_COMMIT=$(git rev-parse nd/magic~8) $ git checkout $BAD_COMMIT but by mistake gave a "-b" after "checkout", i.e. $ git checkout -b $BAD_COMMIT After this, commands that want to work on branch name would still work as "expected", with the expectation being the user would be working on the refs/heads/$BAD_COMMIT branch, e.g. $ git checkout $BAD_COMMIT $ git branch -m $BAD_COMMIT nd/magic-fix but commands that want to work on commit object name will resolve it to the $BAD_COMMIT object (i.e. nd/magic~8), e.g. $ git log $BAD_COMMIT and needs disambiguation if the user wants to work on the commit at the tip of the branch, e.g. $ git log heads/$BAD_COMMIT So we really do want the users to notice and take corrective action, and one way to attract the attention of the users is to phrase the message more explicitly to let them know what is going on. In addition to your topic, it may be a good idea to notice this at the Porcelain level (e.g. "checkout -b" and "branch", but not at the "update-ref" level) and warn or even die if a Porcelain tries to create a branch with such a name. -- 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
[no subject]
-- 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: [RFC 16/17] object_array_entry: copy name before storing in name field
On 05/20/2013 12:33 PM, Johan Herland wrote:
> On Sun, May 19, 2013 at 10:27 PM, Michael Haggerty
> wrote:
>> This is the culmination of the last few commits. Since some callers
>> want to store refnames in the name field of object_array elements, but
>> we don't want those callers to assume that the refnames that they got
>> from for_each_ref() have infinite lifetime, the easiest thing to do is
>> have object_array make a copy of the names before writing them in the
>> entries, and to free the names for entries that are no longer in use.
>> This change fixes the problem, but has some disadvantages:
>>
>> * It requires extra copies to be made of strings that are already
>> copies, for example when the results of path_name(path, name) are
>> used as a name in revision.c:add_object(). This might be rare
>> enough that it can be ignored (though the original result of
>> path_name() would have to be freed, which this patch doesn't do so
>> there is a memory leak).
>>
>> * Many callers store the empty string ("") as the name; for example,
>> most of the entries created during a run of rev-list have "" as
>> their name. This means that lots of needless copies of "" are being
>> made. I think that the best solution to this problem would be to
>> store NULL rather than "" for such entries, but I haven't figured
>> out all of the places where the name is used.
>
> Use strbufs?
>
> No allocation (except for the strbuf object itself) is needed for
> empty strings, and string ownership and be transferred to and from it
> to prevent extra copies.
That would cost two extra size_t per object_array_entry. I have the
feeling that this structure is used often enough that the extra overhead
would be a disadvantage, but I'm not sure.
The obvious alternative would be to teach users to deal with NULL and
either add another constructor alternative that transfers string
ownership or *always* transfer string ownership and change the callers
to call xstrdup() if they don't already own the name string. I think I
will try that approach first.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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
Storing refs in the odb (was: Re: [PATCH 00/17] Remove assumptions about refname lifetimes)
On Mon, May 20, 2013 at 2:15 PM, Michael Haggerty wrote: > This is a very interesting idea. "It's turtles all the way down." :) > On 05/20/2013 12:28 PM, Johan Herland wrote: >> For server-class installations we need ref storage that can be read >> (and updated?) atomically, and the current system of loose + packed >> files won't work since reading (and updating) more than a single file >> is not an atomic operation. Trivially, one could resolve this by >> dropping loose refs, and always using a single packed-refs file, but >> that would make it prohibitively expensive to update refs (the entire >> packed-refs file must be rewritten for every update). > > Correct, or the "packed-refs" file would have to be updated in place > using some database-style approach for locking/transactions/whatever. > >> Now, observe that we don't have these race conditions in the object >> database, because it is an add-only immutable data store. > > Except for prune, of course, which can cause race conditions WRT to writers. Yes, but that is a different race, in need of a different solution. E.g. that race is concerned with pruning unreachable objects that are about to become reachable by a concurrent operation, which is AFAICS independent from the ref update race that we're discussing here. >> What if we stored the refs as a tree object in the object database, >> referenced by a single (loose) ref? There would be a _single_ (albeit >> highly contentious) file outside the object database that represent >> the current state of the refs, but hopefully we can guarantee >> atomicity when reading (and updating?) that one file. Transactions can >> be done by: >> 1. Recording the tree id holding the refs before starting manipulation. >> 2. Creating a new tree object holding the manipulated state. >> 3. Re-checking the tree id before replacing the loose ref. If >> unchanged: commit, else: rollback/error out. > > There are two closely related possibilities and I'm not sure which one > you mean: > > * Effectively treat all of the refs as loose refs, but stored not in the > filesystem but rather in a hierarchical tree structure in the object > database. E.g., all of the refs directly under "refs/heads" would be in > one tree object, those in refs/remotes/foo in a second, those for > refs/remotes/bar in another etc. and all of them linked up together in a > tree object representing "refs". > > * Effectively treat all of the refs as packed refs, but store the single > "packed-refs" file as a single object in the object database. > > (The first alternative sounds more practical to me. I also guess that's > what you mean, since down below you say that each change would require > producing "a few objects".) The first alternative is what I had in mind. Initially I thought to record it as if one were to record a new tree using .git/refs as the root of your worktree (having exploded all packed-refs into loose refs). I.e. you would have "heads", "tags", "remotes" as subtrees of "reference tree", and then e.g. in the "heads" subtree, there would be an entry named "master" pointing to a _blob_, and the contents of that blob would be the commit id of the current tip of the master branch. Obviously the next optimization would be to drop the "master" -> blob -> commit indirection, and use "master" -> commit instead, i.e. the "master" tree entry corresponds directly to the commit to which it points (symrefs would naturally be recorded as symlinks). This would automatically provide reachability for all refs, but as you correctly observe: > Of course in either case we couldn't use a tree object directly, because > these new "reference tree" objects would refer not only to blobs and > other trees but also to commits and tags. Indeed. I don't know if the best solution would be to actually _allow_ that (which would complicate the object parsing code somewhat; a tree entry pointing to a commit is usually interpreted as a submodule, but that is not what we'd want for the ref tree, and a tree entry pointing at a tag has AFAIK not yet been done), or whether it means we need to come up with a different kind of structure. > [I know this is not what you are suggesting, but I am reminded of > Subversion, which stores trunk, branches, and tags in the same "tree" > space as the contents of the working trees. A Subversion commit > references a gigantic tree encompassing all branches of development and > all files on all of those branches (with cheap copies to reduce the > redundancy): > > / > /trunk/ > /trunk/Makefile > /trunk/src/ > /trunk/src/foo.c > /branches/ > /branches/next/ > /branches/next/Makefile > /branches/next/src/ > /branches/next/src/foo.c > /branches/pu/ > /branches/pu/Makefile > /branches/pu/src/ > /branches/pu/src/foo.c > /tags/ > /tags/v1.8.2/ > /tags/v1.8.2/Makefile > /tags/v1.8.2/src/ > /tags/v1.8.2/src/foo.c > etc... > > A Subversion commit thus desc
Re: [PATCH 00/17] Remove assumptions about refname lifetimes
This is a very interesting idea. "It's turtles all the way down." On 05/20/2013 12:28 PM, Johan Herland wrote: > (Sorry for going slightly off-topic and returning to the general > discussion on how to resolve the race conditions...) > > For server-class installations we need ref storage that can be read > (and updated?) atomically, and the current system of loose + packed > files won't work since reading (and updating) more than a single file > is not an atomic operation. Trivially, one could resolve this by > dropping loose refs, and always using a single packed-refs file, but > that would make it prohibitively expensive to update refs (the entire > packed-refs file must be rewritten for every update). Correct, or the "packed-refs" file would have to be updated in place using some database-style approach for locking/transactions/whatever. > Now, observe that we don't have these race conditions in the object > database, because it is an add-only immutable data store. Except for prune, of course, which can cause race conditions WRT to writers. > What if we stored the refs as a tree object in the object database, > referenced by a single (loose) ref? There would be a _single_ (albeit > highly contentious) file outside the object database that represent > the current state of the refs, but hopefully we can guarantee > atomicity when reading (and updating?) that one file. Transactions can > be done by: > 1. Recording the tree id holding the refs before starting manipulation. > 2. Creating a new tree object holding the manipulated state. > 3. Re-checking the tree id before replacing the loose ref. If > unchanged: commit, else: rollback/error out. There are two closely related possibilities and I'm not sure which one you mean: * Effectively treat all of the refs as loose refs, but stored not in the filesystem but rather in a hierarchical tree structure in the object database. E.g., all of the refs directly under "refs/heads" would be in one tree object, those in refs/remotes/foo in a second, those for refs/remotes/bar in another etc. and all of them linked up together in a tree object representing "refs". * Effectively treat all of the refs as packed refs, but store the single "packed-refs" file as a single object in the object database. (The first alternative sounds more practical to me. I also guess that's what you mean, since down below you say that each change would require producing "a few objects".) Of course in either case we couldn't use a tree object directly, because these new "reference tree" objects would refer not only to blobs and other trees but also to commits and tags. > All readers would trivially have access to a consistent refs view, > since the state of the entire refs hierarchy is held in the tree id > read from that single loose ref. > > It seems to me this should be somewhat less prohibitively expensive > than maintaining all refs in a single packed-refs file. That said, we > do end up producing a few new objects for every single ref update, > most of which would be thrown away by a future "gc". This might bog > things down, but I'm not sure how much. > > I'm sure someone must have had this idea before (although I don't > remember this alternative being raised at the Git Merge conference), > so please enlighten me as to why this won't work... ;) [I know this is not what you are suggesting, but I am reminded of Subversion, which stores trunk, branches, and tags in the same "tree" space as the contents of the working trees. A Subversion commit references a gigantic tree encompassing all branches of development and all files on all of those branches (with cheap copies to reduce the redundancy): / /trunk/ /trunk/Makefile /trunk/src/ /trunk/src/foo.c /branches/ /branches/next/ /branches/next/Makefile /branches/next/src/ /branches/next/src/foo.c /branches/pu/ /branches/pu/Makefile /branches/pu/src/ /branches/pu/src/foo.c /tags/ /tags/v1.8.2/ /tags/v1.8.2/Makefile /tags/v1.8.2/src/ /tags/v1.8.2/src/foo.c etc... A Subversion commit thus describes the state of *every* branch and tag at that moment in time. The model is conceptually very simple (in fact, too simple, and I believe the Subversion developers regret not having distinguished between the branch namespace and the file namespace).] The main difficulty with this idea will be the extreme contention on that "last loose reference file" pointing at the root of the reference tree. Essentially *every* change to the repository will have to create a new reference tree and point this file at the new version. I doubt that would be a problem for short-lived operations, but I fear that a long-lived operation would *never* get done. By the time it had finished constructing its new reference tree, some other short-lived operation will have changed it, and the long-lived process will have to choose between * Restart from the beginning. * Die with
Re: [PATCH 0/6] t5000: add test for pax extended header generation
Am 20.05.2013 11:58, schrieb René Scharfe: This series adds a test that exercises git archive's pax header code. It checks for tar versions that don't support pax headers and works around their deficiency. The first five patches are cleanups and refactorings to centralize tar calls into a helper function. The last patch adds the workaround at this central place and a file to the test archive whose name is too long to fit into the path field of a standard tar header, making a pax extended header necessary. Forgot to mention that the last patch was prompted by Thomas' recent test coverage patches. René -- 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: [RFC 16/17] object_array_entry: copy name before storing in name field
On Sun, May 19, 2013 at 10:27 PM, Michael Haggerty wrote:
> This is the culmination of the last few commits. Since some callers
> want to store refnames in the name field of object_array elements, but
> we don't want those callers to assume that the refnames that they got
> from for_each_ref() have infinite lifetime, the easiest thing to do is
> have object_array make a copy of the names before writing them in the
> entries, and to free the names for entries that are no longer in use.
> This change fixes the problem, but has some disadvantages:
>
> * It requires extra copies to be made of strings that are already
> copies, for example when the results of path_name(path, name) are
> used as a name in revision.c:add_object(). This might be rare
> enough that it can be ignored (though the original result of
> path_name() would have to be freed, which this patch doesn't do so
> there is a memory leak).
>
> * Many callers store the empty string ("") as the name; for example,
> most of the entries created during a run of rev-list have "" as
> their name. This means that lots of needless copies of "" are being
> made. I think that the best solution to this problem would be to
> store NULL rather than "" for such entries, but I haven't figured
> out all of the places where the name is used.
Use strbufs?
No allocation (except for the strbuf object itself) is needed for
empty strings, and string ownership and be transferred to and from it
to prevent extra copies.
...Johan
--
Johan Herland,
www.herland.net
--
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-submodule nested subrepo bug (Segmentation fault)
On Mon, May 20, 2013 at 09:32:21AM +0400, Kirill Berezin wrote: > When you trying to add submodule, that already has submodule, it craches. > For example you could try: git clone --recursive > http://github.com/Exsul/al_server Which version of Git were you using? I was not able to reproduce this with 1.8.3-rc3. -- 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: [PATCH 00/17] Remove assumptions about refname lifetimes
On Sun, May 19, 2013 at 10:26 PM, Michael Haggerty wrote: > Recently a number of race conditions related to references have been > discovered. There is likely to be a two-pronged solution to the > races: > > * For traditional, filesystem-based references, there will have to be > more checks that the ref caches are still up-to-date at the time of > their use (see, for example, [1]). If not, the ref cache will have > to be invalidated and reloaded. Assuming that the invalidation of > the old cache includes freeing its memory, such an invalidation will > cause lots of refname strings to be freed even though callers might > still hold references to them. > > * For server-class installations, filesystem-based references might > not be robust enough for 100% reliable operation, because the > reading of the complete set of references is not an atomic > operation. If another reference storage mechanism is developed, > there is no reason to expect the refnames strings to have long > lifetimes. (Sorry for going slightly off-topic and returning to the general discussion on how to resolve the race conditions...) For server-class installations we need ref storage that can be read (and updated?) atomically, and the current system of loose + packed files won't work since reading (and updating) more than a single file is not an atomic operation. Trivially, one could resolve this by dropping loose refs, and always using a single packed-refs file, but that would make it prohibitively expensive to update refs (the entire packed-refs file must be rewritten for every update). Now, observe that we don't have these race conditions in the object database, because it is an add-only immutable data store. What if we stored the refs as a tree object in the object database, referenced by a single (loose) ref? There would be a _single_ (albeit highly contentious) file outside the object database that represent the current state of the refs, but hopefully we can guarantee atomicity when reading (and updating?) that one file. Transactions can be done by: 1. Recording the tree id holding the refs before starting manipulation. 2. Creating a new tree object holding the manipulated state. 3. Re-checking the tree id before replacing the loose ref. If unchanged: commit, else: rollback/error out. All readers would trivially have access to a consistent refs view, since the state of the entire refs hierarchy is held in the tree id read from that single loose ref. It seems to me this should be somewhat less prohibitively expensive than maintaining all refs in a single packed-refs file. That said, we do end up producing a few new objects for every single ref update, most of which would be thrown away by a future "gc". This might bog things down, but I'm not sure how much. I'm sure someone must have had this idea before (although I don't remember this alternative being raised at the Git Merge conference), so please enlighten me as to why this won't work... ;) ...Johan PS: Keeping reflogs is just a matter of wrapping the ref tree in a commit object using the previous state of the ref tree as its parent. -- Johan Herland, www.herland.net -- 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 (May 2013, #04; Wed, 15)
On Thu, May 16, 2013 at 6:42 AM, Junio C Hamano wrote: > * nd/warn-ambiguous-object-name (2013-05-07) 1 commit > - get_sha1: improve ambiguity warning regarding SHA-1 and ref names > > "git cmd ", when happens to be a 40-hex string, > directly uses the 40-hex string as an object name, even if a ref > "refs//" exists. This disambiguation order > is unlikely to change, but we should warn about the ambiguity just > like we warn when more than one refs/ hierachies share the same > name. > > The message needs to be fixed up, as this is not "refname is > ambiguous". hm.. how should the message be rephrased? ambiguity of 40-hex string and a ref path? -- Duy -- 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
[PATCH 1/6] t5000: integrate export-subst tests into regular tests
Instead of creating extra archives for testing substitutions, set the
attribute export-subst and overwrite the marked file with the expected
(expanded) content right between commiting and archiving. Thus
placeholder expansion based on the committed content is performed with
each archive creation and the comparision with the contents of directory
a yields the correct result. We can then remove the special tests for
export-subst.
Signed-off-by: René Scharfe
---
t/t5000-tar-tree.sh | 38 ++
1 file changed, 6 insertions(+), 32 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 3fbd366..68b5698 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -62,6 +62,12 @@ test_expect_success \
git update-ref HEAD $(TZ=GMT GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
git commit-tree $treeid >.git/info/attributes &&
+ git log --max-count=1 "--pretty=format:A${SUBSTFORMAT}O" HEAD \
+ >a/substfile1
+'
+
test_expect_success \
'create bare clone' \
'git clone --bare . bare.git &&
@@ -148,38 +154,6 @@ test_expect_success \
'validate file contents with prefix' \
'diff -r a c/prefix/a'
-test_expect_success \
-'create archives with substfiles' \
-'cp .git/info/attributes .git/info/attributes.before &&
- echo "substfile?" export-subst >>.git/info/attributes &&
- git archive HEAD >f.tar &&
- git archive --prefix=prefix/ HEAD >g.tar &&
- mv .git/info/attributes.before .git/info/attributes'
-
-test_expect_success \
-'extract substfiles' \
-'(mkdir f && cd f && "$TAR" xf -) f/a/substfile1.expected &&
- test_cmp f/a/substfile1.expected f/a/substfile1 &&
- test_cmp a/substfile2 f/a/substfile2
-'
-
-test_expect_success \
-'extract substfiles from archive with prefix' \
-'(mkdir g && cd g && "$TAR" xf -) g/prefix/a/substfile1.expected &&
- test_cmp g/prefix/a/substfile1.expected g/prefix/a/substfile1 &&
- test_cmp a/substfile2 g/prefix/a/substfile2
-'
-
test_expect_success 'git archive with --output, override inferred format' '
git archive --format=tar --output=d4.zip HEAD &&
test_cmp b.tar d4.zip
--
1.8.2.3
--
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
[PATCH 2/6] t5000, t5003: create directories for extracted files lazily
Create the directories b and c just before they are needed instead of up front. For t5003 it turns out we don't need them at all. For t5000 it makes the coming modifications easier. Signed-off-by: René Scharfe --- t/t5000-tar-tree.sh| 6 +++--- t/t5003-archive-zip.sh | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh index 68b5698..41cd609 100755 --- a/t/t5000-tar-tree.sh +++ b/t/t5000-tar-tree.sh @@ -32,7 +32,7 @@ SUBSTFORMAT=%H%n test_expect_success \ 'populate workdir' \ -'mkdir a b c && +'mkdir a && echo simple textfile >a/a && mkdir a/bin && cp /bin/sh a/bin && @@ -126,7 +126,7 @@ test_expect_success \ test_expect_success \ 'extract tar archive' \ -'(cd b && "$TAR" xf -) a/a && mkdir a/bin && cp /bin/sh a/bin && -- 1.8.2.3 -- 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
[PATCH 6/6] t5000: test long filenames
Add a file with a long name to the test archive in order to check
entries with pax extended headers. Also add a check for tar versions
that doen't understand this format. Those versions should extract the
headers as a regular files. Add code to check_tar() to interpret the
path header if present, so that our tests work even with those tar
versions.
It's important to use the fallback code only if needed to still be
able to detect git archive errorously creating pax headers as regular
file entries (with a suitable tar version, of course).
The archive used to check for pax header support in tar was generated
using GNU tar 1.26 and its option --format=pax.
Tested successfully on NetBSD 6.1, which has a tar version lacking pax
header support.
Signed-off-by: René Scharfe
---
t/t5000-tar-tree.sh | 46 ++
t/t5000/pax.tar | Bin 0 -> 10240 bytes
2 files changed, 46 insertions(+)
create mode 100644 t/t5000/pax.tar
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index a1f35d2..c2023b1 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -30,6 +30,32 @@ GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
+test_lazy_prereq TAR_NEEDS_PAX_FALLBACK '
+ (
+ mkdir pax &&
+ cd pax &&
+ "$TAR" xf "$TEST_DIRECTORY"/t5000/pax.tar &&
+ test -f PaxHeaders.1791/file
+ )
+'
+
+get_pax_header() {
+ file=$1
+ header=$2=
+
+ while read len rest
+ do
+ if test "$len" = $(echo "$len $rest" | wc -c)
+ then
+ case "$rest" in
+ $header*)
+ echo "${rest#$header}"
+ ;;
+ esac
+ fi
+ done <"$file"
+}
+
check_tar() {
tarfile=$1.tar
listfile=$1.lst
@@ -40,6 +66,24 @@ check_tar() {
(mkdir $dir && cd $dir && "$TAR" xf -) <$tarfile
'
+ test_expect_success TAR_NEEDS_PAX_FALLBACK ' interpret pax headers' '
+ (
+ cd $dir &&
+ for header in *.paxheader
+ do
+ data=${header%.paxheader}.data &&
+ if test -h $data -o -e $data
+ then
+ path=$(get_pax_header $header path) &&
+ if test -n "$path"
+ then
+ mv "$data" "$path"
+ fi
+ fi
+ done
+ )
+ '
+
test_expect_success ' validate filenames' '
(cd ${dir_with_prefix}a && find .) | sort >$listfile &&
test_cmp a.lst $listfile
@@ -54,6 +98,8 @@ test_expect_success \
'populate workdir' \
'mkdir a &&
echo simple textfile >a/a &&
+ ten=0123456789 && hundred=$ten$ten$ten$ten$ten$ten$ten$ten$ten$ten &&
+ echo long filename >a/four$hundred &&
mkdir a/bin &&
cp /bin/sh a/bin &&
printf "A\$Format:%s\$O" "$SUBSTFORMAT" >a/substfile1 &&
diff --git a/t/t5000/pax.tar b/t/t5000/pax.tar
new file mode 100644
index
..d91173714991fded560fcd6a8aaec6aa6ec7f5e8
GIT binary patch
literal 10240
zcmeIy%?g4*5Ww+0_Y^*X&3@?Sp?k+(L29F*2+YXGPl*s(6d@sk|6W#S)Sdakm@ch^Yh?xL+x+Gv-HHCB5i+IVkN(#%@Lz{l>lx~$rg
z2GWzmuipCRCcpUG2dyNR`g93vZSz%O3b*p9Sn-k>pDo&KIhx%KXMfulr%w}@f7;`7
zyU`e%|L&jgG5=zmO1_@SxRf~Zp8x84t>bJTc^pGH_qWm2pU!{O2LS{SKmY**5I_I{
l1Q0*~0R#|0009ILKmY**5I_I{1Q0*~0R#|00D->}cmml}KZ5`O
literal 0
HcmV?d1
--
1.8.2.3
--
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
[PATCH 3/6] t5000: factor out check_tar
Create a helper function that extracts a tar archive and checks its
contents, modelled after check_zip in t5003.
Signed-off-by: René Scharfe
---
t/t5000-tar-tree.sh | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 41cd609..8337a1f 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -30,6 +30,26 @@ GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
+check_tar() {
+ tarfile=$1.tar
+ listfile=$1.lst
+ dir=$1
+ dir_with_prefix=$dir/$2
+
+ test_expect_success ' extract tar archive' '
+ (mkdir $dir && cd $dir && "$TAR" xf -) <$tarfile
+ '
+
+ test_expect_success ' validate filenames' '
+ (cd ${dir_with_prefix}a && find .) | sort >$listfile &&
+ test_cmp a.lst $listfile
+ '
+
+ test_expect_success ' validate file contents' '
+ diff -r a ${dir_with_prefix}a
+ '
+}
+
test_expect_success \
'populate workdir' \
'mkdir a &&
@@ -81,6 +101,8 @@ test_expect_success \
'git archive' \
'git archive HEAD >b.tar'
+check_tar b
+
test_expect_success \
'git tar-tree' \
'git tar-tree HEAD >b2.tar'
@@ -125,19 +147,6 @@ test_expect_success \
test_cmp .git/$(git symbolic-ref HEAD) b.commitid'
test_expect_success \
-'extract tar archive' \
-'(mkdir b && cd b && "$TAR" xf -) b.lst &&
- test_cmp a.lst b.lst'
-
-test_expect_success \
-'validate file contents' \
-'diff -r a b/a'
-
-test_expect_success \
'git tar-tree with prefix' \
'git tar-tree HEAD prefix >c.tar'
--
1.8.2.3
--
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
[PATCH 4/6] t5000: use check_tar for prefix test
Perform the full range of checks against all archived files instead of looking only at the file type of a few of them. Also add a test of a git archive with a prefix ending in with a slash, i.e. adding a full directory level. Signed-off-by: René Scharfe --- t/t5000-tar-tree.sh | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh index 8337a1f..5a9b570 100755 --- a/t/t5000-tar-tree.sh +++ b/t/t5000-tar-tree.sh @@ -103,6 +103,18 @@ test_expect_success \ check_tar b +test_expect_success 'git archive --prefix=prefix/' ' + git archive --prefix=prefix/ HEAD >with_prefix.tar +' + +check_tar with_prefix prefix/ + +test_expect_success 'git-archive --prefix=olde-' ' + git archive --prefix=olde- HEAD >with_olde-prefix.tar +' + +check_tar with_olde-prefix olde- + test_expect_success \ 'git tar-tree' \ 'git tar-tree HEAD >b2.tar' @@ -180,18 +192,6 @@ test_expect_success 'clients cannot access unreachable commits' ' test_must_fail git archive --remote=. $sha1 >remote.tar ' -test_expect_success 'git-archive --prefix=olde-' ' - git archive --prefix=olde- >h.tar HEAD && - ( - mkdir h && - cd h && - "$TAR" xf - <../h.tar - ) && - test -d h/olde-a && - test -d h/olde-a/bin && - test -f h/olde-a/bin/sh -' - test_expect_success 'setup tar filters' ' git config tar.tar.foo.command "tr ab ba" && git config tar.bar.command "tr ab ba" && -- 1.8.2.3 -- 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
[PATCH 5/6] t5000: simplify tar-tree tests
Just compare the archives created by git tar-tree with the ones created using git archive with the equivalent options, whose contents are checked already, instead of extracting them again. Signed-off-by: René Scharfe --- t/t5000-tar-tree.sh | 31 --- 1 file changed, 8 insertions(+), 23 deletions(-) diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh index 5a9b570..a1f35d2 100755 --- a/t/t5000-tar-tree.sh +++ b/t/t5000-tar-tree.sh @@ -115,14 +115,6 @@ test_expect_success 'git-archive --prefix=olde-' ' check_tar with_olde-prefix olde- -test_expect_success \ -'git tar-tree' \ -'git tar-tree HEAD >b2.tar' - -test_expect_success \ -'git archive vs. git tar-tree' \ -'test_cmp b.tar b2.tar' - test_expect_success 'git archive on large files' ' test_config core.bigfilethreshold 1 && git archive HEAD >b3.tar && @@ -158,22 +150,15 @@ test_expect_success \ 'git get-tar-commit-id b.commitid && test_cmp .git/$(git symbolic-ref HEAD) b.commitid' -test_expect_success \ -'git tar-tree with prefix' \ -'git tar-tree HEAD prefix >c.tar' - -test_expect_success \ -'extract tar archive with prefix' \ -'(mkdir c && cd c && "$TAR" xf -) c.lst && - test_cmp a.lst c.lst' +test_expect_success 'git tar-tree' ' + git tar-tree HEAD >tar-tree.tar && + test_cmp b.tar tar-tree.tar +' -test_expect_success \ -'validate file contents with prefix' \ -'diff -r a c/prefix/a' +test_expect_success 'git tar-tree with prefix' ' + git tar-tree HEAD prefix >tar-tree_with_prefix.tar && + test_cmp with_prefix.tar tar-tree_with_prefix.tar +' test_expect_success 'git archive with --output, override inferred format' ' git archive --format=tar --output=d4.zip HEAD && -- 1.8.2.3 -- 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
[PATCH 0/6] t5000: add test for pax extended header generation
This series adds a test that exercises git archive's pax header code. It checks for tar versions that don't support pax headers and works around their deficiency. The first five patches are cleanups and refactorings to centralize tar calls into a helper function. The last patch adds the workaround at this central place and a file to the test archive whose name is too long to fit into the path field of a standard tar header, making a pax extended header necessary. René Scharfe (6): t5000: integrate export-subst tests into regular tests t5000, t5003: create directories for extracted files lazily t5000: factor out check_tar t5000: use check_tar for prefix test t5000: simplify tar-tree tests t5000: test long filenames t/t5000-tar-tree.sh| 160 + t/t5000/pax.tar| Bin 0 -> 10240 bytes t/t5003-archive-zip.sh | 2 +- 3 files changed, 84 insertions(+), 78 deletions(-) create mode 100644 t/t5000/pax.tar -- 1.8.2.3 -- 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: [RFC/PATCH] patch-ids: check modified paths before calculating diff
On Sun, May 19, 2013 at 11:36:23PM -0700, Jonathan Nieder wrote: > I don't know what it should mean to try to use --cherry without > --no-merges or --first-parent, so I guess this is harmless. Currently --no-merges doesn't actually get passed down this far. We do the patch ID calculations without taking that into account. -- 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: Outdated and broken online versions of user-manual.html
Philip Oakley wrote: > From: "Thomas Ackermann" >> (5) Large overlapping with the tutorials. IMHO all of the >> tutorials should be blended into user-manual [...] > I would be a little cautious of your point 5 if it squoze everything into > one overlong document at the expense of losing the shorter documents - one > can't eat a whole melon in one bite ;-) Yes. Once there was a lovely file at Documentation/howto/isolate-bugs-with-bisect.txt explaining how to use "git bisect" to find which commit caused a kernel regression. That it was a small independent file that didn't assume the reader had read much before was very helpful, since it meant people could easily point novices to that page and say "It's easy!" when asking them to track down a bug. Nowadays that content is gracefully included in the user-manual under the heading [[using-bisect]]. But I never point people to it any more; I just write out the steps by hand, to avoid intimidating them. Ideally this content would be in an EXAMPLE or TUTORIAL section of the git-bisect(1) manpage for easier reference. Thanks, Jonathan -- 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
