Re: What's cooking in git.git (Jul 2013, #09; Mon, 29)
Mark Levedahl writes: > I have been using this patch since Ramsey first sent it, have noticed > no trouble over that time but all of my work is with filemode=true > (has been since I started using git as Cygwin is a secondary platform > for me and interoperability with repos on Linux is an absolute > requirement). Torsten Bögershausen writes: > So I think we can and should remove compat/cygwin.[ch] without further > cooking, to be on the save side. 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 (Jul 2013, #09; Mon, 29)
On 08/01/2013 05:12 PM, Junio C Hamano wrote: Ramsay Jones writes: Junio C Hamano wrote: Ramsay Jones writes: I am personally in favor of this simpler solution. Comments? I had expected this to me marked for 'master'. Has this simply been overlooked, or do you have reservations about applying this patch? I am just being careful and do want to keep it cooking in 'next' during the feature freeze. The more users work with 'next' (not "work *on* 'next'"), the more confidence we would be with, and hopefully this can be one of the topis that graduate early after the 1.8.4 release. Hmm, this patch is a bug-fix for a bug that (currently) will be _introduced_ by v1.8.4. OK, let's merge it then. Thanks for being patient with me. Do you want me to try and find a different bug-fix for v1.8.4? (Although that would most likely be more risky than simply taking this patch! ;-) ). Absolutely not, and I 100% agree with you. I have been using this patch since Ramsey first sent it, have noticed no trouble over that time but all of my work is with filemode=true (has been since I started using git as Cygwin is a secondary platform for me and interoperability with repos on Linux is an absolute requirement). Mark -- 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 (Jul 2013, #09; Mon, 29)
On 2013-08-03 08.50, Torsten Bögershausen wrote: > On 2013-08-01 22.51, Ramsay Jones wrote: >> Junio C Hamano wrote: >>> Ramsay Jones writes: >>> > I am personally in favor of this simpler solution. Comments? I had expected this to me marked for 'master'. Has this simply been overlooked, or do you have reservations about applying this patch? >>> >>> I am just being careful and do want to keep it cooking in 'next' >>> during the feature freeze. The more users work with 'next' (not >>> "work *on* 'next'"), the more confidence we would be with, and >>> hopefully this can be one of the topis that graduate early after >>> the 1.8.4 release. >> >> Hmm, this patch is a bug-fix for a bug that (currently) will be >> _introduced_ by v1.8.4. >> >> Do you want me to try and find a different bug-fix for v1.8.4? >> (Although that would most likely be more risky than simply taking >> this patch! ;-) ). >> >> ATB, >> Ramsay Jones > > I just managed to run v1.8.4-rc1 under cygwin 1.7, and it all passed. > Good work, thanks. > > I realized that core.filemode is true by default, which > by default switches of the stat()/lstat() code in cygwin.c > > Which bug fix are we missing for v1.8.4 ? > /Torsten Oh, the problem is of course that users have existing repos where core.filemode = false. So I think we can and should remove compat/cygwin.[ch] without further cooking, to be on the save side. (Just to be sure: this is what we are talking about ?) /Torsten -- 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 (Jul 2013, #09; Mon, 29)
On 2013-08-01 22.51, Ramsay Jones wrote: > Junio C Hamano wrote: >> Ramsay Jones writes: >> I am personally in favor of this simpler solution. Comments? >>> >>> I had expected this to me marked for 'master'. >>> >>> Has this simply been overlooked, or do you have reservations about >>> applying this patch? >> >> I am just being careful and do want to keep it cooking in 'next' >> during the feature freeze. The more users work with 'next' (not >> "work *on* 'next'"), the more confidence we would be with, and >> hopefully this can be one of the topis that graduate early after >> the 1.8.4 release. > > Hmm, this patch is a bug-fix for a bug that (currently) will be > _introduced_ by v1.8.4. > > Do you want me to try and find a different bug-fix for v1.8.4? > (Although that would most likely be more risky than simply taking > this patch! ;-) ). > > ATB, > Ramsay Jones I just managed to run v1.8.4-rc1 under cygwin 1.7, and it all passed. Good work, thanks. I realized that core.filemode is true by default, which by default switches of the stat()/lstat() code in cygwin.c Which bug fix are we missing for v1.8.4 ? /Torsten -- 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 (Jul 2013, #09; Mon, 29)
Ramsay Jones writes: > Junio C Hamano wrote: >> Ramsay Jones writes: >> I am personally in favor of this simpler solution. Comments? >>> >>> I had expected this to me marked for 'master'. >>> >>> Has this simply been overlooked, or do you have reservations about >>> applying this patch? >> >> I am just being careful and do want to keep it cooking in 'next' >> during the feature freeze. The more users work with 'next' (not >> "work *on* 'next'"), the more confidence we would be with, and >> hopefully this can be one of the topis that graduate early after >> the 1.8.4 release. > > Hmm, this patch is a bug-fix for a bug that (currently) will be > _introduced_ by v1.8.4. OK, let's merge it then. Thanks for being patient with me. > Do you want me to try and find a different bug-fix for v1.8.4? > (Although that would most likely be more risky than simply taking > this patch! ;-) ). Absolutely not, and I 100% agree with you. -- 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 (Jul 2013, #09; Mon, 29)
Junio C Hamano wrote: > Ramsay Jones writes: > >>> I am personally in favor of this simpler solution. Comments? >> >> I had expected this to me marked for 'master'. >> >> Has this simply been overlooked, or do you have reservations about >> applying this patch? > > I am just being careful and do want to keep it cooking in 'next' > during the feature freeze. The more users work with 'next' (not > "work *on* 'next'"), the more confidence we would be with, and > hopefully this can be one of the topis that graduate early after > the 1.8.4 release. Hmm, this patch is a bug-fix for a bug that (currently) will be _introduced_ by v1.8.4. Do you want me to try and find a different bug-fix for v1.8.4? (Although that would most likely be more risky than simply taking this patch! ;-) ). ATB, Ramsay Jones -- 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 (Jul 2013, #09; Mon, 29)
Ramsay Jones writes: >> I am personally in favor of this simpler solution. Comments? > > I had expected this to me marked for 'master'. > > Has this simply been overlooked, or do you have reservations about > applying this patch? I am just being careful and do want to keep it cooking in 'next' during the feature freeze. The more users work with 'next' (not "work *on* 'next'"), the more confidence we would be with, and hopefully this can be one of the topis that graduate early after the 1.8.4 release. -- 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 (Jul 2013, #09; Mon, 29)
Junio C Hamano wrote: > 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 shape of the upcoming release is pretty much known by now; all > the topics that are marked for 'master' in this issue will likely to > be in the final, and others will cook during the pre-release freeze > period. > [ ... ] > > * rj/cygwin-clarify-use-of-cheating-lstat (2013-07-18) 1 commit > - cygwin: Remove the Win32 l/stat() implementation > > Cygwin port added a "not quite correct but a lot faster and good > enough for many lstat() calls that are only used to see if the > working tree entity matches the index entry" lstat() emulation some > time ago, and it started biting us in places. This removes it and > uses the standard lstat() that comes with Cygwin. > > I am personally in favor of this simpler solution. Comments? I had expected this to me marked for 'master'. Has this simply been overlooked, or do you have reservations about applying this patch? If so, then I need to find another solution very quickly [1] (before v1.8.4). At this time, despite passing the test suite [2], the cygwin build is still very much broken. ATB, Ramsay Jones [1] I do have another patch, patch #0 actually, which I said I didn't want applied! :-P [2] I ran the test suite on v1.8.4-rc0 + 1 patch, like so: $ GIT_SKIP_TESTS='t0061.3' make test >test-outp16 2>&1 $ tail -17 test-outp16 [22:33:53] t9902-completion.sh ok13650 ms [22:34:26] t9903-bash-prompt.sh ... ok33468 ms [22:34:26] All tests successful. Test Summary Report --- t7008-grep-binary.sh (Wstat: 0 Tests: 23 Failed: 0) TODO passed: 12 Files=639, Tests=10291, 9581 wallclock secs ( 2.75 usr 1.41 sys + 9421.84 cusr 4551.31 csys = 13977.31 CPU) Result: PASS make clean-except-prove-cache make[2]: Entering directory `/home/ramsay/git/t' rm -f -r 'trash directory'.* 'test-results' rm -f -r valgrind/bin make[2]: Leaving directory `/home/ramsay/git/t' make[1]: Leaving directory `/home/ramsay/git/t' $ This was over 30 minutes faster than the last full test suite run, but it also ran more tests (420 test files ran faster and 16 new test files were run). I've *never* had the test suite run faster before! (I'm not going to celebrate too much; it still took 9581s = 2h39m41s). -- 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 (Jul 2013, #09; Mon, 29)
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 shape of the upcoming release is pretty much known by now; all the topics that are marked for 'master' in this issue will likely to be in the final, and others will cook during the pre-release freeze period. 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"] * ob/typofixes (2013-07-22) 3 commits (merged to 'next' on 2013-07-22 at 8574f9f) + typofix: in-code comments + typofix: documentation + typofix: release notes * es/contacts (2013-07-21) 5 commits (merged to 'next' on 2013-07-22 at a78c3d6) + contrib: contacts: add documentation + contrib: contacts: add mailmap support + contrib: contacts: interpret committish akin to format-patch + contrib: contacts: add ability to parse from committish + contrib: add git-contacts helper A helper to read from a set of format-patch output files or a range of commits and find those who may have insights to the code that the changes touch by running a series of "git blame" commands. * es/line-log-further-fixes (2013-07-23) 5 commits + line-log: fix "log -LN" crash when N is last line of file + range-set: satisfy non-empty ranges invariant + t4211: demonstrate crash when first -L encountered is empty range + t4211: demonstrate empty -L range crash + range-set: fix sort_and_merge_range_set() corner case bug (this branch is used by tr/line-log.) * jk/cat-file-batch-optim (2013-07-18) 9 commits (merged to 'next' on 2013-07-22 at 965897c) + Fix some sparse warnings + sha1_object_info_extended: pass object_info to helpers + sha1_object_info_extended: make type calculation optional + packed_object_info: make type lookup optional + packed_object_info: hoist delta type resolution to helper + sha1_loose_object_info: make type lookup optional + sha1_object_info_extended: rename "status" to "type" + cat-file: disable object/refname ambiguity check for batch mode + Merge branch 'nd/warn-ambiguous-object-name' into jk/cat-file-batch-optim If somebody wants to only know on-disk footprint of an object without having to know its type or payload size, we can bypass a lot of code to cheaply learn it. * jm/doc-ref-prune (2013-07-18) 2 commits (merged to 'next' on 2013-07-22 at 414e6ea) + Documentation: fix git-prune example usage + Documentation: remove --prune from pack-refs examples * mh/multimail (2013-07-22) 2 commits (merged to 'next' on 2013-07-22 at e27c933) + post-receive-email: deprecate script in favor of git-multimail + git-multimail: an improved replacement for post-receive-email An enhanced "post-receive" hook to send e-mail messages. * mh/ref-races-optim-invalidate-cached (2013-06-20) 1 commit (merged to 'next' on 2013-07-22 at 144d135) + refs: do not invalidate the packed-refs cache unnecessarily This requires the platform lstat() to be correct to avoid false negatives. * ml/avoid-using-grep-on-crlf-files (2013-07-18) 1 commit (merged to 'next' on 2013-07-22 at f861472) + test-lib.sh - define and use GREP_STRIPS_CR On systems that understand a CRLF as a line ending, tests in this script that worked on files with CRLF line endings using "grep" to extract matching lines may lose the CR at the end of lines that match, causing the actual output not to match the expected output. * ml/cygwin-updates (2013-07-21) 4 commits (merged to 'next' on 2013-07-22 at e9c9872) + cygwin: stop forcing core.filemode=false + Cygwin 1.7 supports mmap + Cygwin 1.7 has thread-safe pread + Cygwin 1.7 needs compat/regex The tip one does _not_ revert c869753e (Force core.filemode to false on Cygwin., 2006-12-30) on purpose, so that people can still retain the old behaviour if they wanted to. * rh/template-updates (2013-07-15) 3 commits (merged to 'next' on 2013-07-22 at 53dffdd) + templates: spell ASCII in uppercase in pre-commit hook + templates: Reformat pre-commit hook's message + templates: Use heredoc in pre-commit hook This is an earlier part of a 6 patch series, with log message corrected. * rj/sparse (2013-07-21) 1 commit (merged to 'next' on 2013-07-22 at 24efece) + Revert "compat/unsetenv.c: Fix a sparse warning" * sb/misc-fixes (2013-07-15) 3 commits (merged to 'next' on 2013-07-21 at 880b08c) + diff.c: Do not initialize a variable, which gets reassigned anyway. + commit: Fix a memory leak in determine_author_info + daemon.c:handle: Remove unneeded check for null pointer. Assorted code cleanups and a minor fix. * sb/traverse-trees-bitmask-variable-name (2013-07-19) 1 commit (merged to 'next' on 2013-07-22 at be3227c) + traverse_trees(): clarify return value of the callback * tr/line-log (2013-07-23) 1 commit (merged to 'next' on 20
