{"thread":{"id":"32101","subject":"What's cooking in git.git (Nov 2012, #03; Tue, 13)","startedAt":"2012-11-13T17:52:06Z","lastAt":"2012-11-17T07:11:24Z","messageCount":18,"participants":["Jeff King","Junio C Hamano","Torsten Bögershausen","Pyeron, Jason J CTR (US)","Mark Levedahl","Ramsay Jones"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203122","messageId":"20121113175205.GA26960@sigill.intra.peff.net","threadId":"32101","inReplyTo":null,"subject":"What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-13T17:52:06Z","receivedAt":"2012-11-13T17:52:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"What's cooking in git.git (Nov 2012, #03; Tue, 13)\n--------------------------------------------------\n\nHere are the topics that have been cooking.  Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.\n\nThis is my final \"what's cooking\" as interim maintainer. I didn't\ngraduate anything to master, but I updated my plans for each topic to\ngive Junio an idea of where I was.\n\nYou can find the changes described here in the integration branches of\nmy repository at:\n\n  git://github.com/peff/git.git\n\nUntil Junio returns, kernel.org and the other \"usual\" places will not be\nupdated.\n\n--------------------------------------------------\n[New Topics]\n\n* jk/maint-gitweb-xss (2012-11-12) 1 commit\n - gitweb: escape html in rss title\n\n Fixes an XSS vulnerability in gitweb.\n\n Will merge to 'next'.\n\n\n* jk/send-email-sender-prompt (2012-11-13) 6 commits\n - send-email: do not prompt for explicit repo ident\n - Git.pm: teach \"ident\" to query explicitness\n - var: provide explicit/implicit ident information\n - var: accept multiple variables on the command line\n - ident: keep separate \"explicit\" flags for author and committer\n - ident: make user_ident_explicitly_given private\n\n Avoid annoying sender prompt in git-send-email, but only when it is\n safe to do so.\n\n Needs review.\n\n\n* mg/replace-resolve-delete (2012-11-13) 1 commit\n - replace: parse revision argument for -d\n\n Be more user friendly to people using \"git replace -d\".\n\n Will merge to 'next'.\n\n\n* ml/cygwin-mingw-headers (2012-11-12) 1 commit\n - Update cygwin.c for new mingw-64 win32 api headers\n\n Make git work on newer cygwin.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* rc/maint-complete-git-p4 (2012-09-24) 1 commit\n  (merged to 'next' on 2012-10-29 at af52cef)\n + Teach git-completion about git p4\n\n Comment from Pete will need to be addressed in a follow-up patch.\n\n\n* as/test-tweaks (2012-09-20) 7 commits\n - tests: paint unexpectedly fixed known breakages in bold red\n - tests: test the test framework more thoroughly\n - [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up\n - tests: refactor mechanics of testing in a sub test-lib\n - tests: paint skipped tests in bold blue\n - tests: test number comes first in 'not ok $count - $message'\n - tests: paint known breakages in bold yellow\n\n Various minor tweaks to the test framework to paint its output\n lines in colors that match what they mean better.\n\n Has the \"is this really blue?\" issue Peff raised resolved???\n\n\n* jc/maint-name-rev (2012-09-17) 7 commits\n - describe --contains: use \"name-rev --algorithm=weight\"\n - name-rev --algorithm=weight: tests and documentation\n - name-rev --algorithm=weight: cache the computed weight in notes\n - name-rev --algorithm=weight: trivial optimization\n - name-rev: --algorithm option\n - name_rev: clarify the logic to assign a new tip-name to a commit\n - name-rev: lose unnecessary typedef\n\n \"git name-rev\" names the given revision based on a ref that can be\n reached in the smallest number of steps from the rev, but that is\n not useful when the caller wants to know which tag is the oldest one\n that contains the rev.  This teaches a new mode to the command that\n uses the oldest ref among those which contain the rev.\n\n I am not sure if this is worth it; for one thing, even with the help\n from notes-cache, it seems to make the \"describe --contains\" even\n slower. Also the command will be unusably slow for a user who does\n not have a write access (hence unable to create or update the\n notes-cache).\n\n Stalled mostly due to lack of responses.\n\n\n* jc/xprm-generation (2012-09-14) 1 commit\n - test-generation: compute generation numbers and clock skews\n\n A toy to analyze how bad the clock skews are in histories of real\n world projects.\n\n Stalled mostly due to lack of responses.\n\n\n* jc/blame-no-follow (2012-09-21) 2 commits\n - blame: pay attention to --no-follow\n - diff: accept --no-follow option\n\n Teaches \"--no-follow\" option to \"git blame\" to disable its\n whole-file rename detection.\n\n Stalled mostly due to lack of responses.\n\n\n* jc/doc-default-format (2012-10-07) 2 commits\n - [SQAUSH] allow \"cd Doc* && make DEFAULT_DOC_TARGET=...\"\n - Allow generating a non-default set of documentation\n\n Need to address the installation half if this is to be any useful.\n\n\n* mk/maint-graph-infinity-loop (2012-09-25) 1 commit\n - graph.c: infinite loop in git whatchanged --graph -m\n\n The --graph code fell into infinite loop when asked to do what the\n code did not expect ;-)\n\n Anybody who worked on \"--graph\" wants to comment?\n Stalled mostly due to lack of responses.\n\n\n* jc/add-delete-default (2012-08-13) 1 commit\n - git add: notice removal of tracked paths by default\n\n \"git add dir/\" updated modified files and added new files, but does\n not notice removed files, which may be \"Huh?\" to some users.  They\n can of course use \"git add -A dir/\", but why should they?\n\n Resurrected from graveyard, as I thought it was a worthwhile thing\n to do in the longer term.\n\n Waiting for comments.\n\n\n* mb/remote-default-nn-origin (2012-07-11) 6 commits\n - Teach get_default_remote to respect remote.default.\n - Test that plain \"git fetch\" uses remote.default when on a detached HEAD.\n - Teach clone to set remote.default.\n - Teach \"git remote\" about remote.default.\n - Teach remote.c about the remote.default configuration setting.\n - Rename remote.c's default_remote_name static variables.\n\n When the user does not specify what remote to interact with, we\n often attempt to use 'origin'.  This can now be customized via a\n configuration variable.\n\n Expecting a re-roll.\n\n \"The first remote becomes the default\" bit is better done as a\n separate step.\n\n\n* mh/ceiling (2012-10-29) 8 commits\n - string_list_longest_prefix(): remove function\n - setup_git_directory_gently_1(): resolve symlinks in ceiling paths\n - longest_ancestor_length(): require prefix list entries to be normalized\n - longest_ancestor_length(): take a string_list argument for prefixes\n - longest_ancestor_length(): use string_list_split()\n - Introduce new function real_path_if_valid()\n - real_path_internal(): add comment explaining use of cwd\n - Introduce new static function real_path_internal()\n\n Elements of GIT_CEILING_DIRECTORIES list may not match the real\n pathname we obtain from getcwd(), leading the GIT_DIR discovery\n logic to escape the ceilings the user thought to have specified.\n\n--------------------------------------------------\n[Cooking]\n\n* mo/cvs-server-updates (2012-10-16) 10 commits\n - cvsserver Documentation: new cvs ... -r support\n - cvsserver: add t9402 to test branch and tag refs\n - cvsserver: support -r and sticky tags for most operations\n - cvsserver: Add version awareness to argsfromdir\n - cvsserver: generalize getmeta() to recognize commit refs\n - cvsserver: implement req_Sticky and related utilities\n - cvsserver: add misc commit lookup, file meta data, and file listing functions\n - cvsserver: define a tag name character escape mechanism\n - cvsserver: cleanup extra slashes in filename arguments\n - cvsserver: factor out git-log parsing logic\n\n Needs review by folks interested in cvsserver.\n\n\n* ta/doc-cleanup (2012-10-25) 6 commits\n  (merged to 'next' on 2012-11-13 at e11fafd)\n + Documentation: build html for all files in technical and howto\n + Documentation/howto: convert plain text files to asciidoc\n + Documentation/technical: convert plain text files to asciidoc\n + Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt\n + Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1\n + Split over-long synopsis in git-fetch-pack.txt into several lines\n\n Will merge to 'master' in the sixth batch.\n\n\n* lt/diff-stat-show-0-lines (2012-10-17) 1 commit\n - Fix \"git diff --stat\" for interesting - but empty - file changes\n\n We failed to mention a file without any content change but whose\n permission bit was modified, or (worse yet) a new file without any\n content in the \"git diff --stat\" output.\n\n Needs some test updates.\n\n\n* jc/prettier-pretty-note (2012-10-26) 11 commits\n  (merged to 'next' on 2012-11-04 at 40e3e48)\n + Doc User-Manual: Patch cover letter, three dashes, and --notes\n + Doc format-patch: clarify --notes use case\n + Doc notes: Include the format-patch --notes option\n + Doc SubmittingPatches: Mention --notes option after \"cover letter\"\n + Documentation: decribe format-patch --notes\n + format-patch --notes: show notes after three-dashes\n + format-patch: append --signature after notes\n + pretty_print_commit(): do not append notes message\n + pretty: prepare notes message at a centralized place\n + format_note(): simplify API\n + pretty: remove reencode_commit_message()\n\n Now that Philip has submitted some documentation updates, this is\n looking more ready.\n\n Will merge to 'master' in the fifth batch.\n\n\n* jc/same-encoding (2012-11-04) 1 commit\n  (merged to 'next' on 2012-11-04 at 54991f2)\n + reencode_string(): introduce and use same_encoding()\n\n Various codepaths checked if two encoding names are the same using\n ad-hoc code and some of them ended up asking iconv() to convert\n between \"utf8\" and \"UTF-8\".  The former is not a valid way to spell\n the encoding name, but often people use it by mistake, and we\n equated them in some but not all codepaths. Introduce a new helper\n function to make these codepaths consistent.\n\n Will merge to 'master' in the fifth batch.\n\n\n* cr/cvsimport-local-zone (2012-11-04) 2 commits\n  (merged to 'next' on 2012-11-04 at 292f0b4)\n + cvsimport: work around perl tzset issue\n + git-cvsimport: allow author-specific timezones\n\n Allows \"cvsimport\" to read per-author timezone from the author info\n file.\n\n Will merge to 'master' in the fifth batch.\n\n\n* fc/zsh-completion (2012-10-29) 3 commits\n - completion: add new zsh completion\n - completion: add new __gitcompadd helper\n - completion: get rid of empty COMPREPLY assignments\n\n There were some comments on this, but I wasn't clear on the outcome.\n\n Need to take a closer look.\n\n\n* jc/apply-trailing-blank-removal (2012-10-12) 1 commit\n - apply.c:update_pre_post_images(): the preimage can be truncated\n\n Fix to update_pre_post_images() that did not take into account the\n possibility that whitespace fix could shrink the preimage and\n change the number of lines in it.\n\n Extra set of eyeballs appreciated.\n\n\n* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits\n - config: exit on error accessing any config file\n - doc: advertise GIT_CONFIG_NOSYSTEM\n - config: treat user and xdg config permission problems as errors\n - config, gitignore: failure to access with ENOTDIR is ok\n\n An RFC to deal with a situation where .config/git is a file and we\n notice .config/git/config is not readable due to ENOTDIR, not\n ENOENT; I think a bit more refactored approach to consistently\n address permission errors across config, exclude and attrs is\n desirable.  Don't we also need a check for an opposite situation\n where we open .config/git/config or .gitattributes for reading but\n they turn out to be directories?\n\n\n* as/check-ignore (2012-11-08) 14 commits\n - t0007: fix tests on Windows\n - Documentation/check-ignore: we show the deciding match, not the first\n - Add git-check-ignore sub-command\n - dir.c: provide free_directory() for reclaiming dir_struct memory\n - pathspec.c: move reusable code from builtin/add.c\n - dir.c: refactor treat_gitlinks()\n - dir.c: keep track of where patterns came from\n - dir.c: refactor is_path_excluded()\n - dir.c: refactor is_excluded()\n - dir.c: refactor is_excluded_from_list()\n - dir.c: rename excluded() to is_excluded()\n - dir.c: rename excluded_from_list() to is_excluded_from_list()\n - dir.c: rename path_excluded() to is_path_excluded()\n - dir.c: rename cryptic 'which' variable to more consistent name\n\n Duy helped to reroll this.\n\n Expecting a re-roll.\n\n\n* so/prompt-command (2012-10-17) 4 commits\n  (merged to 'next' on 2012-10-25 at 79565a1)\n + coloured git-prompt: paint detached HEAD marker in red\n + Fix up colored git-prompt\n + show color hints based on state of the git tree\n + Allow __git_ps1 to be used in PROMPT_COMMAND\n\n Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,\n instead of being used for command substitution in $PS1, to embed\n color escape sequences in its output.\n\n Will cook in 'next'.\n\n\n* aw/rebase-am-failure-detection (2012-10-11) 1 commit\n - rebase: Handle cases where format-patch fails\n\n I am unhappy a bit about the possible performance implications of\n having to store the output in a temporary file only for a rare case\n of format-patch aborting.\n\n\n* nd/wildmatch (2012-10-15) 13 commits\n  (merged to 'next' on 2012-10-25 at 510e8df)\n + Support \"**\" wildcard in .gitignore and .gitattributes\n + wildmatch: make /**/ match zero or more directories\n + wildmatch: adjust \"**\" behavior\n + wildmatch: fix case-insensitive matching\n + wildmatch: remove static variable force_lower_case\n + wildmatch: make wildmatch's return value compatible with fnmatch\n + t3070: disable unreliable fnmatch tests\n + Integrate wildmatch to git\n + wildmatch: follow Git's coding convention\n + wildmatch: remove unnecessary functions\n + Import wildmatch from rsync\n + ctype: support iscntrl, ispunct, isxdigit and isprint\n + ctype: make sane_ctype[] const array\n\n Allows pathname patterns in .gitignore and .gitattributes files\n with double-asterisks \"foo/**/bar\" to match any number of directory\n hierarchies.\n\n I suspect that this needs to be plugged to pathspec matching code;\n otherwise \"git log -- 'Docum*/**/*.txt'\" would not show the log for\n commits that touch Documentation/git.txt, which would be confusing\n to the users.\n\n Will cook in 'next'.\n\n\n* jk/lua-hackery (2012-10-07) 6 commits\n - pretty: fix up one-off format_commit_message calls\n - Minimum compilation fixup\n - Makefile: make \"lua\" a bit more configurable\n - add a \"lua\" pretty format\n - add basic lua infrastructure\n - pretty: make some commit-parsing helpers more public\n\n Interesting exercise. When we do this for real, we probably would want\n to wrap a commit to make it more like an \"object\" with methods like\n \"parents\", etc.\n\n\n* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits\n . pretty: support %>> that steal trailing spaces\n . pretty: support truncating in %>, %< and %><\n . pretty: support padding placeholders, %< %> and %><\n . pretty: two phase conversion for non utf-8 commits\n . utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences\n . utf8.c: move display_mode_esc_sequence_len() for use by other functions\n . pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)\n . pretty: split parsing %C into a separate function\n . pretty: share code between format_decoration and show_decorations\n\n This causes warnings with -Wuninitialized, so I've ejected it from pu\n for the time being.\n\n\n* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit\n  (merged to 'next' on 2012-11-04 at eda85ef)\n + get_fetch_map(): tighten checks on dest refs\n\n This was split out from discarded jc/maint-push-refs-all topic.\n\n Will merge to 'master' in the fifth batch.\n\n\n* jh/symbolic-ref-d (2012-10-21) 1 commit\n  (merged to 'next' on 2012-11-04 at b0762f5)\n + git symbolic-ref --delete $symref\n\n Add \"symbolic-ref -d SYM\" to delete a symbolic ref SYM.\n\n It is already possible to remove a symbolic ref with \"update-ref -d\n --no-deref\", but it may be a good addition for completeness.\n\n Will merge to 'master' in the fifth batch.\n\n\n* jh/update-ref-d-through-symref (2012-10-21) 2 commits\n - Fix failure to delete a packed ref through a symref\n - t1400-update-ref: Add test verifying bug with symrefs in delete_ref()\n\n \"update-ref -d --deref SYM\" to delete a ref through a symbolic ref\n that points to it did not remove it correctly.\n\n Need to check reviews, but is probably ready for 'next'.\n\n\n* jk/config-ignore-duplicates (2012-10-29) 9 commits\n  (merged to 'next' on 2012-10-29 at 67fa0a2)\n + builtin/config.c: Fix a sparse warning\n  (merged to 'next' on 2012-10-25 at 233df08)\n + git-config: use git_config_with_options\n + git-config: do not complain about duplicate entries\n + git-config: collect values instead of immediately printing\n + git-config: fix regexp memory leaks on error conditions\n + git-config: remove memory leak of key regexp\n + t1300: test \"git config --get-all\" more thoroughly\n + t1300: remove redundant test\n + t1300: style updates\n\n Drop duplicate detection from git-config; this lets it\n better match the internal config callbacks, which clears up\n some corner cases with includes.\n\n Will merge to 'master' in the sixth batch.\n\n\n* ph/submodule-sync-recursive (2012-10-29) 2 commits\n  (merged to 'next' on 2012-11-04 at a000f78)\n + Add tests for submodule sync --recursive\n + Teach --recursive to submodule sync\n\n Adds \"--recursive\" option to submodule sync.\n\n Will merge to 'master' in the fifth batch.\n\n\n* fc/completion-test-simplification (2012-10-29) 2 commits\n - completion: simplify __gitcomp test helper\n - completion: refactor __gitcomp related tests\n\n Clean up completion tests.\n\n There were some comments on the list.\n\n Expecting a re-roll.\n\n\n* fc/remote-testgit-feature-done (2012-10-29) 1 commit\n - remote-testgit: properly check for errors\n\n Needs review.\n\n\n* jk/maint-diff-grep-textconv (2012-10-28) 1 commit\n  (merged to 'next' on 2012-11-04 at 790337b)\n + diff_grep: use textconv buffers for add/deleted files\n (this branch is used by jk/pickaxe-textconv.)\n\n Fixes inconsistent use of textconv with \"git log -G\".\n\n Will merge to 'master' in the fifth batch.\n\n\n* jk/pickaxe-textconv (2012-10-28) 2 commits\n - pickaxe: use textconv for -S counting\n - pickaxe: hoist empty needle check\n (this branch uses jk/maint-diff-grep-textconv.)\n\n Use textconv filters when searching with \"log -S\".\n\n Waiting for a sanity check and review from Junio.\n\n\n* as/maint-doc-fix-no-post-rewrite (2012-11-02) 1 commit\n  (merged to 'next' on 2012-11-09 at 117a91e)\n + commit: fixup misplacement of --no-post-rewrite description\n\n Will merge to 'master' in the fifth batch.\n\n\n* fc/remote-bzr (2012-11-08) 5 commits\n - remote-bzr: update working tree\n - remote-bzr: add support for remote repositories\n - remote-bzr: add support for pushing\n - remote-bzr: add simple tests\n - Add new remote-bzr transport helper\n\n New remote helper for bzr.\n\n Will merge to 'next'.\n\n\n* fc/remote-hg (2012-11-12) 20 commits\n - remote-hg: avoid bad refs\n - remote-hg: try the 'tip' if no checkout present\n - remote-hg: fix compatibility with older versions of hg\n - remote-hg: add missing config for basic tests\n - remote-hg: the author email can be null\n - remote-hg: add option to not track branches\n - remote-hg: add extra author test\n - remote-hg: add tests to compare with hg-git\n - remote-hg: add bidirectional tests\n - test-lib: avoid full path to store test results\n - remote-hg: add basic tests\n - remote-hg: fake bookmark when there's none\n - remote-hg: add compat for hg-git author fixes\n - remote-hg: add support for hg-git compat mode\n - remote-hg: match hg merge behavior\n - remote-hg: make sure the encoding is correct\n - remote-hg: add support to push URLs\n - remote-hg: add support for remote pushing\n - remote-hg: add support for pushing\n - Add new remote-hg transport helper\n\n New remote helper for hg.\n\n Will merge to 'next'.\n\n\n* jk/maint-http-half-auth-fetch (2012-10-31) 2 commits\n  (merged to 'next' on 2012-11-09 at af69926)\n + remote-curl: retry failed requests for auth even with gzip\n + remote-curl: hoist gzip buffer size to top of post_rpc\n\n Fixes fetch from servers that ask for auth only during the actual\n packing phase. This is not really a recommended configuration, but it\n cleans up the code at the same time.\n\n Will merge to 'master' in the sixth batch.\n\n\n* js/hp-nonstop (2012-10-30) 1 commit\n  (merged to 'next' on 2012-11-09 at fe58205)\n + fix 'make test' for HP NonStop\n\n Will merge to 'master' in the fifth batch.\n\n\n* kb/preload-index-more (2012-11-02) 1 commit\n  (merged to 'next' on 2012-11-09 at a750ebd)\n + update-index/diff-index: use core.preloadindex to improve performance\n\n Use preloadindex in more places, which has a nice speedup on systems\n with slow stat calls (and even on Linux).\n\n Will merge to 'master' in the sixth batch.\n\n\n* mh/notes-string-list (2012-11-08) 5 commits\n  (merged to 'next' on 2012-11-09 at 7a4c58c)\n + string_list_add_refs_from_colon_sep(): use string_list_split()\n + notes: fix handling of colon-separated values\n + combine_notes_cat_sort_uniq(): sort and dedup lines all at once\n + Initialize sort_uniq_list using named constant\n + string_list: add a function string_list_remove_empty_items()\n\n Improve the asymptotic performance of the cat_sort_uniq notes merge\n strategy.\n\n Will merge to 'master' in the fifth batch.\n\n\n* mh/strbuf-split (2012-11-04) 4 commits\n  (merged to 'next' on 2012-11-09 at fa984b1)\n + strbuf_split*(): document functions\n + strbuf_split*(): rename \"delim\" parameter to \"terminator\"\n + strbuf_split_buf(): simplify iteration\n + strbuf_split_buf(): use ALLOC_GROW()\n\n Cleanups and documentation for strbuf_split.\n\n Will merge to 'master' in the fifth batch.\n\n\n* mm/maint-doc-commit-edit (2012-11-02) 1 commit\n  (merged to 'next' on 2012-11-09 at 8dab7f5)\n + Document 'git commit --no-edit' explicitly\n\n Will merge to 'master' in the fifth batch.\n\n\n* cr/push-force-tag-update (2012-11-12) 5 commits\n - push: update remote tags only with force\n - push: flag updates that require force\n - push: flag updates\n - push: add advice for rejected tag reference\n - push: return reject reasons via a mask\n\n Require \"-f\" for push to update a tag, even if it is a fast-forward.\n\n Needs review.\n\n I'm undecided yet on whether the goal is the right thing to do, but it\n does prevent some potential mistakes. I haven't looked closely at the\n implementation itself; review from interested parties would be helpful.\n\n\n* fc/fast-export-fixes (2012-11-08) 14 commits\n - fast-export: don't handle uninteresting refs\n - fast-export: make sure updated refs get updated\n - fast-export: fix comparison in tests\n - fast-export: trivial cleanup\n - remote-testgit: make clear the 'done' feature\n - remote-testgit: report success after an import\n - remote-testgit: exercise more features\n - remote-testgit: cleanup tests\n - remote-testgit: remove irrelevant test\n - remote-testgit: get rid of non-local functionality\n - Add new simplified git-remote-testgit\n - Rename git-remote-testgit to git-remote-testpy\n - remote-testgit: fix direction of marks\n - fast-export: avoid importing blob marks\n\n Improvements to fix fast-export bugs, including how refs pointing to\n already-seen commits are handled. An earlier 4-commit version of this\n series looked good to me, but this much-expanded version has not seen\n any comments.\n\n Looks like it has been re-rolled, but I haven't checked it out yet.\n\n Needs review.\n\n\n* mg/maint-pull-suggest-upstream-to (2012-11-08) 1 commit\n  (merged to 'next' on 2012-11-13 at bd74252)\n + push/pull: adjust missing upstream help text to changed interface\n\n Follow-on to the new \"--set-upstream-to\" topic from v1.8.0 to avoid\n suggesting the deprecated \"--set-upstream\".\n\n Will merge to 'master' in the fifth batch.\n\n\n* mh/alt-odb-string-list-cleanup (2012-11-08) 2 commits\n  (merged to 'next' on 2012-11-13 at 2bf41d9)\n + link_alt_odb_entries(): take (char *, len) rather than two pointers\n + link_alt_odb_entries(): use string_list_split_in_place()\n\n Cleanups in the alternates code. Fixes a potential bug and makes the\n code much cleaner.\n\n Will merge to 'master' in the sixth batch.\n\n\n* pf/editor-ignore-sigint (2012-11-11) 5 commits\n - launch_editor: propagate SIGINT from editor to git\n - run-command: do not warn about child death by SIGINT\n - run-command: drop silent_exec_failure arg from wait_or_whine\n - launch_editor: ignore SIGINT while the editor has control\n - launch_editor: refactor to use start/finish_command\n\n Avoid confusing cases where the user hits Ctrl-C while in the editor\n session, not realizing git will receive the signal. Since most editors\n will take over the terminal and will block SIGINT, this is not likely\n to confuse anyone.\n\n Some people raised issues with emacsclient, which are addressed by this\n re-roll. It should probably also handle SIGQUIT, and there were a\n handful of other review comments.\n\n Expecting a re-roll.\n\n\n* pp/gitweb-config-underscore (2012-11-08) 1 commit\n - gitweb: make remote_heads config setting work\n\n The key \"gitweb.remote_heads\" is not legal git config; this maps it to\n \"gitweb.remoteheads\".\n\n Junio raised a good point about the implementation for three-level\n variables.\n\n Expecting a re-roll.\n\n\n* pw/maint-p4-rcs-expansion-newline (2012-11-08) 1 commit\n  (merged to 'next' on 2012-11-13 at e90cc7c)\n + git p4: RCS expansion should not span newlines\n\n I do not have p4 to play with, but looks obviously correct to me.\n\n Will merge to 'master' in the sixth batch.\n\n\n* rh/maint-gitweb-highlight-ext (2012-11-08) 1 commit\n  (merged to 'next' on 2012-11-13 at c57d856)\n + gitweb.perl: fix %highlight_ext mappings\n\n Fixes a clever misuse of perl's list interpretation.\n\n Will merge to 'master' in the sixth batch.\n\n\n* rr/submodule-diff-config (2012-11-08) 3 commits\n - submodule: display summary header in bold\n - diff: introduce diff.submodule configuration variable\n - Documentation: move diff.wordRegex from config.txt to diff-config.txt\n\n Lets \"git diff --submodule=log\" become the default via configuration.\n\n Almost there. Looks like a new version has been posted, but I haven't\n picked it up yet.\n\n Needs review.\n"},{"id":"203139","messageId":"7vbof1e0hq.fsf@alter.siamese.dyndns.org","threadId":"32101","inReplyTo":"20121113175205.GA26960@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-13T20:01:05Z","receivedAt":"2012-11-13T20:01:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> This is my final \"what's cooking\" as interim maintainer. I didn't\n> graduate anything to master, but I updated my plans for each topic to\n> give Junio an idea of where I was.\n\nAfter exploding the first-parent history between your master..pu\ninto component topics and recreating one new merge-fix for\nnd/wildmatch topic, I think I now know how to rebuild your\nintegration branches.\n\nI still haven't caught up with the past discussions (and still am\nslightly jetlagged), but I think I can take it over from here with\nhelp from contributors.\n\nThanks.\n"},{"id":"203145","messageId":"50A2B14C.9040608@web.de","threadId":"32101","inReplyTo":"20121113175205.GA26960@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-11-13T20:45:00Z","receivedAt":"2012-11-13T20:45:00Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"> * ml/cygwin-mingw-headers (2012-11-12) 1 commit\n>  - Update cygwin.c for new mingw-64 win32 api headers\n> \n>  Make git work on newer cygwin.\n> \n>  Will merge to 'next'.\n\n(Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)\n(And thanks for maintaining git)\n\nIs everybody using cygwin happy with this?\n\nI managed to compile on a fresh installed cygwin,\nbut failed to compile under 1.7.7, see below.\nIs there a way we can achieve to compile git both under \"old\" and \"new\" cygwin 1.7 ?\nOr is this not worth the effort?\n/Torsten\n\n\n\n    CC compat/cygwin.o\nIn file included from compat/../git-compat-util.h:90,\n                 from compat/cygwin.c:9:\n/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: warning: #warning \"fd_set and associated macros have been defined in sys/types.      This may cause runtime problems with W32 sockets\"\nIn file included from /usr/include/sys/socket.h:16,\n                 from compat/../git-compat-util.h:131,\n                 from compat/cygwin.c:9:\n/usr/include/cygwin/socket.h:29: error: redefinition of `struct sockaddr'\n/usr/include/cygwin/socket.h:41: error: redefinition of `struct sockaddr_storage'\nIn file included from /usr/include/sys/socket.h:16,\n                 from compat/../git-compat-util.h:131,\n                 from compat/cygwin.c:9:\n/usr/include/cygwin/socket.h:59: error: redefinition of `struct linger'\nIn file included from compat/../git-compat-util.h:131,\n                 from compat/cygwin.c:9:\n/usr/include/sys/socket.h:30: error: conflicting types for 'accept'\n/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: error: previous declaration of 'accept' was here\n"},{"id":"203146","messageId":"871B6C10EBEFE342A772D1159D13208537AA4518@umechphj.easf.csd.disa.mil","threadId":"32101","inReplyTo":"50A2B14C.9040608@web.de","subject":"RE: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-13T20:48:23Z","receivedAt":"2012-11-13T20:48:23Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Torsten Bögershausen\n> Sent: Tuesday, November 13, 2012 3:45 PM\n> \n> > * ml/cygwin-mingw-headers (2012-11-12) 1 commit\n> >  - Update cygwin.c for new mingw-64 win32 api headers\n> >\n> >  Make git work on newer cygwin.\n> >\n> >  Will merge to 'next'.\n> \n> (Sorry for late answer, I managed to test the original patch minutes\n> before Peff merged it to pu)\n> (And thanks for maintaining git)\n> \n> Is everybody using cygwin happy with this?\n> \n> I managed to compile on a fresh installed cygwin,\n> but failed to compile under 1.7.7, see below.\n> Is there a way we can achieve to compile git both under \"old\" and \"new\"\n> cygwin 1.7 ?\n> Or is this not worth the effort?\n\nOnly supporting the new cygwin would make sense. You have to work hard at using older cygwin environments. I will give it a spin later today or tomorrow.\n\n-Jason \n"},{"id":"203155","messageId":"7vobj1cdrb.fsf@alter.siamese.dyndns.org","threadId":"32101","inReplyTo":"20121113175205.GA26960@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-13T22:57:28Z","receivedAt":"2012-11-13T22:57:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> What's cooking in git.git (Nov 2012, #03; Tue, 13)\n> --------------------------------------------------\n>\n> Here are the topics that have been cooking.  Commits prefixed with\n> '-' are only in 'pu' (proposed updates) while commits prefixed with\n> '+' are in 'next'.\n>\n> This is my final \"what's cooking\" as interim maintainer. I didn't\n> graduate anything to master, but I updated my plans for each topic to\n> give Junio an idea of where I was.\n>\n> You can find the changes described here in the integration branches of\n> my repository at:\n>\n>   git://github.com/peff/git.git\n>\n> Until Junio returns, kernel.org and the other \"usual\" places will not be\n> updated.\n\nAnd now the \"usual places\" have been updated with the same tips of\nintegration branches (the broken-out https://github.com/gitster/git\nrepository, too).\n"},{"id":"203166","messageId":"50A2F17D.4010907@gmail.com","threadId":"32101","inReplyTo":"50A2B14C.9040608@web.de","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2012-11-14T01:18:53Z","receivedAt":"2012-11-14T01:18:53Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 11/13/2012 03:45 PM, Torsten Bögershausen wrote:\n>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit\n>>   - Update cygwin.c for new mingw-64 win32 api headers\n>>\n>>   Make git work on newer cygwin.\n>>\n>>   Will merge to 'next'.\n> (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)\n> (And thanks for maintaining git)\n>\n> Is everybody using cygwin happy with this?\n>\n> I managed to compile on a fresh installed cygwin,\n> but failed to compile under 1.7.7, see below.\n> Is there a way we can achieve to compile git both under \"old\" and \"new\" cygwin 1.7 ?\n> Or is this not worth the effort?\n> /Torsten\n>\n>\n>\nI found no version info defined that could be used to automatically \nswitch between the old and current headers. You can always\n\n     make V15_MINGW_HEADERS=1 ...\n\nto force using the old set if you do not wish to update your installation.\n\nMark\n"},{"id":"203209","messageId":"20121114190228.GA3860@sigill.intra.peff.net","threadId":"32101","inReplyTo":"50A2F17D.4010907@gmail.com","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-14T19:02:29Z","receivedAt":"2012-11-14T19:02:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote:\n\n> On 11/13/2012 03:45 PM, Torsten Bögershausen wrote:\n> >>* ml/cygwin-mingw-headers (2012-11-12) 1 commit\n> >>  - Update cygwin.c for new mingw-64 win32 api headers\n> >>\n> >>  Make git work on newer cygwin.\n> >>\n> >>  Will merge to 'next'.\n> >(Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)\n> >(And thanks for maintaining git)\n> >\n> >Is everybody using cygwin happy with this?\n> >\n> >I managed to compile on a fresh installed cygwin,\n> >but failed to compile under 1.7.7, see below.\n> >Is there a way we can achieve to compile git both under \"old\" and \"new\" cygwin 1.7 ?\n> >Or is this not worth the effort?\n> >\n> I found no version info defined that could be used to automatically\n> switch between the old and current headers. You can always\n> \n>     make V15_MINGW_HEADERS=1 ...\n> \n> to force using the old set if you do not wish to update your installation.\n\nShould we keep the code change, then, but not flip the default (i.e.,\nmake people on the newer version opt into it)? I am not clear on how\ncommon the newer include system is. Of course, auto-detecting would be\nthe ideal.\n\n-Peff\n"},{"id":"203223","messageId":"50A40978.2060504@web.de","threadId":"32101","inReplyTo":"20121114190228.GA3860@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-11-14T21:13:28Z","receivedAt":"2012-11-14T21:13:28Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 14.11.12 20:02, Jeff King wrote:\n> On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote:\n> \n>> On 11/13/2012 03:45 PM, Torsten Bögershausen wrote:\n>>>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit\n>>>>  - Update cygwin.c for new mingw-64 win32 api headers\n>>>>\n>>>>  Make git work on newer cygwin.\n>>>>\n>>>>  Will merge to 'next'.\n>>> (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)\n>>> (And thanks for maintaining git)\n>>>\n>>> Is everybody using cygwin happy with this?\n>>>\n>>> I managed to compile on a fresh installed cygwin,\n>>> but failed to compile under 1.7.7, see below.\n>>> Is there a way we can achieve to compile git both under \"old\" and \"new\" cygwin 1.7 ?\n>>> Or is this not worth the effort?\n>>>\n>> I found no version info defined that could be used to automatically\n>> switch between the old and current headers. You can always\n>>\n>>     make V15_MINGW_HEADERS=1 ...\n>>\n>> to force using the old set if you do not wish to update your installation.\n> \n> Should we keep the code change, then, but not flip the default (i.e.,\n> make people on the newer version opt into it)? I am not clear on how\n> common the newer include system is. Of course, auto-detecting would be\n> the ideal.\n> \n> -Peff\nThere are a couple of things which we may want consider:\na) the name V15_MINGW_HEADERS:\n  It indicates that this is true for Version 1.5 (of what?)\n  If I assume Cygwin version 1.5 , then this name is confusing.\n  Even cygwin versions like 1.7.7 use the same (or similar) include files as 1.5\n  A better name could be CYGWIN_USE_MINGW_HEADERS (or the like) and to revert the logic.\n\nb) Autodetection:\n  (Just loud thinking), running \n$grep mingw /usr/include/w32api/winsock2.h\n * This file is part of the mingw-w64 runtime package.\n#include <_mingw_unicode.h>\n\non cygwin 1.7.17 indicates that we can use grep in the Makefile to autodetect the \"mingw headers\"\n\nSomething like this in Makefile:\n+ifeq ($(shell grep mingw /usr/include/w32api/winsock2.h />/dev/null 2>/dev/null && echo y),y)\n+\tCYGWIN_USE_MINGW_HEADERS=YesPlease\n+endif\n\nc) I'm not sure if we want to change cygwin.c or git-compat-util.h for this.\n\nI can prepare a proper patch within the next couple of days\n\n/Torsten\n\n\n\n\n\n\n\n \n"},{"id":"203233","messageId":"20121115001635.GA17370@sigill.intra.peff.net","threadId":"32101","inReplyTo":"50A40978.2060504@web.de","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-15T00:16:35Z","receivedAt":"2012-11-15T00:16:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote:\n\n> >>>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit\n> >>>>  - Update cygwin.c for new mingw-64 win32 api headers\n> >>>>\n> >>>>  Make git work on newer cygwin.\n> >>>>\n> >>>>  Will merge to 'next'.\n\nI'm cc-ing Junio in case he missed the discussion; my original plan had\nbeen to move this topic right to 'next' to get exposure from other\ncygwin people. But it seems we have already got that, and it might need\nre-rolling, so it probably makes sense to hold back until the discussion\nreaches a conclusion.\n\n> There are a couple of things which we may want consider:\n> a) the name V15_MINGW_HEADERS:\n>   It indicates that this is true for Version 1.5 (of what?)\n>   If I assume Cygwin version 1.5 , then this name is confusing.\n>   Even cygwin versions like 1.7.7 use the same (or similar) include files as 1.5\n>   A better name could be CYGWIN_USE_MINGW_HEADERS (or the like) and to revert the logic.\n\nRegardless of flipping the logic, I agree that having CYGWIN in the name\nmakes a lot of sense.\n\n> b) Autodetection:\n>   (Just loud thinking), running \n> $grep mingw /usr/include/w32api/winsock2.h\n>  * This file is part of the mingw-w64 runtime package.\n> #include <_mingw_unicode.h>\n> \n> on cygwin 1.7.17 indicates that we can use grep in the Makefile to\n> autodetect the \"mingw headers\"\n\nHmm. Can we rely on the /usr/include bit, though?\n\nI assume a test-compile would be sufficient, but currently we do not do\nanything more magic than \"uname\" in the Makefile itself to determine\ndefaults.  Maybe it would be better to do the detection in the configure\nscript? And then eventually flip the default in the Makefile once\nsufficient time has passed for most people to want the new format (which\nwould not be necessary for people using autoconf, but would help people\nwho do not).\n\n-Peff\n"},{"id":"203235","messageId":"7v4nkrafbd.fsf@alter.siamese.dyndns.org","threadId":"32101","inReplyTo":"20121115001635.GA17370@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-15T00:19:02Z","receivedAt":"2012-11-15T00:19:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote:\n>\n>> >>>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit\n>> >>>>  - Update cygwin.c for new mingw-64 win32 api headers\n>> >>>>\n>> >>>>  Make git work on newer cygwin.\n>> >>>>\n>> >>>>  Will merge to 'next'.\n>\n> I'm cc-ing Junio in case he missed the discussion; my original plan had\n> been to move this topic right to 'next' to get exposure from other\n> cygwin people. But it seems we have already got that, and it might need\n> re-rolling, so it probably makes sense to hold back until the discussion\n> reaches a conclusion.\n\nThanks for a reminder; that is what I did.\n"},{"id":"203259","messageId":"50A44A73.8020007@gmail.com","threadId":"32101","inReplyTo":"20121115001635.GA17370@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2012-11-15T01:50:43Z","receivedAt":"2012-11-15T01:50:43Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 11/14/2012 07:16 PM, Jeff King wrote:\n> On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote:\n> b) Autodetection:\n>    (Just loud thinking), running\n> $grep mingw /usr/include/w32api/winsock2.h\n>   * This file is part of the mingw-w64 runtime package.\n> #include <_mingw_unicode.h>\n>\n> on cygwin 1.7.17 indicates that we can use grep in the Makefile to\n> autodetect the \"mingw headers\"\n> Hmm. Can we rely on the /usr/include bit, though?\n>\n> I assume a test-compile would be sufficient, but currently we do not do\n> anything more magic than \"uname\" in the Makefile itself to determine\n> defaults.  Maybe it would be better to do the detection in the configure\n> script? And then eventually flip the default in the Makefile once\n> sufficient time has passed for most people to want the new format (which\n> would not be necessary for people using autoconf, but would help people\n> who do not).\n>\n> -Peff\n>\n\nCygwin changed the win32api implementation, and the old is not just no \nlonger supported for the current release series, but virtually \nimpossible to even install (several new packages are now installed, the \nold package is in the \"obsolete\" category, i.e., not available). The \nolder cygwin 1.5 dll + utilities can be installed afresh, so that is why \nI set up to switch based upon dll version - the proposed test(s) and \nconfiguration would be to have git maintain compatibility with an \nunsupported Cygwin configuration. I just don't think this is worth the \nmaintenance burden, but of course I am not the maintainer, just \nexpressing my opinion.\n\nI have no trouble renaming the macro to whatever seems to clarify things.\n\nMark\n"},{"id":"203260","messageId":"20121115015608.GB19131@sigill.intra.peff.net","threadId":"32101","inReplyTo":"50A44A73.8020007@gmail.com","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-15T01:56:08Z","receivedAt":"2012-11-15T01:56:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 14, 2012 at 08:50:43PM -0500, Mark Levedahl wrote:\n\n> Cygwin changed the win32api implementation, and the old is not just\n> no longer supported for the current release series, but virtually\n> impossible to even install (several new packages are now installed,\n> the old package is in the \"obsolete\" category, i.e., not available).\n> The older cygwin 1.5 dll + utilities can be installed afresh, so that\n> is why I set up to switch based upon dll version - the proposed\n> test(s) and configuration would be to have git maintain compatibility\n> with an unsupported Cygwin configuration. I just don't think this is\n> worth the maintenance burden, but of course I am not the maintainer,\n> just expressing my opinion.\n\nOK. I don't have a strong opinion either, as I don't know what's normal\nin the Cygwin world, and that is probably the most important thing to\nfollow for the default. I got the impression that \"normal\" is changing\nto the new way, but Torsten's message made me wonder if were there quite\nyet (if there was some issue with upgrades versus new fresh installs).\n\nBut I have no real cygwin knowledge, so I'll bow out and let you guys\ndiscuss.\n\n-Peff\n"},{"id":"203268","messageId":"50A48391.9090207@web.de","threadId":"32101","inReplyTo":"20121115015608.GB19131@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-11-15T05:54:25Z","receivedAt":"2012-11-15T05:54:25Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 15.11.12 02:56, Jeff King wrote:\n> On Wed, Nov 14, 2012 at 08:50:43PM -0500, Mark Levedahl wrote:\n> \n>> Cygwin changed the win32api implementation, and the old is not just\n>> no longer supported for the current release series, but virtually\n>> impossible to even install (several new packages are now installed,\n>> the old package is in the \"obsolete\" category, i.e., not available).\n>> The older cygwin 1.5 dll + utilities can be installed afresh, so that\n>> is why I set up to switch based upon dll version - the proposed\n>> test(s) and configuration would be to have git maintain compatibility\n>> with an unsupported Cygwin configuration. I just don't think this is\n>> worth the maintenance burden, but of course I am not the maintainer,\n>> just expressing my opinion.\n> \n> OK. I don't have a strong opinion either, as I don't know what's normal\n> in the Cygwin world, and that is probably the most important thing to\n> follow for the default. I got the impression that \"normal\" is changing\n> to the new way, but Torsten's message made me wonder if were there quite\n> yet (if there was some issue with upgrades versus new fresh installs).\n> \n> But I have no real cygwin knowledge, so I'll bow out and let you guys\n> discuss.\n> \n\nMy understanding:\nEither use people cygwin 1.5 or they use cygwin 1.7, and in this case\nthe installation is updated frequently.\n\nPeff or Junio, please go ahead with the patch.\n\nIf it turns out that we want to support cygwin installations like 1.7.7\nwhich could be upgraded, but are not upgraded since they are\n\"production machines we do not dare to touch\" we can still improve\nthe autodetection.\n\nThanks for the responses.\n/Torsten\n"},{"id":"203309","messageId":"50A53CF0.7040809@ramsay1.demon.co.uk","threadId":"32101","inReplyTo":"50A2B14C.9040608@web.de","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2012-11-15T19:05:20Z","receivedAt":"2012-11-15T19:05:20Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Torsten Bögershausen wrote:\n>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit\n>>  - Update cygwin.c for new mingw-64 win32 api headers\n>>\n>>  Make git work on newer cygwin.\n>>\n>>  Will merge to 'next'.\n> \n> (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)\n> (And thanks for maintaining git)\n> \n> Is everybody using cygwin happy with this?\n\nI am still on cygwin 1.5.22 and quite happy that this patch does\nnot (seem) to cause any problems. ;-P\n\n> I managed to compile on a fresh installed cygwin,\n> but failed to compile under 1.7.7, see below.\n> Is there a way we can achieve to compile git both under \"old\" and \"new\" cygwin 1.7 ?\n> Or is this not worth the effort?\n\nDid the cygwin project not bump an api version number somewhere?\n\nATB,\nRamsay Jones\n"},{"id":"203312","messageId":"50A54406.5080309@web.de","threadId":"32101","inReplyTo":"50A53CF0.7040809@ramsay1.demon.co.uk","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-11-15T19:35:34Z","receivedAt":"2012-11-15T19:35:34Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 11/15/2012 08:05 PM, Ramsay Jones wrote:\n> Torsten Bögershausen wrote:\n>>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit\n>>>   - Update cygwin.c for new mingw-64 win32 api headers\n>>>\n>>>   Make git work on newer cygwin.\n>>>\n>>>   Will merge to 'next'.\n>>\n>> (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)\n>> (And thanks for maintaining git)\n>>\n>> Is everybody using cygwin happy with this?\n>\n> I am still on cygwin 1.5.22 and quite happy that this patch does\n> not (seem) to cause any problems. ;-P\n>\n>> I managed to compile on a fresh installed cygwin,\n>> but failed to compile under 1.7.7, see below.\n>> Is there a way we can achieve to compile git both under \"old\" and \"new\" cygwin 1.7 ?\n>> Or is this not worth the effort?\n>\n> Did the cygwin project not bump an api version number somewhere?\n>\n> ATB,\n> Ramsay Jones\nRamsay,\nyou can run uname -r to see the version number.\n\nI myself haven't fully understood all the consequences,\nsomewhere between 1.7.7 and 1.7.17 the include files had been changed.\n\nIf this has consequences for using e.g. winsock2.dll, I want to know \nmyself ;-)\n\n/Torsten\n"},{"id":"203321","messageId":"50A57C12.8080001@gmail.com","threadId":"32101","inReplyTo":"50A54406.5080309@web.de","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2012-11-15T23:34:42Z","receivedAt":"2012-11-15T23:34:42Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 11/15/2012 02:35 PM, Torsten Bögershausen wrote:\n> On 11/15/2012 08:05 PM, Ramsay Jones wrote:\n>>\n>> Did the cygwin project not bump an api version number somewhere?\n>>\n>> ATB,\n>> Ramsay Jones\n> Ramsay,\n> you can run uname -r to see the version number.\n>\n> I myself haven't fully understood all the consequences,\n> somewhere between 1.7.7 and 1.7.17 the include files had been changed.\n>\n> If this has consequences for using e.g. winsock2.dll, I want to know \n> myself ;-)\n>\n> /Torsten\n>\n>\nuname -r gives the version of the dll, not of any particular package, \nand all of the various components are versioned independently. The \nwin32api is spread across several packages, and the recent update \nchanged the names, There is no api number advertised. You could check \nthe names of currently installed packages if you assume those names \nwon't change, but any such method is going to be fragile (and very \nunsupported).\n\nMark\n"},{"id":"203357","messageId":"7vlie1mlcb.fsf@alter.siamese.dyndns.org","threadId":"32101","inReplyTo":"50A48391.9090207@web.de","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-16T18:52:36Z","receivedAt":"2012-11-16T18:52:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n> My understanding:\n> Either use people cygwin 1.5 or they use cygwin 1.7, and in this case\n> the installation is updated frequently.\n>\n> Peff or Junio, please go ahead with the patch.\n>\n> If it turns out that we want to support cygwin installations like 1.7.7\n> which could be upgraded, but are not upgraded since they are\n> \"production machines we do not dare to touch\" we can still improve\n> the autodetection.\n\nOK.  I moved the topic forward but we may still want to rename the\nname of the macro to have CYGWIN somewhere in the name.\n"},{"id":"203395","messageId":"50A7389C.6080003@web.de","threadId":"32101","inReplyTo":"7vlie1mlcb.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-11-17T07:11:24Z","receivedAt":"2012-11-17T07:11:24Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 16.11.12 19:52, Junio C Hamano wrote:\n> Torsten Bögershausen <tboegi@web.de> writes:\n> \n>> My understanding:\n>> Either use people cygwin 1.5 or they use cygwin 1.7, and in this case\n>> the installation is updated frequently.\n>>\n>> Peff or Junio, please go ahead with the patch.\n>>\n>> If it turns out that we want to support cygwin installations like 1.7.7\n>> which could be upgraded, but are not upgraded since they are\n>> \"production machines we do not dare to touch\" we can still improve\n>> the autodetection.\n> \n> OK.  I moved the topic forward but we may still want to rename the\n> name of the macro to have CYGWIN somewhere in the name.\n\nI send a patch some seconds ago.\nI forgot to mention that this should be applied to next\n"}]}