Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Junio C Hamano gits...@pobox.com writes:
* tr/test-v-and-v-subtest-only (2013-06-18) 8 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: self-test that --verbose works
- test-lib: rearrange start/end of test_expect_* and test_skip
- 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 two may be useful in practice but is a tad ugly ;-)
Will merge to 'next'.
Please hold off; Fredrik found an issue with the test automation that
bisects to verbose mode for only tests matching a pattern; when
running with the 'test' target (not with prove however), the suite
reports
failed test(s):
fixed 0
success 9788
failed 2
broken 69
total 9989
Even worse, I botched a rebase that makes the commit before --
self-test that --verbose works untestable. I'm pretty sure that it
has the same problem, too, though I'm still investigating the actual
issue.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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 (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: Because the implementation is too ugly. I know :) The only reason I sent it with code is because I didn't get any responses to an email without code. If you agree that it is a useful feature, we have to figure out a beautiful implementation. I would however can imagine an alternative implementation which might be more palatable. It may go like this: [alias lgF] command = log --oneline --boundary --first-parent help = show the first parent chain, one line per commit I'm not sure what value this adds. If I ever forget what my alias is called, I `git rp --help` to get the expansion and then look up the manpage. It would be ideal if I could `man git lgF` though: I'm sick of having to type out `man git for-each-ref` everytime I need the manpage for fer (obviously an unscripted `man` won't work: `git help` will do the translation). completion = log Again, unsure what value it adds. I already have plenty of aliases that complete fine. The completion only fails if I have an !-command; in that case, this solution is a hack: we should work towards not requiring an !-command in the first place. so that not just alias.c code can take notice of alias.lgF.command to expand it, How? Fundamentally, alias_lookup_cb() is a fired off by the config-parsing infrastructure which calls a tolower() on everything: alias.c has control over nothing, unless we re-implement the entire config-parsing infrastructure specifically for aliases (Bad idea). I don't see how changing from alias.name to alias.name.command helps anything, especially when the other alias.name.* keys aren't even useful. but we can later extend it to help git help lgF Yeah, this is a good idea. and bash/zsh completion (i.e. they would learn lgF parameter would complete in a way similar to 'log' from alias.lgF.completion). Solved problem: see __git_aliased_command() in git-completion.bash. -- 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 (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: * rr/triangle-push-fix (2013-06-20) 9 commits - push: honor branch.*.push - SQUASH??? fix git-config push.default description - SQUASH??? minimum simple safety fix-up - t/t5528-push-default: test pushdefault workflows - t/t5528-push-default: generalize test_push_* - push: remove dead code in setup_push_upstream() - push: change `simple` to accommodate triangular workflows - config doc: rewrite push.default section - t/t5528-push-default: remove redundant test_config lines Give me some more time to perfect this. * rr/rebase-checkout-reflog (2013-06-17) 8 commits - SQUASH??? - rebase -i: use a better reflog message - rebase: use a better reflog message - checkout: respect GIT_REFLOG_ACTION - status: do not depend on rebase reflog messages - t/t2021-checkout-last: checkout - should work after a rebase finishes - wt-status: remove unused field in grab_1st_switch_cbdata - t7512: test detached from as well Waiting for a reroll. $gmane/228271. Please pick up $gmane/228371. -- Four topics are awaiting review (they're important to me in this order): - rr/for-each-ref-pretty at $gmane/227057. - rr/describe-contains-all at $gmane/228278. - rr/mixed-case-aliases at $gmane/227959. - rr/completion-word-diff at $gmane/228305. One topic is stalled: - rr/pull-autostash at $gmane/227796. -- 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 (Jun 2013, #07; Thu, 20)
Ramkumar Ramachandra artag...@gmail.com writes: Four topics are awaiting review (they're important to me in this order): - rr/for-each-ref-pretty at $gmane/227057. No comment on this at this moment. - rr/describe-contains-all at $gmane/228278. This may overlap with a topic in flight (but I didn't look at it). - rr/mixed-case-aliases at $gmane/227959. Personally, not just uninterested but moderately against. - rr/completion-word-diff at $gmane/228305. This was missed in the noise; obviously good and will pick up. I do not think I am the most qualified reviewer in some of the areas they touch, I do not want to be the only one who is reviewing patches here, and I am personally not very much interested in seeing these topics in Git, so I've been waiting if somebody else shows interest and starts reviewing. Which is not happening, so perhaps nobody is interested in them? -- 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 (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: - rr/describe-contains-all at $gmane/228278. This may overlap with a topic in flight (but I didn't look at it). Let me know if I can do anything to make it easier for you. I'm quite excited about this one. - rr/mixed-case-aliases at $gmane/227959. Personally, not just uninterested but moderately against. Okay, but I'd like an explanation. I do not think I am the most qualified reviewer in some of the areas they touch, I do not want to be the only one who is reviewing patches here, and I am personally not very much interested in seeing these topics in Git, so I've been waiting if somebody else shows interest and starts reviewing. Which is not happening, so perhaps nobody is interested in them? I don't know what happened. I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Everyone must share the burden of review, and I try to do my bit. -- 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 (Jun 2013, #07; Thu, 20)
Ramkumar Ramachandra artag...@gmail.com writes: ... I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Hmph, I do not particularly see that happening. I actually think all the usual suspects (I could name them, but I wouldn't---you know who you are) are doing a reasonably good job on patches that touch parts of the system that matter. Patches on the fringes (e.g. stuff in contrib/) may need a bit more love, though. -- 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 (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: ... I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Hmph, I do not particularly see that happening. Observer bias. To verify either claim, could you run some stats on the ML archives [1] and report the results? [1]: I lost the copy Peff gave me because I kept it locally. -- 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 (Jun 2013, #07; Thu, 20)
On Fri, Jun 21, 2013 at 7:13 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Junio C Hamano wrote: ... I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Hmph, I do not particularly see that happening. Observer bias. To verify either claim, could you run some stats on the ML archives [1] and report the results? Do we really need that ? Flaming generates lots of useless discussions that would be difficult to interpret/extract from your numbers. I think we should focus on improving what is left to improve. That is of course merely my humble opinion. -- 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 (Jun 2013, #07; Thu, 20)
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: ... I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Hmph, I do not particularly see that happening. Observer bias. To verify either claim, could you run some stats on the ML archives [1] and report the results? Unfortunately, I tend to become bottleneck more often than you do, so I do not think that would be a good use of my time. Which ones went unreviewed that are of high value? -- 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 (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: Unfortunately, I tend to become bottleneck more often than you do, so I do not think that would be a good use of my time. Besides, as Antoine points out, those numbers might well be useless (or worse, misleading). It's probably not worth the effort. Which ones went unreviewed that are of high value? My observation can be boiled down to: I usually never get the opportunity to say something useful on most patches, because someone else already has; that has not been the case offlate. Probably some bias: I tried looking for examples and counter-examples, but the list is too large for individual patches to make any sense. I did run a script on git.git to see if there are any recent trends: if I'm right about patches not being reviewed, it must ultimately show up somewhere, right? v1.7.0..v1.7.1:: 702 jc (68), jn (50), jh (32), tr (22), jk (19), tr (19), mj (18), sb (15), bc (11), jl (10) v1.7.1..v1.7.2:: 772 jc (57), jn (56), Æa (32), mj (26), jk (21), tr (20), bc (19), gv (18), jn (18), cc (17) v1.7.2..v1.7.3:: 624 jn (117), Æa (64), jc (28), mm (23), nt (23), en (18), bc (17), tr (17), js (15), jl (12) v1.7.3..v1.7.4:: 1025 jn (89), nt (68), jc (59), en (54), jk (27), mj (26), Æa (25), ef (23), jh (23), ra (20) v1.7.4..v1.7.5:: 734 jn (90), Æa (79), jc (64), mj (40), jk (38), nt (31), bw (16), hv (13), pw (12), jl (10) v1.7.5..v1.7.6:: 650 jc (112), jk (51), mv (35), jn (28), jn (20), mj (16), jh (15), Æa (12), mk (11), jm (9) v1.7.6..v1.7.7:: 779 jc (105), jk (60), en (55), Æa (48), mh (44), js (19), di (16), jn (16), sr (15), tr (15) v1.7.7..v1.7.8:: 644 jc (85), mh (37), jk (31), rs (26), rr (23), jn (18), nt (15), bc (13), mj (10), ra (9) v1.7.8..v1.7.9:: 565 jc (82), jk (62), nt (24), mh (23), pw (18), jn (16), tr (15), bw (14), mv (11), pt (11) v1.7.9..v1.7.10:: 683 jc (84), jk (40), jn (27), nt (25), tr (21), jn (18), jx (15), zj (15), mh (13), th (11) v1.7.10..v1.7.11:: 925 jc (92), ap (73), jk (69), nt (39), rs (38), mh (37), jn (25), jx (19), rt (17), zj (17) v1.7.11..v1.7.12:: 548 jc (107), jk (51), mm (29), jx (15), mg (14), nt (14), pw (13), jn (12), as (7), cw (7) v1.8.0..v1.8.1:: 525 jc (55), jk (41), fc (32), nt (19), fa (15), mh (12), km (11), ta (11), mo (10), rr (9) v1.8.1..v1.8.2:: 957 jc (107), nt (53), jk (39), pw (35), jk (33), as (31), mh (31), fc (26), mv (23), wt (17) v1.8.2..v1.8.3:: 1005 fc (112), jc (95), jk (89), nt (35), jk (29), da (26), rr (24), tr (18), bc (15), jn (15) v1.8.3..master:: 497 fc (112), mh (60), rr (24), jc (23), rs (21), tr (18), kb (15), js (13), ra (12), nt (11) Meh, it looks normal. Sorry for the noise: I don't think there's any cause for worry. -- 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 (Jun 2013, #07; Thu, 20)
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: - rr/describe-contains-all at $gmane/228278. This may overlap with a topic in flight (but I didn't look at it). Let me know if I can do anything to make it easier for you. I'm quite excited about this one. - rr/mixed-case-aliases at $gmane/227959. Personally, not just uninterested but moderately against. Okay, but I'd like an explanation. Because the implementation is too ugly. The damage to the more generic config parser codepath is a real downside and the benefit from the little feature does not seem to justify it. I would however can imagine an alternative implementation which might be more palatable. It may go like this: [alias lgF] command = log --oneline --boundary --first-parent help = show the first parent chain, one line per commit completion = log so that not just alias.c code can take notice of alias.lgF.command to expand it, but we can later extend it to help git help lgF and bash/zsh completion (i.e. they would learn lgF parameter would complete in a way similar to 'log' from alias.lgF.completion). -- 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
