{"thread":{"id":"18843","subject":"What's cooking in git.git (Apr 2009, #02; Sun, 12)","startedAt":"2009-04-13T02:50:34Z","lastAt":"2009-04-16T13:12:04Z","messageCount":6,"participants":["Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"111154","messageId":"7vvdp9w9l1.fsf@gitster.siamese.dyndns.org","threadId":"18843","inReplyTo":null,"subject":"What's cooking in git.git (Apr 2009, #02; Sun, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-13T02:50:34Z","receivedAt":"2009-04-13T02:50:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with '-' are\nonly in 'pu' while commits prefixed with '+' are in 'next'.  The ones\nmarked with '.' do not appear in any of the branches, but I am still\nholding onto them.\n\nThe topics list the commits in reverse chronological order.  The topics\nmeant to be merged to the maintenance series have \"maint-\" in their names.\n\nWe are at 1.6.3-rc0; the tip of 'master' might have some unexpected\nminor regressions, and I'd appreciate people to test and report so that we\ncan keep this cycle short.\n\n----------------------------------------------------------------\n[New Topics]\n\n* mm/add-p-quit (Fri Apr 10 16:57:01 2009 +0200) 1 commit\n - [NEEDS SIGN OFF, DOC, AND REVIEW] git add -p: new \"quit\" command\n   at the prompt.\n\nI think this is Ok for 1.6.3, but some duplicated hunks bothered me.  I\ndid not read the patch really seriously.\n\n* lt/bool-on-off (Thu Apr 9 12:40:39 2009 -0700) 1 commit\n - Allow users to un-configure rename detection\n\nThe commit log message needs to be cleaned up, the patch needs to be\nsigned off, and there probably needs a documentation, but I think\notherwise this is a good idea.\n\n* nd/archive-attribute (Thu Apr 9 17:01:30 2009 +1000) 2 commits\n - archive: do not read .gitattributes in working directory\n - attr: add GIT_ATTR_INDEX \"direction\"\n\nI think this is Ok for 1.6.3 but it needs new tests to protect the new\nfeature from future breakages.\n\n* js/add-edit (Wed Apr 8 23:30:24 2009 +0200) 1 commit\n - git-add: introduce --edit (to edit the diff vs. the index)\n\nI am Ok with the general idea, but the error detection needs to be more\nrobust than merely relying on --recount.\n\n* eb/upload-archive-from-git-shell (Thu Apr 9 21:58:52 2009 +0200) 1 commit\n - git-shell: Add 'git-upload-archive' to allowed commands.\n\nI think this is Ok for 1.6.3.\n\n* jc/shared-literally (Sun Apr 12 17:55:18 2009 -0700) 2 commits\n - Mark t1301 permission test to depend on POSIXPERM\n - t1301-shared-repo: fix forced modes test\n\nJ6t's updates to fix permission tests and make sure they won't run on\nsystems without permission bits on the filesystem.\n\nI think this is Ok for 1.6.3.\n\n* ns/am-to-empty (Fri Apr 10 09:34:42 2009 +0900) 1 commit\n - git-am: teach git-am to apply a patch to an unborn branch\n\nI think this is Ok for 1.6.3.\n\n* bw/short-ref-strict (Sat Apr 11 22:35:18 2009 +0200) 2 commits\n . for-each-ref: refname:short utilize core.warnAmbiguousRefs\n . get_short_ref(): add strict mode\n\nThis is an \"obviously good thing to do\" candidate for 1.6.3 but had\nserious conflicts with other topics I didn't feel like resolving myself;\nas the series is coming from TopGit, I'd ask the submitter to rebase it\nfor me ;-)\n\n* lt/pack-object-memuse (Fri Apr 10 18:15:26 2009 -0700) 2 commits\n - show_object(): push path_name() call further down\n - process_{tree,blob}: show objects without buffering\n\nThis had some conflicts with Christian's bisect topic; I think I resolved\nthem correctly, but double-checking would be nice.\n\n----------------------------------------------------------------\n[Graduated to \"master\"]\n\n* mh/html-path (Sun Apr 5 04:15:16 2009 +0200) 1 commit\n + add --html-path to get the location of installed HTML docs\n\n* lt/reflog-expire (Mon Mar 30 21:34:14 2009 -0700) 2 commits\n + Speed up reflog pruning of unreachable commits\n + Clean up reflog unreachability pruning decision\n\n* bs/maint-1.6.0-tree-walk-prefix (Wed Apr 1 19:34:03 2009 -0700) 2 commits\n + match_tree_entry(): a pathspec only matches at directory\n   boundaries\n + tree_entry_interesting: a pathspec only matches at directory\n   boundary\n\n* ms/http-auth (Wed Apr 1 19:48:24 2009 +0300) 1 commit\n + Allow curl to rewind the read buffers\n\n* js/maint-submodule-checkout (Thu Apr 2 15:30:25 2009 +0200) 1 commit\n + Fix 'git checkout <submodule>' to update the index\n\n* cb/maint-merge-recursive-submodule-fix (Sun Apr 5 02:47:00 2009 +0200) 3 commits\n + simplify output of conflicting merge\n + update cache for conflicting submodule entries\n + add tests for merging with submodules\n\n* fg/remote-prune (Fri Apr 3 11:03:44 2009 +0200) 2 commits\n + git remote update: New option --prune\n + builtin-remote.c: Split out prune_remote as a separate function.\n\nThese should go to 'master' soonish.\n\n* cc/sha1-bsearch (Mon Apr 6 00:48:49 2009 -0700) 3 commits\n + sha1-lookup: fix up the assertion message\n + patch-ids: use the new generic \"sha1_pos\" function to lookup sha1\n + sha1-lookup: add new \"sha1_pos\" function to efficiently lookup\n   sha1\n\n* jc/name-branch-iffy (Sat Mar 21 14:30:21 2009 -0700) 1 commit\n + checkout -: make \"-\" to mean \"previous branch\" everywhere\n\n* cc/bisect-filter (Mon Mar 30 06:59:59 2009 +0200) 19 commits\n + bisect--helper: string output variables together with \"&&\"\n + rev-list: pass \"int flags\" as last argument of \"show_bisect_vars\"\n + t6030: test bisecting with paths\n + bisect: use \"bisect--helper\" and remove \"filter_skipped\" function\n + bisect: implement \"read_bisect_paths\" to read paths in\n   \"$GIT_DIR/BISECT_NAMES\"\n + bisect--helper: implement \"git bisect--helper\"\n + bisect: use the new generic \"sha1_pos\" function to lookup sha1\n + rev-list: call new \"filter_skip\" function\n + Merge branch 'cc/sha1-bsearch' into HEAD\n + patch-ids: use the new generic \"sha1_pos\" function to lookup sha1\n + sha1-lookup: add new \"sha1_pos\" function to efficiently lookup\n   sha1\n + rev-list: pass \"revs\" to \"show_bisect_vars\"\n + rev-list: make \"show_bisect_vars\" non static\n + rev-list: move code to show bisect vars into its own function\n + rev-list: move bisect related code into its own file\n + rev-list: make \"bisect_list\" variable local to \"cmd_rev_list\"\n + refs: add \"for_each_ref_in\" function to refactor \"for_each_*_ref\"\n   functions\n + quote: add \"sq_dequote_to_argv\" to put unwrapped args in an argv\n   array\n + quote: implement \"sq_dequote_many\" to unwrap many args in one\n   string\n\n----------------------------------------------------------------\n[Stalled and may need help and prodding to go forward]\n\n* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit\n - blame.c: start libifying the blame infrastructure\n\nA few minor point remains in this initial one.  I hate to do these minor\nfix-ups myself, but I may end up doing so...\n\n* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit\n - Allow --date=local --date=other-format to work as expected\n\nThe one I posted had a few corner-case bugs that was caught with the test\nsuite; this one has them fixed.  People did not like the UI so it is kept\nout of 'next'\n\n* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit\n - git-merge-file: allow converting the results for the work tree\n\nThis is a feature waiting for a user.\n\nWe did not give scripted Porcelains a way to say \"this temporary file I am\nusing for merging is for this path, so use the core.autocrlf and attributes\nrules for that final path\".  Instead, merge-file simply wrote out the\ndata in the canonical repository representation.\n\nrerere has the same issue, but it is a lot worse.  It reads the three\nfiles (preimage, postimage and thisimage) from the work tree in the work\ntree representation, merges them without converting them to the canonical\nrepresentation first but inserts the conflict markers with the canonical\nrepresentation and writes the resulting mess out.  It needs to be fixed to\nread with convert_to_git(), merge them while they are still in the\ncanonical representation and possibly add conflict markers, and then write\nthe results out after convert_to_working_tree().  It also needs to write\nin binary mode as well.\n\n* db/foreign-scm (Tue Mar 24 23:04:12 2009 -0400) 3 commits\n - Add option for using a foreign VCS\n - Document details of transport function APIs\n - Allow late reporting of fetched hashes\n\n* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits\n - tests: fix \"export var=val\"\n - notes: refuse to edit notes outside refs/notes/\n - t3301: use test_must_fail instead of !\n - t3301: fix confusing quoting in test for valid notes ref\n - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR\n - notes: only clean up message file when editing\n - handle empty notes gracefully\n - git notes show: test empty notes\n - git-notes: fix printing of multi-line notes\n - notes: fix core.notesRef documentation\n - Add an expensive test for git-notes\n - Speed up git notes lookup\n - Add a script to edit/inspect notes\n - Introduce commit notes\n\n* hv/cvsps-tests (Sun Apr 5 01:40:50 2009 -0700) 8 commits\n - t/t9600: remove exit after test_done\n - cvsimport: extend testcase about patchset order to contain\n   branches\n - cvsimport: add test illustrating a bug in cvsps\n + Add a test of \"git cvsimport\"'s handling of tags and branches\n + Add some tests of git-cvsimport's handling of vendor branches\n + Test contents of entire cvsimported \"master\" tree contents\n + Use CVS's -f option if available (ignore user's ~/.cvsrc file)\n + Start a library for cvsimport-related tests\n\nTwo cvsimport test topics were rewound from 'next' and merged into this\none.  I'll keep this in 'pu' so that people can polish their cvsps skilz\nto resolve issues these tests identify.\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* da/difftool (Sat Apr 11 20:41:56 2009 -0700) 16 commits\n - mergetool--lib: simplify API usage by removing more global\n   variables\n - Fix misspelled mergetool.keepBackup\n - difftool/mergetool: refactor commands to use git-mergetool--lib\n - mergetool: use $( ... ) instead of `backticks`\n - bash completion: add git-difftool\n - difftool: add support for a difftool.prompt config variable\n - difftool: add various git-difftool tests\n - difftool: move 'git-difftool' out of contrib\n - difftool/mergetool: add diffuse as merge and diff tool\n - difftool: add a -y shortcut for --no-prompt\n - difftool: use perl built-ins when testing for msys\n - difftool: remove the backup file feature\n - difftool: remove merge options for opendiff, tkdiff, kdiff3 and\n   xxdiff\n - git-mergetool: add new merge tool TortoiseMerge\n - git-mergetool/difftool: make (g)vimdiff workable under Windows\n - doc/merge-config: list ecmerge as a built-in merge tool\n\n* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits\n - builtin-replace: use \"usage_msg_opt\" to give better error messages\n - parse-options: add new function \"usage_msg_opt\"\n - builtin-replace: teach \"git replace\" to actually replace\n - Add new \"git replace\" command\n - environment: add global variable to disable replacement\n - mktag: call \"check_sha1_signature\" with the replacement sha1\n - replace_object: add a test case\n - object: call \"check_sha1_signature\" with the replacement sha1\n - sha1_file: add a \"read_sha1_file_repl\" function\n - replace_object: add mechanism to replace objects found in\n   \"refs/replace/\"\n - refs: add a \"for_each_replace_ref\" function\n\nI suspect an attempt to replace an object that is directly listed on the\ncommand line would not work very well with this series.\n\n----------------------------------------------------------------\n[On Hold]\n\n* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit\n - receive-pack: default receive.denyDeleteCurrent to refuse\n\n* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit\n - Refuse updating the current branch in a non-bare repository via\n   push\n\nThese are for 1.7.0, but the messages when they trigger together may need\nto be rethought.\n"},{"id":"111296","messageId":"alpine.DEB.1.00.0904141943060.10279@pacific.mpi-cbg.de","threadId":"18843","inReplyTo":"7vvdp9w9l1.fsf@gitster.siamese.dyndns.org","subject":"add -e, was Re: What's cooking in git.git (Apr 2009, #02; Sun, 12)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-14T17:48:55Z","receivedAt":"2009-04-14T17:48:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 12 Apr 2009, Junio C Hamano wrote:\n\n> * js/add-edit (Wed Apr 8 23:30:24 2009 +0200) 1 commit\n>  - git-add: introduce --edit (to edit the diff vs. the index)\n> \n> I am Ok with the general idea, but the error detection needs to be more \n> robust than merely relying on --recount.\n\nYou mean something like saving an extra copy of the patch, and checking if \ncommon or removed lines were either removed or kept intact?\n\nThat might turn out to be _very_ tricky.\n\nExample:\n\n@@ <some numbers>\n common line\n+added line\n common line\n-removed line\n common line\n\nNow, edit it, and come up with\n\n@@ <some numbers>\n common line\n+removed line\n common line\n\nIt is obvious what is meant, but is there a clear semantics a _computer_ \ncould understand?  I do not think so.\n\nIf you had some other error checking in mind, please let me hear it.\n\nCiao,\nDscho\n"},{"id":"111300","messageId":"7vhc0r3wpq.fsf@gitster.siamese.dyndns.org","threadId":"18843","inReplyTo":"alpine.DEB.1.00.0904141943060.10279@pacific.mpi-cbg.de","subject":"Re: add -e, was Re: What's cooking in git.git (Apr 2009, #02; Sun, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-14T18:40:33Z","receivedAt":"2009-04-14T18:40:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Sun, 12 Apr 2009, Junio C Hamano wrote:\n>\n>> * js/add-edit (Wed Apr 8 23:30:24 2009 +0200) 1 commit\n>>  - git-add: introduce --edit (to edit the diff vs. the index)\n>> \n>> I am Ok with the general idea, but the error detection needs to be more \n>> robust than merely relying on --recount.\n>\n> You mean something like saving an extra copy of the patch, and checking if \n> common or removed lines were either removed or kept intact?\n\nNo, editing a removed line and changing it to an unchanged line is\nperfectly fine.\n\nI was thinking more about people touching the lines near the hunk boundary\n(e.g. insert a new line at the beginning of the hunk) which would not be\ncompatible without --unidiff-zero hack while applying, and --unidiff-zero\nhack should not be used if we care about the correctness.\n"},{"id":"111313","messageId":"alpine.DEB.1.00.0904142224030.10279@pacific.mpi-cbg.de","threadId":"18843","inReplyTo":"7vhc0r3wpq.fsf@gitster.siamese.dyndns.org","subject":"Re: add -e, was Re: What's cooking in git.git (Apr 2009, #02; Sun, 12)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-14T20:25:55Z","receivedAt":"2009-04-14T20:25:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 14 Apr 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > On Sun, 12 Apr 2009, Junio C Hamano wrote:\n> >\n> >> * js/add-edit (Wed Apr 8 23:30:24 2009 +0200) 1 commit\n> >>  - git-add: introduce --edit (to edit the diff vs. the index)\n> >> \n> >> I am Ok with the general idea, but the error detection needs to be \n> >> more robust than merely relying on --recount.\n> >\n> > You mean something like saving an extra copy of the patch, and \n> > checking if common or removed lines were either removed or kept \n> > intact?\n> \n> No, editing a removed line and changing it to an unchanged line is \n> perfectly fine.\n> \n> I was thinking more about people touching the lines near the hunk \n> boundary (e.g. insert a new line at the beginning of the hunk) which \n> would not be compatible without --unidiff-zero hack while applying, and \n> --unidiff-zero hack should not be used if we care about the correctness.\n\nActually, I am beginning to hate the idea of having this in add -e, but \nwould prefer it to be in apply (\"git apply $PATCH\" could -- and should -- \ncomplain when not being called with --unidiff-zero and encountering a \npatch that should (but does not) have common context lines).\n\nDo you agree?\n\nCiao,\nDscho\n"},{"id":"111330","messageId":"7v7i1m3m1m.fsf@gitster.siamese.dyndns.org","threadId":"18843","inReplyTo":"alpine.DEB.1.00.0904142224030.10279@pacific.mpi-cbg.de","subject":"Re: add -e, was Re: What's cooking in git.git (Apr 2009, #02; Sun, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-14T22:31:01Z","receivedAt":"2009-04-14T22:31:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Actually, I am beginning to hate the idea of having this in add -e, but \n> would prefer it to be in apply (\"git apply $PATCH\" could -- and should -- \n> complain when not being called with --unidiff-zero and encountering a \n> patch that should (but does not) have common context lines).\n\nI think it already complains by rejecting.  The thing is, only \"add -e\"\nknows that the patch being fed to apply is potentially manually corrupt by\nthe end user.\n"},{"id":"111446","messageId":"alpine.DEB.1.00.0904161510080.6798@intel-tinevez-2-302","threadId":"18843","inReplyTo":"7v7i1m3m1m.fsf@gitster.siamese.dyndns.org","subject":"Re: add -e, was Re: What's cooking in git.git (Apr 2009, #02; Sun, 12)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-16T13:12:04Z","receivedAt":"2009-04-16T13:12:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 14 Apr 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > Actually, I am beginning to hate the idea of having this in add -e, \n> > but would prefer it to be in apply (\"git apply $PATCH\" could -- and \n> > should -- complain when not being called with --unidiff-zero and \n> > encountering a patch that should (but does not) have common context \n> > lines).\n> \n> I think it already complains by rejecting.  The thing is, only \"add -e\" \n> knows that the patch being fed to apply is potentially manually corrupt \n> by the end user.\n\nI think that this extra-check for missing context lines is a substantial \namount of work for little use, as the most common mistakes are other \nthings, and _they_ will be hard to catch, as I illustrated.\n\nSo, how about adding a warning before the beginning of the patch instead?\n\nCiao,\nDscho\n"}]}