Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)
Antoine Pelisse apeli...@gmail.com writes: On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano gits...@pobox.com wrote: * rh/remote-hg-bzr-updates (2013-11-18) 9 commits (merged to 'next' on 2013-11-20 at a36f3c4) + remote-bzr, remote-hg: fix email address regular expression + test-hg.sh: help user correlate verbose output with email test + test-hg.sh: fix duplicate content strings in author tests + test-hg.sh: avoid obsolete 'test' syntax + test-hg.sh: eliminate 'local' bashism + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple + test-bzr.sh, test-hg.sh: allow running from any dir + test-lib.sh: convert $TEST_DIRECTORY to an absolute path + remote-hg: don't decode UTF-8 paths into Unicode objects Can wait in 'next'. Would it be possible to merge the first commit of this series in master (and eventually in maint) ? My commit (11362653: remote-hg: unquote C-style paths when exporting) breaks the remote-hg tests since v1.8.4.3 (sorry about that), and is fixed by this commit. It would be nice to deliver 1.8.5 with working remote-helpers tests. Surely. Let's do that. -- 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 (Nov 2013, #05; Thu, 21)
On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano gits...@pobox.com wrote: * rh/remote-hg-bzr-updates (2013-11-18) 9 commits (merged to 'next' on 2013-11-20 at a36f3c4) + remote-bzr, remote-hg: fix email address regular expression + test-hg.sh: help user correlate verbose output with email test + test-hg.sh: fix duplicate content strings in author tests + test-hg.sh: avoid obsolete 'test' syntax + test-hg.sh: eliminate 'local' bashism + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple + test-bzr.sh, test-hg.sh: allow running from any dir + test-lib.sh: convert $TEST_DIRECTORY to an absolute path + remote-hg: don't decode UTF-8 paths into Unicode objects Can wait in 'next'. Would it be possible to merge the first commit of this series in master (and eventually in maint) ? My commit (11362653: remote-hg: unquote C-style paths when exporting) breaks the remote-hg tests since v1.8.4.3 (sorry about that), and is fixed by this commit. It would be nice to deliver 1.8.5 with working remote-helpers tests. Cheers, Antoine -- 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 (Nov 2013, #05; Thu, 21)
On Thu, Nov 21, 2013 at 04:19:43PM -0800, Junio C Hamano wrote: * np/pack-v4 (2013-09-18) 90 commits . packv4-parse.c: add tree offset caching . t1050: replace one instance of show-index with verify-pack . index-pack, pack-objects: allow creating .idx v2 with .pack v4 . unpack-objects: decode v4 trees . unpack-objects: allow to save processed bytes to a buffer - ... Nico and Duy advancing the eternal vaporware pack-v4. This is here primarily for wider distribution of the preview edition. Temporarily ejected from 'pu', to try out jk/pack-bitmap, which this topic conflicts with. I had a look at the conflicts. Textually, I do not think it is anything too serious; it is mostly a case of adding unrelated lines in the same spot. I am happy to help with resolving that if there is a need. However, there may be semantic conflicts. The big one I can think of is how packfile reuse interacts with various versions. We only do pack reuse during a --stdout pack to a client. At this point, that means we must be outputting packv2. If we have packv2 on disk, we are fine. If we have packv4 on disk, I guess we simply need to disable reuse, which should not be hard. Once we start sending packv4 to clients, we'll have to reevaluate. Probably we can just get away with turning off reuse when there is a mismatch, though if my understanding of packv4 is correct, we could still reuse packv2 entries. We can put that off until somebody works on packv4-on-the-wire, though. :) * jk/pack-bitmap (2013-11-18) 22 commits - compat/mingw.h: Fix the MinGW and msvc builds - pack-bitmap: implement optional name_hash cache - t/perf: add tests for pack bitmaps - t: add basic bitmap functionality tests - count-objects: recognize .bitmap in garbage-checking - repack: consider bitmaps when performing repacks - repack: handle optional files created by pack-objects - repack: turn exts array into array-of-struct - repack: stop using magic number for ARRAY_SIZE(exts) - pack-objects: implement bitmap writing - rev-list: add bitmap mode to speed up object lists - pack-objects: use bitmaps when packing objects - pack-bitmap: add support for bitmap indexes - documentation: add documentation for the bitmap format - ewah: compressed bitmap implementation - compat: add endianness helpers - sha1_file: export `git_open_noatime` - revision: allow setting custom limiter function - pack-objects: factor out name_hash - pack-objects: refactor the packing list - revindex: export new APIs - sha1write: make buffer const-correct Borrows the bitmap index into packfiles from JGit to speed up enumeration of objects involved in a commit range without having to fully traverse the history. Looks like you picked up my latest re-roll with Ramsay's fix on top. There wasn't a lot of review on this past round (I'm not surprised; it's a dauntingly large chunk to review). I outlined a few possible open issues in the cover letter, but I'd be happy to build those on top, which I think will make review of them a lot easier. Do we want to try this in 'next' post-1.8.5, or should I try to prod an area expert like Shawn into doing another round of review? -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: What's cooking in git.git (Nov 2013, #05; Thu, 21)
Jeff King p...@peff.net writes: * jk/pack-bitmap (2013-11-18) 22 commits [...] Borrows the bitmap index into packfiles from JGit to speed up enumeration of objects involved in a commit range without having to fully traverse the history. Looks like you picked up my latest re-roll with Ramsay's fix on top. There wasn't a lot of review on this past round (I'm not surprised; it's a dauntingly large chunk to review). I outlined a few possible open issues in the cover letter, but I'd be happy to build those on top, which I think will make review of them a lot easier. Do we want to try this in 'next' post-1.8.5, or should I try to prod an area expert like Shawn into doing another round of review? Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on or responded to my June reviews in this thread: http://thread.gmane.org/gmane.comp.version-control.git/228918 and again mentioned here, though I didn't point out all of them: http://thread.gmane.org/gmane.comp.version-control.git/236587/focus=236740 Granted, the way I verified this was checking whether you renamed rlw_xor_run_bit() to something more fitting, so perhaps you just forgot that one thing but did all the rest. -- Thomas Rast t...@thomasrast.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 (Nov 2013, #05; Thu, 21)
On Fri, Nov 22, 2013 at 05:52:37PM +0100, Thomas Rast wrote: Looks like you picked up my latest re-roll with Ramsay's fix on top. There wasn't a lot of review on this past round (I'm not surprised; it's a dauntingly large chunk to review). I outlined a few possible open issues in the cover letter, but I'd be happy to build those on top, which I think will make review of them a lot easier. Do we want to try this in 'next' post-1.8.5, or should I try to prod an area expert like Shawn into doing another round of review? Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on or responded to my June reviews in this thread: http://thread.gmane.org/gmane.comp.version-control.git/228918 and again mentioned here, though I didn't point out all of them: http://thread.gmane.org/gmane.comp.version-control.git/236587/focus=236740 Sorry, I didn't respond directly to the email. Vicent did a pass for style and documentation shortly after the initial series, and then I did another pass in the most recent re-roll, adding a C fallback for the gcc builtin. I thought that covered it, but: Granted, the way I verified this was checking whether you renamed rlw_xor_run_bit() to something more fitting, so perhaps you just forgot that one thing but did all the rest. I didn't touch that. Vicent, did you have a comment on the name (it really does look like it is a negation, and the only caller is ewah_not). -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: What's cooking in git.git (Nov 2013, #05; Thu, 21)
Jeff King p...@peff.net writes: Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on or responded to my June reviews in this thread: http://thread.gmane.org/gmane.comp.version-control.git/228918 [...] Granted, the way I verified this was checking whether you renamed rlw_xor_run_bit() to something more fitting, so perhaps you just forgot that one thing but did all the rest. I didn't touch that. Vicent, did you have a comment on the name (it really does look like it is a negation, and the only caller is ewah_not). Hmm, so it really was that one unlucky thing :-) I don't have much to say on the area, but if you think it helps you I can set aside some time RSN to review the second half of the series, too. Back in June I only looked at the first half. -- Thomas Rast t...@thomasrast.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 (Nov 2013, #05; Thu, 21)
Jeff King p...@peff.net writes: Looks like you picked up my latest re-roll with Ramsay's fix on top. There wasn't a lot of review on this past round (I'm not surprised; it's a dauntingly large chunk to review). I outlined a few possible open issues in the cover letter, but I'd be happy to build those on top, which I think will make review of them a lot easier. Do we want to try this in 'next' post-1.8.5, or should I try to prod an area expert like Shawn into doing another round of review? Yes ;-). I recall starting to read the series over and then got sidetracked in the middle and never finishing. I'll try to make time sometime this weekend (we are still buried in boxes after the move, though, so no promises) myself. How close is this what you guys are running in production these days, by the way? -- 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 (Nov 2013, #05; Thu, 21)
On Fri, Nov 22, 2013 at 6:26 PM, Jeff King p...@peff.net wrote: Granted, the way I verified this was checking whether you renamed rlw_xor_run_bit() to something more fitting, so perhaps you just forgot that one thing but did all the rest. I didn't touch that. Vicent, did you have a comment on the name (it really does look like it is a negation, and the only caller is ewah_not). Yes, the name was ported straight from the original library and kept as-is to make the translation more straightforward. These sources are --again-- a translation, so I tried to remain as close to the original Java implementation as possible. I agree the name is not ideal, but it does make quite a bit of sense. It effectively inverts the word based on the run bit, which is the equivalent of xoring it with the bit if it's one. Love, vmg -- 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 (Nov 2013, #05; Thu, 21)
On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano gits...@pobox.com wrote: Do we want to try this in 'next' post-1.8.5, or should I try to prod an area expert like Shawn into doing another round of review? Yes ;-). I recall starting to read the series over and then got sidetracked in the middle and never finishing. I'll try to make time sometime this weekend (we are still buried in boxes after the move, though, so no promises) myself. How close is this what you guys are running in production these days, by the way? We are running a slightly older version of the patchset, because we're still on 1.8.4 and the current reroll doesn't apply cleanly there. If this could make it to `next` some time next week, that would work out great for us, because we may start considering using `next` as a partial or full deployment on our production machines This also means that we could exercise the patchset and everything else that is queued up in next release... You must remember all the corner cases and bugs peff brings to the list every time we deploy a new Git to production. Wouldn't it be nice to have a thorough checking of the current iteration *before* the release, and not after? :) *hint hint* -- 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 (Nov 2013, #05; Thu, 21)
Vicent Martà tan...@gmail.com writes: On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano gits...@pobox.com wrote: We are running a slightly older version of the patchset, because we're still on 1.8.4 and the current reroll doesn't apply cleanly there. If this could make it to `next` some time next week, that would work out great for us, because we may start considering using `next` as a partial or full deployment on our production machines I do not think potentially incompatible stuff that are slated for 2.0 that have been cooking in 'next' affects the server side, so that may be a good and safe move. This also means that we could exercise the patchset and everything else that is queued up in next release... There is no 'next release' though; there is no guarantee what is cooking in 'next' will be in any future release ;-). In any case, it is nice to see that people from a large hosting site finally taking a hint from my occasional light complaints that come after thanks for reporting whenever I see regression and breakage report soon after a topic graduates to 'master' ;-). It is good to see that more people starting to adopt the 'next' branch early for wider testing. 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: What's cooking in git.git (Nov 2013, #05; Thu, 21)
Vicent Marti vic...@github.com writes: On Fri, Nov 22, 2013 at 6:26 PM, Jeff King p...@peff.net wrote: I didn't touch that. Vicent, did you have a comment on the name (it really does look like it is a negation, and the only caller is ewah_not). Yes, the name was ported straight from the original library and kept as-is to make the translation more straightforward. These sources are --again-- a translation, so I tried to remain as close to the original Java implementation as possible. I agree the name is not ideal, but it does make quite a bit of sense. It effectively inverts the word based on the run bit, which is the equivalent of xoring it with the bit if it's one. It's a funny xor that doesn't take a second argument ;-) Anyway, let's not argue forever about the choice of this name. It's just the first thing that came to my mind from the original review, so I used it as an indicator to see if you had done something about it. It seems I picked an indicator that is not significant for the overall state. -- Thomas Rast t...@thomasrast.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 (Nov 2013, #05; Thu, 21)
On Fri, Nov 22, 2013 at 12:05:25PM -0800, Junio C Hamano wrote: If this could make it to `next` some time next week, that would work out great for us, because we may start considering using `next` as a partial or full deployment on our production machines I do not think potentially incompatible stuff that are slated for 2.0 that have been cooking in 'next' affects the server side, so that may be a good and safe move. I do not think we will literally run `next` in this case, but probably v1.8.5 + selected topics (like this one :) ). We do not need to base ourselves on a release, of course, and we may start using a rolling version of master, but choose quiescent points in the cycle (like starting with a release, and then rolling forward around -rc time). I started trying that with this cycle, which is how I found the --literal-pathspec regression in mid-cycle, and then found out the fix hadn't graduated during -rc. :) If that proves stable, then I will consider bumping up our frequency of following `master`, and then eventually following `next` (possibly with some lag). As a large site, we get to expose the code to a lot of new people; but we also need to be mindful that we are exposing a lot of people to new bugs. -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: What's cooking in git.git (Nov 2013, #05; Thu, 21)
On Fri, Nov 22, 2013 at 06:58:55PM +0100, Thomas Rast wrote: I didn't touch that. Vicent, did you have a comment on the name (it really does look like it is a negation, and the only caller is ewah_not). Hmm, so it really was that one unlucky thing :-) I don't promise there is only one unlucky thing. :) Only that we made a good faith effort to address the comments. There were a lot of comments and a lot of re-rolls, and I would not be surprised if something else was missed (I am not thinking of anything in particular, but just preparing you mentally). I don't have much to say on the area, but if you think it helps you I can set aside some time RSN to review the second half of the series, too. Back in June I only looked at the first half. I would love that. My comments to Junio were not to rush the topic, but mainly to keep it progressing. Re-rolling such a big chunk of code _is_ a pain for both me and for reviewers, so I wouldn't mind switching to fixes on top instead of re-rolling at some point. But we can do another round or two of re-roll first. -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: What's cooking in git.git (Nov 2013, #05; Thu, 21)
Jeff King p...@peff.net writes: Re-rolling such a big chunk of code _is_ a pain for both me and for reviewers, so I wouldn't mind switching to fixes on top instead of re-rolling at some point. But we can do another round or two of re-roll first. No, actually I think the plan that you sketched in the other side thread sounded nice: give it some exposure in next. I'll still try and read the rest, but that way it hopefully gets (much) more testing. -- Thomas Rast t...@thomasrast.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
What's cooking in git.git (Nov 2013, #05; Thu, 21)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Hopefully 1.8.5-rc3 that was tagged on Wednesday will be the final release candidate for this cycle. 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] * nd/liteal-pathspecs (2013-10-28) 1 commit (merged to 'next' on 2013-11-01 at 1a91775) + pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses Fixes a regression on 'master' since v1.8.4. -- [New Topics] * jj/doc-markup-hints-in-coding-guidelines (2013-11-18) 1 commit (merged to 'next' on 2013-11-21 at 9c638a6) + State correct usage of literal examples in man pages in the coding standards Can wait in 'next'. * jn/perl-lib-extra (2013-11-18) 2 commits (merged to 'next' on 2013-11-20 at 8c90afae) + Makefile: add PERLLIB_EXTRA variable that adds to default perl path + Makefile: rebuild perl scripts when perl paths change * jj/doc-markup-gitcli (2013-11-20) 1 commit (merged to 'next' on 2013-11-21 at 5e49fa8) + Documentation/gitcli.txt: fix double quotes Can wait in 'next'. * jk/remove-experimental-loose-object-support (2013-11-21) 1 commit (merged to 'next' on 2013-11-21 at d37bab7) + drop support for experimental loose objects Can wait in 'next'. * jl/commit-v-strip-marker (2013-11-19) 1 commit - commit -v: strip diffs and submodule shortlogs from the commit message Perhaps another reroll for core.commentChar coming? * nd/glossary-content-pathspec-markup (2013-11-21) 1 commit (merged to 'next' on 2013-11-21 at 6072636) + glossary-content.txt: fix documentation of ** patterns Can wait in 'next'. * nd/magic-pathspec (2013-11-20) 1 commit (merged to 'next' on 2013-11-21 at f914a30) + diff: restrict pathspec limitations to diff b/f case only Can wait in 'next'. -- [Stalled] * fc/transport-helper-fixes (2013-11-13) 12 commits - remote-bzr: support the new 'force' option - transport-helper: add support to delete branches - fast-export: add support to delete refs - fast-import: add support to delete refs - transport-helper: add support for old:new refspec - fast-export: add new --refspec option - fast-export: improve argument parsing - test-hg.sh: tests are now expected to pass - transport-helper: check for 'forced update' message - transport-helper: add 'force' to 'export' helpers - transport-helper: don't update refs in dry-run - transport-helper: mismerge fix Updates transport-helper, fast-import and fast-export to allow the ref mapping and ref deletion in a way similar to the natively supported transports. The option name --refspec needs to be rethought. It does not mean what refspec usually means, even though it shares the same syntax with refspec; calling it --refspec only because it shares the same syntax is like calling it --asciistring and does not make sense. * nv/commit-gpgsign-config (2013-11-06) 1 commit - Add the commit.gpgsign option to sign all commits Introduce commit.gpgsign configuration variable to force every commit to be GPG signed. Needs tests, perhaps? * tb/clone-ssh-with-colon-for-port (2013-11-04) 1 commit . git clone: is an URL local or ssh Still being reworked. * cn/thin-push-capability (2013-11-06) 2 commits - send-pack: only send a thin pack if the server supports it - receive-pack: advertise thin-pack Peff had a good suggestion to control this by expressing what the receiving end wants in a more direct way, namely to advertise a 'no-thin' trait in the capability list, which seems to be favored by Shawn, too. * jt/commit-fixes-footer (2013-10-30) 1 commit - commit: Add -f, --fixes commit option to add Fixes: line There is an ongoing discussion around this topic; in general I am fairly negative on a new feature that is too narrow and prefer a more generic solution that can be tailored for specific needs, as many people stated in the thread. It appears that the discussion stalled. * np/pack-v4 (2013-09-18) 90 commits . packv4-parse.c: add tree offset caching . t1050: replace one instance of show-index with verify-pack . index-pack, pack-objects: allow creating .idx v2 with .pack v4 . unpack-objects: decode v4 trees . unpack-objects: allow to save processed bytes to a buffer - ... Nico and Duy advancing the eternal vaporware pack-v4. This is here primarily for wider distribution of the preview edition. Temporarily ejected from 'pu', to try out jk/pack-bitmap, which this topic conflicts with. * jk/pack-bitmap (2013-11-18) 22 commits - compat/mingw.h: Fix the MinGW and msvc builds - pack-bitmap: implement optional name_hash cache - t/perf: add tests for pack bitmaps -
