Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
Am 8/27/2013 23:48, schrieb Jeff King: The counterarguments I can see are: 1. Who cares? If you want to know whether pack-objects will choke on your huge config value, then run pack-objects. 2. Such a check would involve knowing which type we use internally to look at packSizeLimit, and that is utterly undocumented (and subject to change; e.g., it seems kind of senseless that we have a 4G pack-size limit on 32-bit platforms, and we may want to fix that). So if you do not buy the argument that communicating git's internal range checks is useful, then we can simply say --int is magically long on every platform, and you can use it for everything numeric. And implement it with int64_t. You may be able to read or write some values for certain keys that git will barf on internally, but that is git's problem. I'm in the camp of these (counter) arguments. When my shell script asks for 'git config --int 3g', I expect to be returned a positive 10-digit. What would I care which type Git or any other tool is using internally? I only care whether my shell can work with numbers that large. Or the next tool that I feed the number to. But that's my business, not Git's. The one thing it doesn't get you is that you can currently set unsigned values to -1 in the config to have them treated as ULONG_MAX. This is undocumented and as far as I know not used by anyone. And it better stays that way. Magic numbers should be encoded with magic strings in the config file. -- Hannes -- 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 (Aug 2013, #06; Tue, 27)
On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: * jk/config-int-range-check (2013-08-21) 2 commits (merged to 'next' on 2013-08-22 at 465efb3) + teach git-config to output large integers + config: properly range-check integer values Originally merged to 'next' on 2013-08-22 git config --int section.var 3g should somehow diagnose that the number does not fit in int (on 32-bit platforms anyway) but it did not. Will cook in 'next'. I think Jonathan had some concerns about the test in the first one, and there was an open question in the second of whether we wanted to add something like --ulong, call it something more agnostic like --file-size, or simply teach --int to use 64-bit integers everywhere for simplicity. Thoughts? * jk/mailmap-incomplete-line (2013-08-25) 2 commits - mailmap: avoid allocation when reading from blob - mailmap: handle mailmap blobs without trailing newlines Will merge to 'next'. Did you want me to squash these? The second one more or less eradicates the changes made to the first one. I mainly did them separately in case we were going to only do the first half on maint. * jk/write-broken-index-with-nul-sha1 (2013-08-26) 1 commit - write_index: optionally allow broken null sha1s Am I waiting for another reroll? Yep, just sent v3. [Stalled] [...] * jk/list-objects-sans-blobs (2013-06-06) 4 commits . archive: ignore blob objects when checking reachability . list-objects: optimize revs-blob_objects = 0 case . upload-archive: restrict remote objects with reachability check . clear parsed flag when we free tree buffers Attempt to allow archive --remote=$there $arbitrary_sha1 while keeping the reachability safety. Seems to break some tests in a trivial and obvious way. You can probably discard this one (though you may want to take the bottom as a separate cleanup). I think we decided that the right strategy is to do the : split as we do now, but then do the normal commit-level reachability check on the left-hand side. I just haven't gotten around to writing the code yet. -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 (Aug 2013, #06; Tue, 27)
Jeff King p...@peff.net writes: On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: * jk/config-int-range-check (2013-08-21) 2 commits (merged to 'next' on 2013-08-22 at 465efb3) + teach git-config to output large integers + config: properly range-check integer values Originally merged to 'next' on 2013-08-22 git config --int section.var 3g should somehow diagnose that the number does not fit in int (on 32-bit platforms anyway) but it did not. Will cook in 'next'. I think Jonathan had some concerns about the test in the first one, and there was an open question in the second of whether we wanted to add something like --ulong, call it something more agnostic like --file-size, or simply teach --int to use 64-bit integers everywhere for simplicity. Thoughts? Are the scripts that use git config --type expected to know the representation type used by C binaries on the platform? If so, letting them say git config --ulong 3g when setting a new value, and git config --ulong when asking the current value with range checking does make sense. When the underlying code uses int (as opposed to int32_t) to read the value for a variable on any platform, then git config --int 3g that does not warn only because it is running on 64-bit platform may not help very much. The users can protect themselves by learning to use config --int32 3g, but I am not sure that is a sensible approach---rather, config --int that makes sure that the current value or the value being set is within range on any sensible platform may be a lot more user-friendly. * jk/mailmap-incomplete-line (2013-08-25) 2 commits - mailmap: avoid allocation when reading from blob - mailmap: handle mailmap blobs without trailing newlines Will merge to 'next'. Did you want me to squash these? The second one more or less eradicates the changes made to the first one. I mainly did them separately in case we were going to only do the first half on maint. Hmm, perhaps. Is reading mailmap from a blob commonly done and deserves a maint update down for 1.8.3/1.8.2 series? I'll be rewinding the 'next' soonish (either tomorrow or Thursday), so I'll try to remember not to merge this (yet). * jk/write-broken-index-with-nul-sha1 (2013-08-26) 1 commit - write_index: optionally allow broken null sha1s Am I waiting for another reroll? Yep, just sent v3. 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 (Aug 2013, #06; Tue, 27)
On Tue, Aug 27, 2013 at 9:22 PM, Junio C Hamano gits...@pobox.com wrote: * jh/remote-hg-fetch-fix (2013-07-25) 2 commits (merged to 'next' on 2013-07-25 at 33161ad) + Revert remotes-hg: bugfix for fetching non local remotes (merged to 'next' on 2013-07-24 at 9c96641) + remotes-hg: bugfix for fetching non local remotes Originally merged to 'next' on 2013-07-25 Reverted. Waiting for the final patch to replace, after discussion settles. I think it has already been replaced by: * fc/remote-hg-shared-setup (2013-08-11) 2 commits (merged to 'next' on 2013-08-14 at aae6858) + remote-hg: add shared repo upgrade + remote-hg: ensure shared repo is initialized Originally merged to 'next' on 2013-08-14 Will cook in 'next'. -- 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 (Aug 2013, #06; Tue, 27)
[+cc Jonathan] On Tue, Aug 27, 2013 at 02:05:01PM -0700, Junio C Hamano wrote: * jk/config-int-range-check (2013-08-21) 2 commits [...] I think Jonathan had some concerns about the test in the first one, and there was an open question in the second of whether we wanted to add something like --ulong, call it something more agnostic like --file-size, or simply teach --int to use 64-bit integers everywhere for simplicity. Are the scripts that use git config --type expected to know the representation type used by C binaries on the platform? I think that's an open question. My argument was that you would want to be able to get the same range errors that git would see internally. So I know that if git config --ulong pack.packSizeLimit 10g does not fail, then pack-objects itself will be fine when reading the value. So if you buy the argument that such a thing is useful, then: 1. We would want to keep the range checks we have for --int. 2. We would need new types to represent items beyond --int, and they should match what git will do internally. You can call it --ulong, or --uint64, or --file-size, or whatever you like, but --int does not cut it. The counterarguments I can see are: 1. Who cares? If you want to know whether pack-objects will choke on your huge config value, then run pack-objects. 2. Such a check would involve knowing which type we use internally to look at packSizeLimit, and that is utterly undocumented (and subject to change; e.g., it seems kind of senseless that we have a 4G pack-size limit on 32-bit platforms, and we may want to fix that). So if you do not buy the argument that communicating git's internal range checks is useful, then we can simply say --int is magically long on every platform, and you can use it for everything numeric. And implement it with int64_t. You may be able to read or write some values for certain keys that git will barf on internally, but that is git's problem. The one thing it doesn't get you is that you can currently set unsigned values to -1 in the config to have them treated as ULONG_MAX. This is undocumented and as far as I know not used by anyone. But it would be one place where the interpretation of git config key is not the same as what git does internally, and you do not get a warning or death, but rather you just get a completely different value. I don't feel too strongly either way. I mostly kept the range checks for --int because that is how the code already worked, and I assumed that was what was desired. But given what I know of the history of the config code, it is probably a completely random side effect of how it is implemented. :) I can try to prepare a series going in that direction (we still need to fix the internal truncation that currently happens, though). * jk/mailmap-incomplete-line (2013-08-25) 2 commits - mailmap: avoid allocation when reading from blob - mailmap: handle mailmap blobs without trailing newlines Will merge to 'next'. Did you want me to squash these? The second one more or less eradicates the changes made to the first one. I mainly did them separately in case we were going to only do the first half on maint. Hmm, perhaps. Is reading mailmap from a blob commonly done and deserves a maint update down for 1.8.3/1.8.2 series? Yes. The tip of jk/mailmap-from-blob turned on blob reading by default in bare repositories. So if you have a .mailmap without a terminating newline, git shortlog will segfault by default in a bare version of your repository. I do not know if it is so serious a fix that you need to go back to v1.8.2 series, but I think it is definitely maint-worthy. I was worried initially that the second part of the patch would involve too much refactoring for maint, but it actually turned out pretty simple. I'll prepare a squashed version that I think should be suitable for maint. -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 (Aug 2013, #06; Tue, 27)
Junio C Hamano gits...@pobox.com writes: What's cooking in git.git (Aug 2013, #06; Tue, 27) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Git 1.8.4 was tagged and released recently, and we will shortly go into a new development cycle for the next one, likely to be 1.8.5. In this issue of What's cooking report, I haven't started sifting the topics, most of which are marked as will cook in next, into separate bins to indicate what order they would graduate yet. After doing so, the tip of 'next' will be rewound, hopefully tomorrow but it may slip by a day or so. I am nominating the following topics to graduate to 'master' by the end of this week (or in the middle of the next week at the latest). Those graduating earlier than others are: (1) trivially correct and safe; (2) of minor impact and even if they are broken, no real harm will be done; or (3) touch parts of the system that are so important that we would want to learn unforseen breakages sooner rather than later in the cycle, and we have done sufficient reviews and testing on 'next' already. The last category is of particular importance, as we seemed to have seen a few regression reports _after_ topics that have been cooking for a long time in 'next' graduated to 'master' during the latest cycle. We need to recruit more people from minority platforms and with various different workflows to test 'next' more, but that will not happen overnight, so the next best thing we can do is to feed topics that are reasonably well cooked in 'next' early to 'master'. * nd/fetch-pack-shallow-fix (2013-08-25) 1 commit (merged to 'next' on 2013-08-27 at 7c2a162) + fetch-pack: do not remove .git/shallow file when --depth is not specified Recent short-cut clone connectivity check topic broke a shallow repository when a fetch operation tries to auto-follow tags. Will merge to 'master', aiming to later apply to 1.8.4.x maintenance track. * hv/config-from-blob (2013-08-26) 1 commit (merged to 'next' on 2013-08-27 at 7bc9019) + config: do not use C function names as struct members Portability fix. Will merge to 'master', aiming to later apply to 1.8.4.x maintenance track. * rj/doc-rev-parse (2013-07-22) 2 commits (merged to 'next' on 2013-07-22 at 8188667) + rev-parse(1): logically group options + rev-parse: remove restrictions on some options Will merge to 'master'. * mb/docs-favor-en-us (2013-08-01) 1 commit (merged to 'next' on 2013-08-06 at 763d868) + Provide some linguistic guidance for the documentation. Declare that the official grammar spelling of the source of this project is en_US, but strongly discourage patches only to fix existing en_UK strings to avoid unnecessary churns. Will merge to 'master'. * nd/sq-quote-buf (2013-07-30) 3 commits (merged to 'next' on 2013-08-01 at dc7934a) + quote: remove sq_quote_print() + tar-tree: remove dependency on sq_quote_print() + for-each-ref, quote: convert *_quote_print - *_quote_buf Code simplification as a preparatory step to something larger. Will merge to 'master'. * mm/no-shell-escape-in-die-message (2013-08-07) 1 commit (merged to 'next' on 2013-08-08 at bddff86) + die_with_status: use printf '%s\n', not echo Fixes a minor bug in git rebase -i (there could be others, as the root cause is pretty generic) where the code feeds a random, data dependeant string to 'echo' and expects it to come out literally. Will merge to 'master'. * sb/parseopt-boolean-removal (2013-08-07) 9 commits (merged to 'next' on 2013-08-08 at b138a2d) + revert: use the OPT_CMDMODE for parsing, reducing code + checkout-index: fix negations of even numbers of -n + config parsing options: allow one flag multiple times + hash-object: replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP + branch, commit, name-rev: ease up boolean conditions + checkout: remove superfluous local variable + log, format-patch: parsing uses OPT__QUIET + Replace deprecated OPT_BOOLEAN by OPT_BOOL + Remove deprecated OPTION_BOOLEAN for parsing arguments (this branch uses jc/parseopt-command-modes.) Convert most uses of OPT_BOOLEAN/OPTION_BOOLEAN that can use OPT_BOOL/OPTION_BOOLEAN which have much saner semantics, and turn remaining ones into OPT_SET_INT, OPT_COUNTUP, etc. as necessary. Will merge to 'master'. * ap/remote-hg-tilde-is-home-directory (2013-08-09) 1 commit (merged to 'next' on 2013-08-14 at cd963e3) + remote-hg: fix path when cloning with tilde expansion Will merge to 'master'. * rt/doc-merge-file-diff3 (2013-08-09) 1 commit (merged to 'next' on 2013-08-14 at 1e5847b) + Documentation/git-merge-file: document option --diff3 Will merge to 'master'. * sb/misc-cleanup (2013-08-09) 3 commits (merged to 'next' on 2013-08-14 at 9e7ff9a) + rm: remove unneeded null pointer check
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
Jeff King p...@peff.net writes: I don't feel too strongly either way. I mostly kept the range checks for --int because that is how the code already worked, and I assumed that was what was desired. But given what I know of the history of the config code, it is probably a completely random side effect of how it is implemented. :) ;-) I can try to prepare a series going in that direction (we still need to fix the internal truncation that currently happens, though). Yeah, allowing range checks to allow those who do set using git config from the command line to protect themselves is in theory a good idea, but in practice that means they need to know the internal type (and they need to know to pass --int in the first place), so it may be a losing proposition. I do not know if it is so serious a fix that you need to go back to v1.8.2 series, but I think it is definitely maint-worthy. I was worried initially that the second part of the patch would involve too much refactoring for maint, but it actually turned out pretty simple. I'll prepare a squashed version that I think should be suitable for maint. 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 (Aug 2013, #06; Tue, 27)
Antoine Pelisse apeli...@gmail.com writes: On Tue, Aug 27, 2013 at 9:22 PM, Junio C Hamano gits...@pobox.com wrote: * jh/remote-hg-fetch-fix (2013-07-25) 2 commits (merged to 'next' on 2013-07-25 at 33161ad) + Revert remotes-hg: bugfix for fetching non local remotes (merged to 'next' on 2013-07-24 at 9c96641) + remotes-hg: bugfix for fetching non local remotes Originally merged to 'next' on 2013-07-25 Reverted. Waiting for the final patch to replace, after discussion settles. I think it has already been replaced by: Surely, of course. I think I just ignored the text altogether when I moved it to the discarded section. 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 (Aug 2013, #06; Tue, 27)
On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: * kk/tests-with-no-perl (2013-08-24) 4 commits - reset test: modernize style - t/t7106-reset-unborn-branch.sh: Add PERL prerequisite - add -i test: use skip_all instead of repeated PERL prerequisite - Make test using invalid commit with -C more strict Am I waiting for another reroll? From these four commits only the second and last one are from me and I'm happy with their form as in pu (I see that you have already introduced your improvement of commit --allow-empty to the last one). Unless there are some remarks to them. But I don't know what about Jonathan's commits. As a matter of fact I have no idea how I even should reroll the topic that includes commits with mixed authorship. -- Kacper -- 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
