{"thread":{"id":"20237","subject":"What's cooking in git.git (Jul 2009, #02; Sun, 26)","startedAt":"2009-07-26T08:47:14Z","lastAt":"2009-07-28T08:09:19Z","messageCount":11,"participants":["Junio C Hamano","Jakub Narebski","Johannes Schindelin","Michael Haggerty","Alex Riesen","Paolo Bonzini"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118821","messageId":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","threadId":"20237","inReplyTo":null,"subject":"What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-26T08:47:14Z","receivedAt":"2009-07-26T08:47:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"These topics in 'next' (ones prefixed with '+') and 'pu' (ones prefixed\nwith '.') will not be in 1.6.4 final, and are subject to be rewound once\n1.6.4 final happens.\n\nWe have quite a few solid topics in 'next', so hopefully the next cycle\nwould be shorter than usual.  I'd propose to call it 1.6.5, and then make\nthe one after that 1.7.0, which means that during the 1.6.5 cycle, 'next'\nwill have the two incompatible \"push\" (actually, receive-pack) changes\nhitherto kept on hold in 'pu'.\n\n----------------------------------------------------------------\n[New Topics]\n\n* jk/show-tag (Sat Jul 18 06:14:37 2009 -0400) 2 commits\n + show: add space between multiple items\n + show: suppress extra newline when showing annotated tag\n\nDidn't look bad at all, but is not pressing either.\n\n* sb/parse-options (Tue Jul 7 22:15:41 2009 -0700) 4 commits\n + prune-packed: migrate to parse-options\n + verify-pack: migrate to parse-options\n + verify-tag: migrate to parse-options\n + write-tree: migrate to parse-options\n\n* mk/grep-max-depth (Wed Jul 22 19:52:15 2009 +0200) 1 commit\n + grep: Add --max-depth option.\n\n* jn/gitweb-blame (Sat Jul 25 00:44:10 2009 +0200) 10 commits\n - gitweb: Create links leading to 'blame_incremental' using\n   JavaScript\n - gitweb: Incremental blame (proof of concept)\n - gitweb: Add optional \"time to generate page\" info in footer\n - gitweb: Add -partial_query option to href() subroutine\n - gitweb: Use light/dark for class names also in 'blame' view\n - gitweb: Add author initials in 'blame' view, a la \"git gui blame\"\n - gitweb: Mark commits with no \"previous\" in 'blame' view\n - gitweb: Use \"previous\" header of git-blame -p in 'blame' view\n - gitweb: Mark boundary commits in 'blame' view\n - gitweb: Make .error style generic\n\nStill in flux/rfc.\n\n* ns/init-mkdir (Sat Jul 25 06:59:28 2009 +0900) 1 commit\n + git init: optionally allow a directory argument\n\nDidn't look bad, but is not pressing either.\n\n* jc/apply-epoch-patch (Fri Jul 10 18:38:08 2009 -0700) 1 commit\n + apply: notice creation/removal patches produced by GNU diff\n\n* sb/pull-rebase (Sun Jul 19 09:45:16 2009 +0200) 2 commits\n + pull: support rebased upstream + fetch + pull --rebase\n + t5520-pull: Test for rebased upstream + fetch + pull --rebase\n\n* db/transport-shim (Sat Jul 25 13:51:40 2009 -0400) 3 commits\n - git-http-fetch: not a builtin\n - Use an external program to implement fetching with curl\n - Add support for external programs for handling native fetches\n\nInteresting as a concept.  I saw its ls-remote segfault on me, though.\nHopefully will mature by 1.6.5 final.\n\n* pb/tracking (Thu Jul 16 16:26:15 2009 -0500) 7 commits\n + branch.c: if remote is not config'd for branch, don't try delete\n   push config\n + branch, checkout: introduce autosetuppush\n + move deletion of merge configuration to branch.c\n + remote: add per-remote autosetupmerge and autosetuprebase\n   configuration\n + introduce a struct tracking_config\n + branch: install_branch_config and struct tracking refactoring\n + config: allow false and true values for branch.autosetuprebase\n\nAfter some discussion, I suspect we may want to rewind this out of 'next'\nand start over with a fresh design.\n\n* mk/init-db-parse-options (Sun Jul 12 12:24:32 2009 +0200) 1 commit\n + init-db: migrate to parse-options\n\n* tr/reset-checkout-patch (Sat Jul 25 23:29:34 2009 +0200) 5 commits\n - Implement 'git stash save --patch'\n - Implement 'git checkout --patch'\n - Implement 'git reset --patch'\n - builtin-add: refactor the meat of interactive_add()\n - git-apply--interactive: Refactor patch mode code\n\nStill in flux/rfc.\n\n----------------------------------------------------------------\n[Stalled and may need help and prodding to go forward]\n\n* gp/maint-rebase-p-onto (Wed Jul 22 12:38:58 2009 -0400) 1 commit\n . Fix rebase -p --onto\n\nI'd say we should take this even if it means Dscho needs his rebase -p\nrewrite.  It is not very pressing, so perhaps do so immediately after\n1.6.4 final.\n\n* jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n - Teach \"-m <msg>\" and \"-F <file>\" to \"git notes edit\"\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\nDscho asked about the performance implications of this; I do not think I\nsaw any progress on that yet...\n\nWill drop after 1.6.4 unless any further progress is seen.\n\n* ar/maint-1.6.2-merge-recursive-d-f (Mon May 11 21:25:36 2009 +0200) 2 commits\n - Fix for a merge where a branch has an F->D transition\n - Add a reminder test case for a merge with F/D transition\n\nAlthough the reported breakage is covered with the patch, Alex feels the\nsolution unsatisfactory. Cleaning up D/F conflict handling in merge-recursive\nmay be long overdue but seems to be a hard problem.\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.\n\nWill drop after 1.6.4 unless any further progress is seen.\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\nWill drop after 1.6.4 unless any further progress is seen.\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\nWill drop after 1.6.4 unless any further progress is seen.\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\nI have a feeling that the recent transport-shim series from the same\nauthor could supersede this one.\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\n----------------------------------------------------------------\n[Not actively cooking]\n\n* js/run-command-updates (Sat Jul 4 21:26:43 2009 +0200) 6 commits\n + receive-pack: remove unnecessary run_status report\n + run_command: report failure to execute the program, but optionally\n   don't\n + run_command: encode deadly signal number in the return value\n + run_command: report system call errors instead of returning error\n   codes\n + run_command: return exit code as positive value\n + MinGW: simplify waitpid() emulation macros\n\nWill merge after 1.6.4\n\n* cc/sequencer-rebase-i (Fri Jun 26 23:08:46 2009 +0200) 4 commits\n - rebase -i: use \"git sequencer--helper --make-patch\"\n - sequencer: free memory used in \"make_patch\" function\n - sequencer: add \"make_patch\" function to save a patch\n - sequencer: add \"builtin-sequencer--helper.c\"\n\n* en/fast-export (Thu Jun 25 22:48:33 2009 -0600) 7 commits\n + fast-export: Document the fact that git-rev-list arguments are\n   accepted\n + Add new fast-export testcases\n + fast-export: Add a --tag-of-filtered-object option for newly\n   dangling tags\n + fast-export: Do parent rewriting to avoid dropping relevant\n   commits\n + fast-export: Make sure we show actual ref names instead of\n   \"(null)\"\n + fast-export: Omit tags that tag trees\n + fast-export: Set revs.topo_order before calling setup_revisions\n\nShawn?  Dscho?\n\n* jc/diff-whitespace-only-status (Sat May 23 01:15:35 2009 -0700) 2 commits\n + diff: Rename QUIET internal option to QUICK\n + diff: change semantics of \"ignore whitespace\" options\n\nPossibly merge during 1.6.5, or 1.7.0 since this is a semantics change.\n\n* sb/read-tree (Thu Jun 25 22:14:10 2009 -0700) 2 commits\n + read-tree: migrate to parse-options\n + read-tree: convert unhelpful usage()'s to helpful die()'s\n\nWill merge after 1.6.4\n\n* ne/futz-upload-pack (Wed Jun 10 01:50:18 2009 +0200) 1 commit\n + Shift object enumeration out of upload-pack\n\nWill merge after 1.6.4\n\n* cc/replace (Wed May 27 07:14:09 2009 +0200) 14 commits\n + t6050: check pushing something based on a replaced commit\n + Documentation: add documentation for \"git replace\"\n + Add git-replace to .gitignore\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\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.  Will be kept in 'next' during 1.6.5 cycle.\n\n----------------------------------------------------------------\n[Dropped]\n\n* ae/maint-mailinfo-rm-only-one-patch-marker (Mon Jun 29 11:55:51 2009 +0200) 1 commit\n - mailinfo: Remove only one set of square brackets\n\n* lt/read-directory (Fri May 15 12:01:29 2009 -0700) 3 commits\n . Add initial support for pathname conversion to UTF-8\n . read_directory(): infrastructure for pathname character set\n   conversion\n . Add 'fill_directory()' helper function for directory traversal\n\nIt appears that we may want to settle with a MacOS X specific conversion,\nif somebody really cares enough.\n"},{"id":"118822","messageId":"m3ljmb3j7k.fsf@localhost.localdomain","threadId":"20237","inReplyTo":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-07-26T09:08:19Z","receivedAt":"2009-07-26T09:08:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> ----------------------------------------------------------------\n> [New Topics]\n> \n> * jk/show-tag (Sat Jul 18 06:14:37 2009 -0400) 2 commits\n>  + show: add space between multiple items\n>  + show: suppress extra newline when showing annotated tag\n> \n> Didn't look bad at all, but is not pressing either.\n\nI like the output of \"git show <tag>\" much better than current one\n(where I sometimes fall back on \"git cat-file -p <tag>\").\n \n> * jn/gitweb-blame (Sat Jul 25 00:44:10 2009 +0200) 10 commits\n>  - gitweb: Create links leading to 'blame_incremental' using\n>    JavaScript\n>  - gitweb: Incremental blame (proof of concept)\n>  - gitweb: Add optional \"time to generate page\" info in footer\n>  - gitweb: Add -partial_query option to href() subroutine\n\nThis part (above) is RFC, especially the 'incremental blame' patch,\nwhich is in flux.\n\nWell, perhaps except 'time to generate page' (aka. 'timed' feature),\nbut even this still have some things (like name of feature enabling\nthis behavior: currently 'named', or unconditional requiring\nTime::HiRes if it exists even if it is not needed).\n\n>  - gitweb: Use light/dark for class names also in 'blame' view\n>  - gitweb: Add author initials in 'blame' view, a la \"git gui blame\"\n>  - gitweb: Mark commits with no \"previous\" in 'blame' view\n>  - gitweb: Use \"previous\" header of git-blame -p in 'blame' view\n>  - gitweb: Mark boundary commits in 'blame' view\n>  - gitweb: Make .error style generic\n> \n> Still in flux/rfc.\n\nThis part is, I think, good now (after fixing embarassing but harmless\nunquote_maybe() incident ;-)).  Junio had some questions about style\nused, but it can be very easily fiddled with later, IMVHO.\n\n> \n> * ns/init-mkdir (Sat Jul 25 06:59:28 2009 +0900) 1 commit\n>  + git init: optionally allow a directory argument\n> \n> Didn't look bad, but is not pressing either.\n\nThis is I think good UI improvement.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"118829","messageId":"alpine.DEB.1.00.0907261231070.8306@pacific.mpi-cbg.de","threadId":"20237","inReplyTo":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","subject":"en/fast-export, was Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-26T10:32:13Z","receivedAt":"2009-07-26T10:32:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Jul 2009, Junio C Hamano wrote:\n\n> * en/fast-export (Thu Jun 25 22:48:33 2009 -0600) 7 commits\n>  + fast-export: Document the fact that git-rev-list arguments are\n>    accepted\n>  + Add new fast-export testcases\n>  + fast-export: Add a --tag-of-filtered-object option for newly\n>    dangling tags\n>  + fast-export: Do parent rewriting to avoid dropping relevant\n>    commits\n>  + fast-export: Make sure we show actual ref names instead of\n>    \"(null)\"\n>  + fast-export: Omit tags that tag trees\n>  + fast-export: Set revs.topo_order before calling setup_revisions\n> \n> Shawn?  Dscho?\n\nI think that those changes are good, even for 1.6.4.\n\nCiao,\nDscho\n"},{"id":"118831","messageId":"alpine.DEB.1.00.0907261232280.8306@pacific.mpi-cbg.de","threadId":"20237","inReplyTo":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","subject":"db/transport-shim, was Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-26T10:35:11Z","receivedAt":"2009-07-26T10:35:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Jul 2009, Junio C Hamano wrote:\n\n> * db/transport-shim (Sat Jul 25 13:51:40 2009 -0400) 3 commits\n>  - git-http-fetch: not a builtin\n>  - Use an external program to implement fetching with curl\n>  - Add support for external programs for handling native fetches\n> \n> Interesting as a concept.  I saw its ls-remote segfault on me, though.\n> Hopefully will mature by 1.6.5 final.\n> \n> [...]\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> I have a feeling that the recent transport-shim series from the same\n> author could supersede this one.\n\nOh, you mean that the foreign scm helpers would turn into shim helpers, \nwhich could then either call fast-import directly or use another helper?\n\nInteresting,\nDscho\n"},{"id":"118832","messageId":"4A6C6348.90607@alum.mit.edu","threadId":"20237","inReplyTo":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2009-07-26T14:08:08Z","receivedAt":"2009-07-26T14:08:08Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Junio C Hamano wrote:\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\nWhat needs to happen to get these changes moving again?  The last\nrelevant comment I can find from you about this subject is from 2009-02-22:\n\n> Thanks, both.  I generally am not very fond of adding tests without\n> intention to look into fixes, but if they make outstanding bugs more\n> visible, they may have the effect of shaming the original authors\n> badly enough to step in in the effort of fixing them  ;-)\n\nNo knight in shining armor has shown up to fix these bugs, but there is\nstill value to documenting them in the form of unit tests.\n\nMichael\n"},{"id":"118842","messageId":"alpine.DEB.1.00.0907261925370.8306@pacific.mpi-cbg.de","threadId":"20237","inReplyTo":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","subject":"gp/maint-rebase-p-onto, was Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-26T17:27:01Z","receivedAt":"2009-07-26T17:27:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Jul 2009, Junio C Hamano wrote:\n\n> ----------------------------------------------------------------\n> [Stalled and may need help and prodding to go forward]\n> \n> * gp/maint-rebase-p-onto (Wed Jul 22 12:38:58 2009 -0400) 1 commit\n>  . Fix rebase -p --onto\n> \n> I'd say we should take this even if it means Dscho needs his rebase -p\n> rewrite.  It is not very pressing, so perhaps do so immediately after\n> 1.6.4 final.\n\nMaybe better include it into 1.6.4?\n\nCiao,\nDscho\n"},{"id":"118843","messageId":"alpine.DEB.1.00.0907261927360.8306@pacific.mpi-cbg.de","threadId":"20237","inReplyTo":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-26T17:28:29Z","receivedAt":"2009-07-26T17:28:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Jul 2009, Junio C Hamano wrote:\n\n> * jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n>  - Teach \"-m <msg>\" and \"-F <file>\" to \"git notes edit\"\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> Dscho asked about the performance implications of this; I do not think I \n> saw any progress on that yet...\n\nI didn't see any progress, either.  And I am very disappointed.\n\nCiao,\nDscho\n"},{"id":"118879","messageId":"81b0412b0907270709kd6a5b8fy51829099d7b488e5@mail.gmail.com","threadId":"20237","inReplyTo":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-07-27T14:09:56Z","receivedAt":"2009-07-27T14:09:56Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Sun, Jul 26, 2009 at 10:47, Junio C Hamano<gitster@pobox.com> wrote:\n> * ar/maint-1.6.2-merge-recursive-d-f (Mon May 11 21:25:36 2009 +0200) 2 commits\n>  - Fix for a merge where a branch has an F->D transition\n>  - Add a reminder test case for a merge with F/D transition\n>\n> Although the reported breakage is covered with the patch, Alex feels the\n> solution unsatisfactory. Cleaning up D/F conflict handling in merge-recursive\n> may be long overdue but seems to be a hard problem.\n\nMaybe promote the testcase patch to master and drop (or leave it in\nnext) the other patch?\nSo that the reminder reminds not only people running next but also anyone who\nhappens to look at the output of their test suite run.\n"},{"id":"118926","messageId":"4A6EA86A.5010705@gnu.org","threadId":"20237","inReplyTo":"7viqhfrfu5.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2009-07-28T07:27:38Z","receivedAt":"2009-07-28T07:27:38Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> * pb/tracking (Thu Jul 16 16:26:15 2009 -0500) 7 commits\n>   + branch.c: if remote is not config'd for branch, don't try delete\n>     push config\n>   + branch, checkout: introduce autosetuppush\n>   + move deletion of merge configuration to branch.c\n>   + remote: add per-remote autosetupmerge and autosetuprebase\n>     configuration\n>   + introduce a struct tracking_config\n>   + branch: install_branch_config and struct tracking refactoring\n>   + config: allow false and true values for branch.autosetuprebase\n>\n> After some discussion, I suspect we may want to rewind this out of 'next'\n> and start over with a fresh design.\n\nIs your workflow to merge next to master after the release, or do you \ncherry-pick the merges?  If the latter, I propose that instead you \ngraduate to master only the first five patches (e.g. as \npb/per-remote-tracking).\n\nI'd rather not see the series reverted until there is some code for the \nfresh design.  While I like it overall, I tried implementing it and I \ncould not really do it in a nice way (I could not even find a way to \nnicely separate changes).\n\nDo you plan to merge at least the first two patches of \"git push \n--current\" (i.e. without the config option)?  Do you want me to resend \nthem separately?\n\nI will also separate from the --push series in two parts the patch that \nreuse \"git remote\" code in \"git clone\", so that you can get the first \none as a cleanup and I can resubmit the rest later if the fresh design \ndoes not work out.  I'll submit it after 1.6.4.\n\nPaolo\n"},{"id":"118929","messageId":"7v3a8h8cdc.fsf@alter.siamese.dyndns.org","threadId":"20237","inReplyTo":"4A6EA86A.5010705@gnu.org","subject":"Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-28T08:01:35Z","receivedAt":"2009-07-28T08:01:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini <bonzini@gnu.org> writes:\n\n> Is your workflow to merge next to master after the release, or do you\n> cherry-pick the merges?\n\nUsually 'next' will never rewind, and topics graduate by merging into\n'master', either as a whole or in steps.\n\nBut I've kept 'next' and 'pu' deliberately more inclusive during this -rc\nperiod, knowing that people by now would be very well aware that after the\nfinal release of 1.6.4, 'next' will be discarded and rebuilt with a few\nselected topics.  That means what currently is in 'next' can be safely\nkicked back to 'pu' or discarded if it turns out to be necessary.\n\nIf you have doubts or regrets in the series currently in 'next', you can\neven send in replacements if you want to (which is not how 'next' works\nnormally). I can revert the merge of the original series to 'next' and\nmerge the replacements during -rc period.  After 1.6.4, I can discard the\noriginal series and keep only the updated series.\n\nOn the other hand, if you want to keep going incremental, which is how\n'next' is supposed to work, that is perfectly Ok, too.  After 1.6.4, we\ncan decide what to do.\n\n> Do you plan to merge at least the first two patches of \"git push\n> --current\" (i.e. without the config option)?\n\nI am not quite sure if that is a good approach.  If the design is in flux,\nperhaps we should cook the code in 'pu' a bit longer until we know what\nend user interface want?  The last thing I want to do is to give end users\na set of new command line options in 'master' (or even 'next'), only to\nrevoke them before the next release.\n"},{"id":"118930","messageId":"4A6EB22F.6090007@gmail.com","threadId":"20237","inReplyTo":"7v3a8h8cdc.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)","fromName":"Paolo Bonzini","fromEmail":"paolo.bonzini@gmail.com","sentAt":"2009-07-28T08:09:19Z","receivedAt":"2009-07-28T08:09:19Z","isPatch":false,"sender":{"key":"paolo.bonzini@gmail.com","avatar":"https://gravatar.com/avatar/7817ef2e168b4ef0570c5bb5bdc1d4b44f34d3075fe32b871710dd942d0a89f5?d=mp&s=160"},"body":"On 07/28/2009 10:01 AM, Junio C Hamano wrote:\n> The last thing I want to do is to give end users\n> a set of new command line options in 'master' (or even 'next'), only to\n> revoke them before the next release.\n\nAgreed.  However, some people expressed appreciation for the new \ngit-push command-line option independent of the push.tracking work, of \nwhich I'd guess they might not even be aware.  If you agree, I would \nleave in pu the third patch (\"add remote.*.pushHeadOnly\") while merging \nthe first two to next.\n\nPaolo\n"}]}