{"thread":{"id":"18311","subject":"What's cooking in git.git (Mar 2009, #04; Sat, 14)","startedAt":"2009-03-15T06:28:58Z","lastAt":"2009-03-18T01:05:25Z","messageCount":10,"participants":["Junio C Hamano","Daniel Barkalow","Johannes Schindelin","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108035","messageId":"7vr60z8fkl.fsf@gitster.siamese.dyndns.org","threadId":"18311","inReplyTo":null,"subject":"What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-15T06:28:58Z","receivedAt":"2009-03-15T06:28:58Z","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\n----------------------------------------------------------------\n[New Topics]\n\n* bw/autoconf (Thu Mar 12 15:20:12 2009 -0400) 7 commits\n - configure: rework pthread handling to allow for user defined flags\n - configure: make iconv tests aware of user arguments\n - configure: asciidoc version test cleanup\n - configure: wrap some library tests with GIT_STASH_FLAGS\n - configure: add macros to stash FLAG variables\n - configure: reorganize flow of argument checks\n - configure: ensure settings from user are also usable in the script\n\nLooked quite expertly done but I do not use autoconf myself, so I'd merge\nthis to 'next' soon and see anybody screams.\n\n* jc/maint-1.6.0-read-tree-overlay (Thu Mar 12 00:02:12 2009 -0700) 1 commit\n - read-tree A B C: do not create a bogus index and do not segfault\n\n* fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit\n - New config push.default to decide default behavior for push\n\nReplaced the old series with the first step to allow a smooth transition.\nSome might argue that this should not give any warning but just give users\nthis new configuration to play with first, and after we know we are going\nto switch default some day, start the warning.\n\n* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit\n - blame.c: start libifying the blame infrastructure\n\n* jc/attributes-checkout (Fri Mar 13 21:24:08 2009 -0700) 1 commit\n - Read attributes from the index that is being checked out\n\n----------------------------------------------------------------\n[Graduated to \"master\"]\n\n* mg/maint-submodule-normalize-path (Tue Mar 3 16:08:21 2009 +0100) 2 commits\n + git submodule: Fix adding of submodules at paths with ./, .. and\n   //\n + git submodule: Add test cases for git submodule add\n\n* rs/memmem (Tue Mar 3 00:19:30 2009 +0100) 2 commits\n + optimize compat/ memmem()\n + diffcore-pickaxe: use memmem()\n\n* tv/rebase-stat (Sun Mar 1 22:28:28 2009 +0100) 2 commits\n + git-pull: Allow --stat and --no-stat to be used with --rebase\n + git-rebase: Add --stat and --no-stat for producing diffstat on\n   rebase\n\n* jk/clone-post-checkout (Tue Mar 3 00:37:51 2009 -0500) 1 commit\n + clone: run post-checkout hook when checking out\n\n* jc/maint-1.6.0-keep-pack (Sat Feb 28 00:37:19 2009 -0800) 6 commits\n + is_kept_pack(): final clean-up\n + Simplify is_kept_pack()\n + Consolidate ignore_packed logic more\n + has_sha1_kept_pack(): take \"struct rev_info\"\n + has_sha1_pack(): refactor \"pretend these packs do not exist\"\n   interface\n + git-repack: resist stray environment variable\n\nThis is in response to Linus's \"Really slow 'git gc'\" ($gmane/110743)\n\n* el/blame-date (Fri Feb 20 14:51:11 2009 -0800) 1 commit\n + Make git blame's date output format configurable, like git log\n\n* tr/gcov (Thu Feb 19 12:13:42 2009 +0100) 8 commits\n + Test git-patch-id\n + Test rev-list --parents/--children\n + Test log --decorate\n + Test fsck a bit harder\n + Test log --graph\n + Test diff --dirstat functionality\n + Test that diff can read from stdin\n + Support coverage testing with GCC/gcov\n\n* tr/format-patch-thread (Thu Feb 19 22:26:33 2009 +0100) 4 commits\n + format-patch: support deep threading\n + format-patch: thread as reply to cover letter even with in-reply-\n   to\n + format-patch: track several references\n + format-patch: threading test reactivation\n\n----------------------------------------------------------------\n[Will merge to 'master' soon]\n\n* kb/checkout-optim (Sun Mar 8 17:22:51 2009 -0400) 18 commits\n + Makefile: Set compiler switch for USE_NSEC\n + Create USE_ST_TIMESPEC and turn it on for Darwin\n + Not all systems use st_[cm]tim field for ns resolution file\n   timestamp\n + Record ns-timestamps if possible, but do not use it without\n   USE_NSEC\n + write_index(): update index_state->timestamp after flushing to\n   disk\n + verify_uptodate(): add ce_uptodate(ce) test\n + make USE_NSEC work as expected\n + fix compile error when USE_NSEC is defined\n + check_updates(): effective removal of cache entries marked\n   CE_REMOVE\n + lstat_cache(): print a warning if doing ping-pong between cache\n   types\n + show_patch_diff(): remove a call to fstat()\n + write_entry(): use fstat() instead of lstat() when file is open\n + write_entry(): cleanup of some duplicated code\n + create_directories(): remove some memcpy() and strchr() calls\n + unlink_entry(): introduce schedule_dir_for_removal()\n + lstat_cache(): swap func(length, string) into func(string, length)\n + lstat_cache(): generalise longest_match_lstat_cache()\n + lstat_cache(): small cleanup and optimisation\n\nKjetil has another fix-up patch for ctime/mtime gotcha that is not on this\nlist but after that is applied this series can go to 'master'.\n\n* tr/maint-1.6.0-send-email-irt (Wed Mar 11 23:40:13 2009 +0100) 2 commits\n + send-email: test --no-thread --in-reply-to combination\n + send-email: respect in-reply-to regardless of threading\n\n* js/remote-improvements (Sun Mar 8 00:10:33 2009 -0800) 23 commits\n + builtin-remote.c: no \"commented out\" code, please\n + builtin-remote: new show output style for push refspecs\n + builtin-remote: new show output style\n + remote: make guess_remote_head() use exact HEAD lookup if it is\n   available\n + builtin-remote: add set-head subcommand\n + builtin-remote: teach show to display remote HEAD\n + builtin-remote: fix two inconsistencies in the output of \"show\n   <remote>\"\n + builtin-remote: make get_remote_ref_states() always populate\n   states.tracked\n + builtin-remote: rename variables and eliminate redundant function\n   call\n + builtin-remote: remove unused code in get_ref_states\n + builtin-remote: refactor duplicated cleanup code\n + string-list: new for_each_string_list() function\n + remote: make match_refs() not short-circuit\n + remote: make match_refs() copy src ref before assigning to\n   peer_ref\n + remote: let guess_remote_head() optionally return all matches\n + remote: make copy_ref() perform a deep copy\n + remote: simplify guess_remote_head()\n + move locate_head() to remote.c\n + move duplicated ref_newer() to remote.c\n + move duplicated get_local_heads() to remote.c\n + refactor find_ref_by_name() to accept const list\n + add basic http clone/fetch tests\n + test scripts: refactor start_httpd helper\n\n----------------------------------------------------------------\n[Discarded]\n\n* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits\n . git commit: pathspec without -i/-o implies -i semantics during a\n   merge\n . builtin-commit: shorten eye-sore overlong lines\n . Add \"partial commit\" tests during a conflicted merge\n\nThis was only meant as a weatherballoon to help facilitate discussion.\n\n----------------------------------------------------------------\n[Stalled and may need help and prodding to go forward]\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* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit\n - archive.c: add support for --submodules[=(all|checkedout)]\n\nDiscussion stalled on the submodule selection criteria.\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 (Sun Jan 11 15:12:10 2009 -0500) 3 commits\n - Support fetching from foreign VCSes\n - Add specification of git-vcs helpers\n - Add \"vcs\" config option in remotes\n\nThe \"spec\" did not seem quite well cooked yet, but in the longer term I\nthink something like this to allow interoperating with other SCMs as if\nthe other end is a native git repository is a very worthy goal.\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\n----------------------------------------------------------------\n[Actively cooking]\n\n* mg/http-auth (Thu Mar 12 22:34:43 2009 -0700) 4 commits\n + http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient\n   versions of cURL\n + http authentication via prompts\n + http_init(): Fix config file parsing\n + http.c: style cleanups\n\nThis does only the fetch side but without any additional configuration\nvariables that looked like band-aid.\n\n* db/maint-missing-origin (Wed Mar 11 01:47:20 2009 -0400) 1 commit\n + Give error when no remote is configured\n\n* js/sideband-stderr (Tue Mar 10 22:58:09 2009 +0100) 2 commits\n + winansi: support ESC [ K (erase in line)\n + recv_sideband: Bands #2 and #3 always go to stderr\n\n* js/rsync-local (Mon Mar 9 19:44:55 2009 +0100) 1 commit\n + rsync transport: allow local paths, and fix tests\n\n* rs/color-grep (Sun Mar 8 18:22:44 2009 -0700) 6 commits\n + grep: cast printf %.*s \"precision\" argument explicitly to int\n + grep: add support for coloring with external greps\n + grep: color patterns in output\n + grep: add pmatch and eflags arguments to match_one_pattern()\n + grep: remove grep_opt argument from match_expr_eval()\n + grep: micro-optimize hit collection for AND nodes\n\n* db/refspec-wildcard-in-the-middle (Sat Mar 7 01:11:39 2009 -0500) 5 commits\n + Support '*' in the middle of a refspec\n + Keep '*' in pattern refspecs\n + Use the matching function to generate the match results\n + Use a single function to match names against patterns\n + Make clone parse the default refspec with the normal code\n\n* db/push-cleanup (Sun Mar 8 21:06:07 2009 -0400) 2 commits\n - Move push matching and reporting logic into transport.c\n - Use a common function to get the pretty name of refs\n\n* xx/db-refspec-vs-js-remote (Sun Mar 8 00:12:33 2009 -0800) 1 commit\n + Adjust js/remote-improvements and db/refspec-wildcard-in-the-\n   middle\n\n* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit\n + cvsimport: add test illustrating a bug in cvsps\n\nYet more tests without fixing anything...\n\n* jc/clone-branch-rebase (Tue Mar 10 01:20:42 2009 -0700) 2 commits\n + Improve \"git branch --tracking\" output\n + Make git-clone respect branch.autosetuprebase\n\nThis is a rewrite of a patch from Pat Notz.\n\n* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit\n + stat_tracking_info(): only count real commits\n\nThis gives the merge commits zero weight when talking about how many\ncommits you have ahead (or behind) of the branch you are tracking.  Even\nthough I agree that they should carry much less weight than the \"real\"\ncommits, because your repeated merge from the other branch does not really\nadd any real value to the end result, giving them absolute zero weight\nsomehow feels wrong. At least it shows that your have been _active_ on the\nbranch.  But I do not feel very strongly about it.\n\n* js/rebase-i-opt (Tue Mar 3 10:55:31 2009 +0100) 1 commit\n + rebase -i: avoid 'git reset' when possible\n\n* mv/parseopt-ls-files (Sat Mar 7 20:27:22 2009 -0500) 4 commits\n + ls-files: fix broken --no-empty-directory\n + t3000: use test_cmp instead of diff\n + parse-opt: migrate builtin-ls-files.\n + Turn the flags in struct dir_struct into a single variable\n\nThe tip one was a subject for further discussion, but nothing is queued\nyet.\n\n* fc/parseopt-config (Sat Mar 7 12:14:05 2009 -0500) 9 commits\n + config: set help text for --bool-or-int\n + git config: don't allow --get-color* and variable type\n + git config: don't allow extra arguments for -e or -l.\n + git config: don't allow multiple variable types\n + git config: don't allow multiple config file locations\n + git config: reorganize to use parseopt\n + git config: reorganize get_color*\n + git config: trivial rename in preparation for parseopt\n + git_config(): not having a per-repo config file is not an error\n\n* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits\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\nTests without fixes are of dubious value.  Any takers?\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\nRebased and then kicked back to 'pu' to give the author a chance to\nrearrange if necessary.  Nothing happened yet, but I see Dscho has been\nbusy on msysgit side of the world, so it is understandable.\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":"108158","messageId":"alpine.LNX.1.00.0903161834530.19665@iabervon.org","threadId":"18311","inReplyTo":"7vr60z8fkl.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-16T23:11:03Z","receivedAt":"2009-03-16T23:11:03Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 14 Mar 2009, Junio C Hamano wrote:\n\n> * db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits\n>  - Support fetching from foreign VCSes\n>  - Add specification of git-vcs helpers\n>  - Add \"vcs\" config option in remotes\n> \n> The \"spec\" did not seem quite well cooked yet, but in the longer term I\n> think something like this to allow interoperating with other SCMs as if\n> the other end is a native git repository is a very worthy goal.\n\nI recently figured out a way to alter the transport API slightly to make \nit possible to attach foreign VCSes there. This amounts to allowing \nget_refs_list() to leave the sha1s null, and allowing fetch() to set them. \nThis just requires a copy of a ref list in the clone path, and a check to \nmake null (for not having a ref) not match null (for not knowing the hash \nof the ref) in the fetch logic.\n\nI think I will end up changing the spec, mostly to allow a single \nnon-trivial call to the helper to provide both the list of refs and the \nfast-import stream; this matches how the pack protocol works (except, of \ncourse, that the initial list doesn't have hashes, and the output goes to \nfast-import instead of unpack-objects). I'm going to rebase the series at \nsome point, but I've been focused more on the more core transport and \nremote stuff now that I think I can go through that.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"108163","messageId":"7v4oxtuhki.fsf@gitster.siamese.dyndns.org","threadId":"18311","inReplyTo":"alpine.LNX.1.00.0903161834530.19665@iabervon.org","subject":"Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-17T00:19:25Z","receivedAt":"2009-03-17T00:19:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Sat, 14 Mar 2009, Junio C Hamano wrote:\n>\n>> * db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits\n>>  - Support fetching from foreign VCSes\n>>  - Add specification of git-vcs helpers\n>>  - Add \"vcs\" config option in remotes\n>> \n>> The \"spec\" did not seem quite well cooked yet, but in the longer term I\n>> think something like this to allow interoperating with other SCMs as if\n>> the other end is a native git repository is a very worthy goal.\n>\n> I recently figured out a way to alter the transport API slightly to make \n> it possible to attach foreign VCSes there. This amounts to allowing \n> get_refs_list() to leave the sha1s null, and allowing fetch() to set them. \n> This just requires a copy of a ref list in the clone path, and a check to \n> make null (for not having a ref) not match null (for not knowing the hash \n> of the ref) in the fetch logic.\n>\n> I think I will end up changing the spec, mostly to allow a single \n> non-trivial call to the helper to provide both the list of refs and the \n> fast-import stream; this matches how the pack protocol works (except, of \n> course, that the initial list doesn't have hashes, and the output goes to \n> fast-import instead of unpack-objects). I'm going to rebase the series at \n> some point, but I've been focused more on the more core transport and \n> remote stuff now that I think I can go through that.\n\nThanks for a wonderful news.\n"},{"id":"108208","messageId":"alpine.DEB.1.00.0903171125420.6393@intel-tinevez-2-302","threadId":"18311","inReplyTo":"7vr60z8fkl.fsf@gitster.siamese.dyndns.org","subject":"push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-17T10:28:31Z","receivedAt":"2009-03-17T10:28:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 14 Mar 2009, Junio C Hamano wrote:\n\n> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit\n>  - New config push.default to decide default behavior for push\n> \n> Replaced the old series with the first step to allow a smooth \n> transition. Some might argue that this should not give any warning but \n> just give users this new configuration to play with first, and after we \n> know we are going to switch default some day, start the warning.\n\nIIRC Steffen posted a patch series earlier, where he initialized \nremote.origin.push upon clone (I am not sure if he provided a \ncorresponding patch for checkout --track), but personally, I think that \nwould be nicer than having a push.default.\n\nCiao,\nDscho\n"},{"id":"108209","messageId":"alpine.DEB.1.00.0903171129050.6393@intel-tinevez-2-302","threadId":"18311","inReplyTo":"7vr60z8fkl.fsf@gitster.siamese.dyndns.org","subject":"notes, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-17T10:31:18Z","receivedAt":"2009-03-17T10:31:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 14 Mar 2009, Junio C Hamano wrote:\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> Rebased and then kicked back to 'pu' to give the author a chance to \n> rearrange if necessary.  Nothing happened yet, but I see Dscho has been \n> busy on msysgit side of the world, so it is understandable.\n\nActually, I have been busy in the real world, and msysGit was just a \nconsequence.\n\nBesides, the 'notes' feature is not as important to me as 'rebase -i -p', \nwhich I am trying hard to find the time to finish up properly.\n\nThe 'notes' changes as I have them in mind will also need some serious \ndiscussion, as I _think_ we should really have the flexibility of a \nvariable fan-out.  To prepare for that discussion, I'll have to do some \nserious thinking, which needs time for this old brain of mine.\n\nSo do not hold your breath...\n\nCiao,\nDscho\n"},{"id":"108283","messageId":"20090318063053.6117@nanako3.lavabit.com","threadId":"18311","inReplyTo":"alpine.DEB.1.00.0903171125420.6393@intel-tinevez-2-302","subject":"push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-03-17T21:30:53Z","receivedAt":"2009-03-17T21:30:53Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n\n> On Sat, 14 Mar 2009, Junio C Hamano wrote:\n>\n>> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit\n>>  - New config push.default to decide default behavior for push\n>> \n>> Replaced the old series with the first step to allow a smooth \n>> transition. Some might argue that this should not give any warning but \n>> just give users this new configuration to play with first, and after we \n>> know we are going to switch default some day, start the warning.\n>\n> IIRC Steffen posted a patch series earlier, where he initialized \n> remote.origin.push upon clone (I am not sure if he provided a \n> corresponding patch for checkout --track), but personally, I think that \n> would be nicer than having a push.default.\n\nIsn't recent trend to avoid such inconsistency between behavior in an existing repository and behavior in a newly created repository? For example, Jeff calls such inconsistency in\n\n  http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433\n\nas \"this breaks in my repo, but when I make a test repo it works\". Junio even called it 'madness' (^_^;)\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"108289","messageId":"alpine.DEB.1.00.0903172350270.10279@pacific.mpi-cbg.de","threadId":"18311","inReplyTo":"20090318063053.6117@nanako3.lavabit.com","subject":"Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-17T22:53:38Z","receivedAt":"2009-03-17T22:53:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Mar 2009, Nanako Shiraishi wrote:\n\n> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> \n> > On Sat, 14 Mar 2009, Junio C Hamano wrote:\n> >\n> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit\n> >>  - New config push.default to decide default behavior for push\n> >> \n> >> Replaced the old series with the first step to allow a smooth \n> >> transition. Some might argue that this should not give any warning \n> >> but just give users this new configuration to play with first, and \n> >> after we know we are going to switch default some day, start the \n> >> warning.\n> >\n> > IIRC Steffen posted a patch series earlier, where he initialized \n> > remote.origin.push upon clone (I am not sure if he provided a \n> > corresponding patch for checkout --track), but personally, I think \n> > that would be nicer than having a push.default.\n> \n> Isn't recent trend to avoid such inconsistency between behavior in an \n> existing repository and behavior in a newly created repository? For \n> example, Jeff calls such inconsistency in\n> \n>   http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433\n> \n> as \"this breaks in my repo, but when I make a test repo it works\". Junio \n> even called it 'madness' (^_^;)\n\nMy point is that it is _not_ an inconsistency.\n\nIt has a default setting.  One that already is well established.  Push the \nmatching refs.\n\nBut you can override it by setting the config variable.  Which is also \nwell established.\n\nThe only thing Steffen's patches would have changed would be to set the \ndefault differently now.\n\nWhich is not that much of a 'madness'.\n\nEspecially if you think about changing the default, which _will_ make for \nangry users (\"why did you change the default?  I _liked_ it!  Please \nrevert _now_!\").\n\nCiao,\nDscho\n"},{"id":"108295","messageId":"7vab7jpv93.fsf@gitster.siamese.dyndns.org","threadId":"18311","inReplyTo":"alpine.DEB.1.00.0903172350270.10279@pacific.mpi-cbg.de","subject":"Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-17T23:47:20Z","receivedAt":"2009-03-17T23:47:20Z","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> Hi,\n>\n> On Wed, 18 Mar 2009, Nanako Shiraishi wrote:\n>\n>> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n>> \n>> > On Sat, 14 Mar 2009, Junio C Hamano wrote:\n>> >\n>> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit\n>> >>  - New config push.default to decide default behavior for push\n>> >> \n>> >> Replaced the old series with the first step to allow a smooth \n>> >> transition. Some might argue that this should not give any warning \n>> >> but just give users this new configuration to play with first, and \n>> >> after we know we are going to switch default some day, start the \n>> >> warning.\n>> >\n>> > IIRC Steffen posted a patch series earlier, where he initialized \n>> > remote.origin.push upon clone (I am not sure if he provided a \n>> > corresponding patch for checkout --track), but personally, I think \n>> > that would be nicer than having a push.default.\n>> \n>> Isn't recent trend to avoid such inconsistency between behavior in an \n>> existing repository and behavior in a newly created repository? For \n>> example, Jeff calls such inconsistency in\n>> \n>>   http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433\n>> \n>> as \"this breaks in my repo, but when I make a test repo it works\". Junio \n>> even called it 'madness' (^_^;)\n>\n> My point is that it is _not_ an inconsistency.\n>\n> It has a default setting.  One that already is well established.  Push the \n> matching refs.\n>\n> But you can override it by setting the config variable.  Which is also \n> well established.\n>\n> The only thing Steffen's patches would have changed would be to set the \n> default differently now.\n>\n> Which is not that much of a 'madness'.\n>\n> Especially if you think about changing the default, which _will_ make for \n> angry users (\"why did you change the default?  I _liked_ it!  Please \n> revert _now_!\").\n\nI cloned my old project to my new machine with a recent git and it behaves\ndifferently.  Why did you change the default \"git clone\" creates, without\ntelling me?\n\nSounds like a huge inconsistency to me.\n"},{"id":"108298","messageId":"alpine.DEB.1.00.0903180138210.10279@pacific.mpi-cbg.de","threadId":"18311","inReplyTo":"7vab7jpv93.fsf@gitster.siamese.dyndns.org","subject":"Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-18T00:40:39Z","receivedAt":"2009-03-18T00:40:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Mar 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > On Wed, 18 Mar 2009, Nanako Shiraishi wrote:\n> >\n> >> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >> \n> >> > On Sat, 14 Mar 2009, Junio C Hamano wrote:\n> >> >\n> >> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit\n> >> >>  - New config push.default to decide default behavior for push\n> >> >> \n> >> >> Replaced the old series with the first step to allow a smooth \n> >> >> transition. Some might argue that this should not give any warning \n> >> >> but just give users this new configuration to play with first, and \n> >> >> after we know we are going to switch default some day, start the \n> >> >> warning.\n> >> >\n> >> > IIRC Steffen posted a patch series earlier, where he initialized \n> >> > remote.origin.push upon clone (I am not sure if he provided a \n> >> > corresponding patch for checkout --track), but personally, I think \n> >> > that would be nicer than having a push.default.\n> >> \n> >> Isn't recent trend to avoid such inconsistency between behavior in an \n> >> existing repository and behavior in a newly created repository? For \n> >> example, Jeff calls such inconsistency in\n> >> \n> >>   http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433\n> >> \n> >> as \"this breaks in my repo, but when I make a test repo it works\". \n> >> Junio even called it 'madness' (^_^;)\n> >\n> > My point is that it is _not_ an inconsistency.\n> >\n> > It has a default setting.  One that already is well established.  \n> > Push the matching refs.\n> >\n> > But you can override it by setting the config variable.  Which is also \n> > well established.\n> >\n> > The only thing Steffen's patches would have changed would be to set \n> > the default differently now.\n> >\n> > Which is not that much of a 'madness'.\n> >\n> > Especially if you think about changing the default, which _will_ make \n> > for angry users (\"why did you change the default?  I _liked_ it!  \n> > Please revert _now_!\").\n> \n> I cloned my old project to my new machine with a recent git and it \n> behaves differently.  Why did you change the default \"git clone\" \n> creates, without telling me?\n> \n> Sounds like a huge inconsistency to me.\n\nOkay, I'll bite.\n\nIn my git.git clone on one machine, I have remote.orcz.push = master.  I \ncloned it.  There, \"git push\" does something different.\n\nInconsistent right there, correct?  Without any change to git.git.\n\nAssume push.default goes in.\n\nNothing changes in my scenario.  Inconsistency right there.\n\nCiao,\nDscho\n"},{"id":"108304","messageId":"7vwsanod2i.fsf@gitster.siamese.dyndns.org","threadId":"18311","inReplyTo":"alpine.DEB.1.00.0903180138210.10279@pacific.mpi-cbg.de","subject":"Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-18T01:05:25Z","receivedAt":"2009-03-18T01:05:25Z","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> In my git.git clone on one machine, I have remote.orcz.push = master.  I \n> cloned it.  There, \"git push\" does something different.\n>\n> Inconsistent right there, correct?  Without any change to git.git.\n\nYou must be smoking something potent.  It's a nonsense argument and you\nknow it.\n\nIn your git.git clone on one machine, you have some setting.\n\nYou cloned it to one machine some time ago.  It behave differently and\nthat is something that has always been true, and you know it.  Repository\nconfiguration is private.\n\nYou clone it to another today.  Now the new clone, without any\nconfiguration, will behave differently from the other clone, that you\nhaven't done any funny configuration.\n\nThat's inconsistent.\n"}]}