{"thread":{"id":"17428","subject":"What's cooking in git.git (Jan 2009, #07; Wed, 28)","startedAt":"2009-01-29T02:06:45Z","lastAt":"2009-02-12T21:51:26Z","messageCount":30,"participants":["Junio C Hamano","Jeff King","Charles Bailey","Sverre Rabbelier","Pieter de Bie","Nico -telmich- Schottelius","Johannes Schindelin","Kirill Smelkov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"102386","messageId":"7vwscej26i.fsf@gitster.siamese.dyndns.org","threadId":"17428","inReplyTo":null,"subject":"What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-29T02:06:45Z","receivedAt":"2009-01-29T02:06:45Z","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* jc/maint-1.6.0-split-diff-metainfo (Mon Jan 26 00:08:24 2009 -0800) 1 commit\n + diff.c: output correct index lines for a split diff\n\nThis is slated for maintenance series 1.6.0.X, 1.6.1.X and also for\n'master'. I think the change is pretty safe and sane to go directly to\n'master' but I had too many other topoics to look at that I did not feel\ncomfortable enough to do so.\n\n* jc/maint-split-diff-metainfo (Tue Jan 27 01:08:02 2009 -0800) 2 commits\n + Merge branch 'jc/maint-1.6.0-split-diff-metainfo' into jc/maint-\n split-diff-metainfo\n + diff.c: output correct index lines for a split diff\n\nEarly conflict resolution branch for the above to carry it to 1.6.1X\nseries.\n\n* js/maint-rebase-i-submodule (Tue Jan 27 12:42:31 2009 +0100) 2 commits\n + Fix submodule squashing into unrelated commit\n + rebase -i squashes submodule changes into unrelated commit\n\n* jg/tag-contains (Mon Jan 26 09:13:25 2009 -0500) 3 commits\n + git-tag: Add --contains option\n + Make has_commit() non-static\n + Make opt_parse_with_commit() non-static\n\n* jk/maint-cleanup-after-exec-failure (Wed Jan 28 02:38:14 2009 -0500) 4 commits\n + git: use run_command() to execute dashed externals\n + run_command(): help callers distinguish errors\n + run_command(): handle missing command errors more gracefully\n + git: s/run_command/run_builtin/\n\n* jc/maint-allow-uninteresting-missing (Tue Jan 27 23:19:30 2009 -0800) 1 commit\n + revision traversal: allow UNINTERESTING objects to be missing\n\nThis is a small follow-up to the fix to send-pack in 1.6.1; meant to go in\n1.6.1.X maintenance series and newer.\n\n* am/maint-push-doc (Mon Jan 26 00:45:33 2009 +0100) 3 commits\n + Documentation: rework src/dst description in git push\n + Documentation: more git push examples\n + Documentation: simplify refspec format description\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\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* jc/maint-add-u-remove-conflicted (Wed Jan 28 14:24:53 2009 -0800) 1 commit\n - add -u: do not fail to resolve a path as deleted\n\nThis has been updated from the posted version with a correction.\n\n* ns/am-slacker (Sat Jan 24 10:18:02 2009 +0900) 2 commits\n + git-am: Add --ignore-date option\n + am: Add --committer-date-is-author-date option\n\nIt is a (probably) useful new feature with a sort-of cute explanation.\n\n* jc/maint-apply-fix (Sun Jan 25 23:41:26 2009 -0800) 1 commit\n + builtin-apply.c: do not set bogus mode in check_preimage() for\n deleted path\n\n----------------------------------------------------------------\n[Stalled and may need help and prodding to go forward]\n\n* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits\n + blame: show \"previous\" information in --porcelain/--incremental\n format\n + git-blame: refactor code to emit \"porcelain format\" output\n\nThis gives Porcelains (like gitweb) the information on the commit _before_\nthe one that the final blame is laid on, which should save them one\nrev-parse to dig further. The line number in the \"previous\" information\nmay need refining, and sanity checking code for reference counting may\nneed to be resurrected before this can move forward.\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 (Fri Jan 23 10:07:46 2009 +0100) 7 commits\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\nNobody has review comments on this yet.\n\n* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 6 commits\n - archive.c: add support for --submodules[=(all|checkedout)]\n - tree.c: allow read_tree_recursive() to traverse gitlink entries\n + Revert round #1 of the series\n + builtin-ls-tree: enable traversal of submodules\n + archive.c: enable traversal of submodules\n + tree.c: add support for traversal of submodules\n\n----------------------------------------------------------------\n[Reverted]\n\n* mh/unify-color (Fri Jan 23 01:25:23 2009 -0800) 3 commits\n ? Revert previous two commits\n ? move the color variables to color.c\n ? handle color.ui at a central place\n\nThis broke git-format-patch badly.\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits\n - valgrind: ignore ldso errors\n - Add valgrind support in test scripts\n\nDscho and Peff had further exchanges on the list; I am sort of waiting for\nthe conclusion before picking any intermediate version up.\n\n* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 4 commits\n + mailinfo: tests for RFC2047 examples\n + mailinfo: add explicit test for mails like '\n (A U Thor)'\n + mailinfo: 'From:' header should be unfold as well\n + mailinfo: correctly handle multiline 'Subject:' header\n\nI just got tired of waiting and cleaned up the series myself.\n\n* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits\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\nIt would be nice to hear a real world success story using the notes\nmechanism; Dscho says he also wants to make sure the current choice\nof the structure scales well before casting it in stone.\n\n* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits\n - gitweb: Optional grouping of projects by category\n - gitweb: Split git_project_list_body in two functions\n - gitweb: Modularized git_get_project_description to be more generic\n\nDesign discussion between Jakub and Sebastien continues.\n\n----------------------------------------------------------------\n[Graduated to \"master\"]\n\n* sr/clone-empty (Fri Jan 23 01:07:32 2009 +0100) 1 commit\n + Allow cloning an empty repository\n\nHas anybody actually tried this and made sure the resulting empty clone\nworks fine after the clone source gets updated with some contents?\n\n* kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits\n + lstat_cache(): introduce clear_lstat_cache() function\n + lstat_cache(): introduce invalidate_lstat_cache() function\n + lstat_cache(): introduce has_dirs_only_path() function\n + lstat_cache(): introduce has_symlink_or_noent_leading_path()\n function\n + lstat_cache(): more cache effective symlink/directory detection\n\n* tr/previous-branch (Wed Jan 21 00:37:38 2009 -0800) 10 commits\n + Simplify parsing branch switching events in reflog\n + Introduce for_each_recent_reflog_ent().\n + interpret_nth_last_branch(): plug small memleak\n + Fix reflog parsing for a malformed branch switching entry\n + Fix parsing of @{-1}@{1}\n + interpret_nth_last_branch(): avoid traversing the reflog twice\n + checkout: implement \"-\" abbreviation, add docs and tests\n + sha1_name: support @{-N} syntax in get_sha1()\n + sha1_name: tweak @{-N} lookup\n + checkout: implement \"@{-N}\" shortcut name for N-th last branch\n\n* js/maint-all-implies-HEAD (Sat Jan 17 22:27:08 2009 -0800) 2 commits\n + bundle: allow the same ref to be given more than once\n + revision walker: include a detached HEAD in --all\n\n* cb/add-pathspec (Wed Jan 14 15:54:35 2009 +0100) 2 commits\n + remove pathspec_match, use match_pathspec instead\n + clean up pathspec matching\n\n* js/diff-color-words (Tue Jan 20 22:59:54 2009 -0600) 9 commits\n + Change the spelling of \"wordregex\".\n + color-words: Support diff.wordregex config option\n + color-words: make regex configurable via attributes\n + color-words: expand docs with precise semantics\n + color-words: enable REG_NEWLINE to help user\n + color-words: take an optional regular expression describing words\n + color-words: change algorithm to allow for 0-character word\n boundaries\n + color-words: refactor word splitting and use ALLOC_GROW()\n + Add color_fwrite_lines(), a function coloring each line\n individually\n\n----------------------------------------------------------------\n[Will merge to \"master\" soon]\n\n* jg/mergetool (Sat Jan 24 00:12:45 2009 +0100) 1 commit\n + mergetool: Don't repeat merge tool candidates\n\n* cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit\n + mergetool: respect autocrlf by using checkout-index\n\nNow Ted told us not to wait for him, we'll go ahead by ourselves ;-).\n\n* jk/signal-cleanup (Thu Jan 22 01:03:28 2009 -0500) 5 commits\n + pager: do wait_for_pager on signal death\n + refactor signal handling for cleanup functions\n + chain kill signals for cleanup functions\n + diff: refactor tempfile cleanup handling\n + Windows: Fix signal numbers\n\n* sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 7 commits\n + Windows: Revert to default paths and convert them by\n RUNTIME_PREFIX\n + Compute prefix at runtime if RUNTIME_PREFIX is set\n + Modify setup_path() to only add git_exec_path() to PATH\n + Add calls to git_extract_argv0_path() in programs that call\n git_config_*\n + git_extract_argv0_path(): Move check for valid argv0 from caller\n to callee\n + Refactor git_set_argv0_path() to git_extract_argv0_path()\n + Move computation of absolute paths from Makefile to runtime (in\n preparation for RUNTIME_PREFIX)\n\n----------------------------------------------------------------\n[On Hold]\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 is only meant as a weatherballoon to help facilitate discussion.\n\n* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit\n . diff: enable \"too large a rename\" warning when -M/-C is explicitly\n asked for\n\n* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits\n . git-am --forge: add Signed-off-by: line for the author\n . git-am: clean-up Signed-off-by: lines\n . stripspace: add --log-clean option to clean up signed-off-by:\n lines\n . stripspace: use parse_options()\n . Add \"git am -s\" test\n . git-am: refactor code to add signed-off-by line for the committer\n\n* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits\n . revision --simplify-merges: incremental simplification\n . revision --simplify-merges: prepare for incremental simplification\n\n* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits\n . valgrind: ignore ldso errors\n . add valgrind support in test scripts\n\n* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits\n . In add --patch, Handle K,k,J,j slightly more gracefully.\n . Add / command in add --patch\n . git-add -i/-p: Change prompt separater from slash to comma\n"},{"id":"102396","messageId":"20090129033816.GB11836@coredump.intra.peff.net","threadId":"17428","inReplyTo":"7vwscej26i.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-29T03:38:16Z","receivedAt":"2009-01-29T03:38:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:\n\n> * js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits\n> - valgrind: ignore ldso errors\n> - Add valgrind support in test scripts\n> \n> Dscho and Peff had further exchanges on the list; I am sort of waiting for\n> the conclusion before picking any intermediate version up.\n\nI think I gave an OK to the last version posted, but then the last thing\nI saw from Dscho was \"I have a new patch, but I'm not posting it right\nthis second\":\n\n http://article.gmane.org/gmane.comp.version-control.git/107300\n\nfollowed by much \"is zlib broken\" discussion which I think doesn't hold\nus up (either it is a bug in zlib, in which case it is not our problem,\nor it is a false positive, in which case we just add a suppression).\n\nSo I think we are waiting for the next round from Johannes.\n\n> * jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits\n> . valgrind: ignore ldso errors\n> . add valgrind support in test scripts\n\nI think it probably makes sense to drop these at this point. Dscho's\nmore recent work should be the basis to which new patches are compared.\n\n-Peff\n"},{"id":"102399","messageId":"20090129035138.GC11836@coredump.intra.peff.net","threadId":"17428","inReplyTo":"7vwscej26i.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-29T03:51:38Z","receivedAt":"2009-01-29T03:51:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:\n\n> * sr/clone-empty (Fri Jan 23 01:07:32 2009 +0100) 1 commit\n> + Allow cloning an empty repository\n> \n> Has anybody actually tried this and made sure the resulting empty clone\n> works fine after the clone source gets updated with some contents?\n\nHmm. It sort of works:\n\n $ mkdir parent && (cd parent && git init)\n Initialized empty Git repository in /home/peff/parent/.git/\n\n $ git clone parent child\n Initialized empty Git repository in /home/peff/child/.git/\n warning: You appear to have cloned an empty repository.\n\nSo far so good...\n\n $ (cd parent && echo content >file && git add file && git commit -m one)\n [normal commit output]\n $ (cd child && git fetch)\n [normal fetch output]\n\nBut:\n\n $ (cd child && git pull)\n You asked me to pull without telling me which branch you\n want to merge with, and 'branch.master.merge' in\n ...\n\nSo it's not quite seamless. The problem is that we're not setting up the\nbranch.master.* config on the empty clone. Nor do we set up\nrefs/remotes/origin/HEAD.\n\nOn top of that, I get funniness between versions:\n\n $ ssh peff.net 'git version && mkdir foo && cd foo && git init'\n git version 1.5.6.5\n Initialized empty Git repository in /mnt/data/home/peff/foo/.git/\n\n $ git clone peff.net:foo\n Initialized empty Git repository in /home/peff/foo/.git/\n warning: You appear to have cloned an empty repository.\n $ fatal: The remote end hung up unexpectedly\n\n-Peff\n"},{"id":"102400","messageId":"20090129040254.GD11836@coredump.intra.peff.net","threadId":"17428","inReplyTo":"20090129035138.GC11836@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-29T04:02:54Z","receivedAt":"2009-01-29T04:02:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 28, 2009 at 10:51:38PM -0500, Jeff King wrote:\n\n> But:\n> \n> $ (cd child && git pull)\n> You asked me to pull without telling me which branch you\n> want to merge with, and 'branch.master.merge' in\n> ...\n> \n> So it's not quite seamless. The problem is that we're not setting up the\n> branch.master.* config on the empty clone. Nor do we set up\n> refs/remotes/origin/HEAD.\n\nHrm. I was thinking we checked out \"master\" as a branch yet to be born,\nbut of course that doesn't work because we don't even know that the name\n\"master\" exists on the other side (to do that, we would need an\nextension to transmit symref information for a ref yet to be born).\n\nWe could always assume the remote side is going to eventually put\ncontent on \"master\" (we know they aren't using another branch _now_, or\nthe repo wouldn't be empty, so we are just guessing they will follow the\nusual convention). That feels a bit hack-ish, though.\n\nSo the current behavior is probably sane. But it is not obvious to a\nuser how to extend their repo one the upstream isn't empty. Maybe the\n\"empty repo\" warning could mention \"git fetch && git checkout -b master\norigin/master\" (which is the most obvious way I can think of)?\n\n-Peff\n"},{"id":"102402","messageId":"7vab9aivvv.fsf@gitster.siamese.dyndns.org","threadId":"17428","inReplyTo":"20090129040254.GD11836@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-29T04:22:44Z","receivedAt":"2009-01-29T04:22:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> We could always assume the remote side is going to eventually put\n> content on \"master\" (we know they aren't using another branch _now_, or\n> the repo wouldn't be empty, so we are just guessing they will follow the\n> usual convention). That feels a bit hack-ish, though.\n\nNow, doesn't \"The other end is empty\" error start looking much saner than\neverybody seems to have thought ;-)?\n"},{"id":"102416","messageId":"20090129081438.GA10490@hashpling.org","threadId":"17428","inReplyTo":"7vwscej26i.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Charles Bailey","fromEmail":"charles@hashpling.org","sentAt":"2009-01-29T08:14:38Z","receivedAt":"2009-01-29T08:14:38Z","isPatch":false,"sender":{"key":"charles@hashpling.org","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:\n> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit\n> + mergetool: respect autocrlf by using checkout-index\n> \n\nCan you hold off on merging this one? I now think that there's a\ncleaner way of doing this and I would like the opportunity for a\nrethink.\n\n-- \nCharles Bailey\nhttp://ccgi.hashpling.plus.com/blog/\n"},{"id":"102418","messageId":"7vbptqh60w.fsf@gitster.siamese.dyndns.org","threadId":"17428","inReplyTo":"20090129081438.GA10490@hashpling.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-29T08:26:39Z","receivedAt":"2009-01-29T08:26:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Charles Bailey writes:\n\n> On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:\n>> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit\n>> + mergetool: respect autocrlf by using checkout-index\n>> \n>\n> Can you hold off on merging this one? I now think that there's a\n> cleaner way of doing this and I would like the opportunity for a\n> rethink.\n\nSure, it is not in 'master' yet.\n\nBut it's in 'next', so incremental updates from now on, please.\n"},{"id":"102422","messageId":"20090129091611.GB10490@hashpling.org","threadId":"17428","inReplyTo":"7vbptqh60w.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Charles Bailey","fromEmail":"charles@hashpling.org","sentAt":"2009-01-29T09:16:11Z","receivedAt":"2009-01-29T09:16:11Z","isPatch":false,"sender":{"key":"charles@hashpling.org","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Thu, Jan 29, 2009 at 12:26:39AM -0800, Junio C Hamano wrote:\n> Charles Bailey writes:\n> \n> > On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:\n> >> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit\n> >> + mergetool: respect autocrlf by using checkout-index\n> >> \n> >\n> > Can you hold off on merging this one? I now think that there's a\n> > cleaner way of doing this and I would like the opportunity for a\n> > rethink.\n> \n> Sure, it is not in 'master' yet.\n> \n> But it's in 'next', so incremental updates from now on, please.\n> \n\nOK, I've thought again and I still think that this patch is good.\n\nJust so you know what I was thinking...\n\nI felt that the new shell function that calls git checkout-index was a\nbit clunky. git checkout-index --temp creates its own temporary file\nand then the git mergetool renames this file to the temporary filename\nthat it had already decided on.\n\nAn earlier patch to mergetool was careful to ensure that mergetool\ntemporaries maintained the file extension of the target file in order\nto help syntax highlighting merge tools. For this reason, just using\ncheckout-index generated filenames is not a sufficient solution.\n\nI had two ideas, the first was that perhaps git mergetool could choose\na temporary naming scheme that could be matched by the appropriate use\nof checkout-index --prefix. This would obviously preserve the file\nextension but it's fairly obvious that it would have surprising\nbehaviour for merging files in subfolders.\n\nMy last idea would be to add an explicit --to-path= to git\ncheckout-index. It would make the mergetool code simpler but I'm not\nsure how useful it would be in any other circumstance.\n\n-- \nCharles Bailey\nhttp://ccgi.hashpling.plus.com/blog/\n"},{"id":"102430","messageId":"bd6139dc0901290327u572cc30ci9dc719c912fbf875@mail.gmail.com","threadId":"17428","inReplyTo":"20090129035138.GC11836@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-29T11:27:23Z","receivedAt":"2009-01-29T11:27:23Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 29, 2009 at 04:51, Jeff King wrote:\n> $ mkdir parent && (cd parent && git init)\n> Initialized empty Git repository in /home/peff/parent/.git/\n>\n> $ git clone parent child\n> Initialized empty Git repository in /home/peff/child/.git/\n> warning: You appear to have cloned an empty repository.\n>\n> So far so good...\n>\n> $ (cd parent && echo content >file && git add file && git commit -m one)\n> [normal commit output]\n> $ (cd child && git fetch)\n> [normal fetch output]\n\nI thought instead we wanted to support the following workflow:\n\n$ (cd child && echo content >file && git add file && git commit -m one)\n[normal commit output]\n\nWhich is what the testcase tests. E.g., we want to support cloning an\nempty repo so that the user can then _push_ to that repository to make\nit non-empty, no?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"102431","messageId":"20090129113735.GA6505@coredump.intra.peff.net","threadId":"17428","inReplyTo":"bd6139dc0901290327u572cc30ci9dc719c912fbf875@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-29T11:37:36Z","receivedAt":"2009-01-29T11:37:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 29, 2009 at 12:27:23PM +0100, Sverre Rabbelier wrote:\n\n> I thought instead we wanted to support the following workflow:\n> \n> $ (cd child && echo content >file && git add file && git commit -m one)\n> [normal commit output]\n> \n> Which is what the testcase tests. E.g., we want to support cloning an\n> empty repo so that the user can then _push_ to that repository to make\n> it non-empty, no?\n\nTrue, that is probably going to be more common (otherwise, why would the\nperson who is going to push into the empty repo advertise it to you\nbefore they have put any content in it).\n\nBut it will probably still be surprising not to have the branch merging\nsetup:\n\n mkdir parent && (cd parent && git init) &&\n git clone parent child && cd child &&\n echo content >file && git add file && git commit -m one &&\n git push origin master ;# note we have to explicitly mention the branch\n\n ... time passes ...\n\n git pull\n\nproduces the \"you haven't asked me which branch to merge\" message.\n\nWhich does make some sense, given how tracking configuration is set up.\nIt's just that it's a little sad that cloning an empty repository and\nthen later getting commits out of it (whether commits you put in or\nsomebody else) does not behave the same as cloning a repository with\ncommits.\n\nWhich I thought was sort of the point, that this would work seamlessly.\nOtherwise, there is not much advantage over:\n\n mkdir parent && (cd parent && git init) &&\n mkdir child && cd child && git init &&\n echo content >file && git add file && git commit -m one &&\n git push origin master ;# note we have to explicitly mention the branch\n\nWith the empty clone, you get your \"origin\" remote set up, but in both\ncases you are missing the branch tracking.\n\nI don't know if there is a good solution, though. Perhaps it's best to\njust let what's there get released and see if people complain.\n\n-Peff\n"},{"id":"102432","messageId":"351A6988-32EB-473F-B6E5-8FBB38D91F88@ai.rug.nl","threadId":"17428","inReplyTo":"20090129113735.GA6505@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2009-01-29T11:40:42Z","receivedAt":"2009-01-29T11:40:42Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 29 jan 2009, at 11:37, Jeff King wrote:\n\n> git push origin master ;# note we have to explicitly mention the \n> branch\n>\n> ... time passes ...\n>\n> git pull\n>\n> produces the \"you haven't asked me which branch to merge\" message.\n>\n> Which does make some sense, given how tracking configuration is set \n> up.\n> It's just that it's a little sad that cloning an empty repository and\n> then later getting commits out of it (whether commits you put in or\n> somebody else) does not behave the same as cloning a repository with\n> commits.\n\nThis is true in all cases. If you create a new branch in any repository,\npush that, and later do a 'git pull', you get that message. I agree it's\nnot the nicest way to handle things, but this is not an issue with the \nclone,\nit's an issue of pushing new branches in general.\n"},{"id":"102433","messageId":"bd6139dc0901290345u4962f747gbe93c945ab35c9cb@mail.gmail.com","threadId":"17428","inReplyTo":"351A6988-32EB-473F-B6E5-8FBB38D91F88@ai.rug.nl","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-29T11:45:23Z","receivedAt":"2009-01-29T11:45:23Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 29, 2009 at 12:40, Pieter de Bie wrote:\n> This is true in all cases. If you create a new branch in any repository,\n> push that, and later do a 'git pull', you get that message. I agree it's\n> not the nicest way to handle things, but this is not an issue with the\n> clone, it's an issue of pushing new branches in general.\n\nMhhh, so maybe we want a way to set up tracking branches when pushing,\nyes? From what I've seen a patch to do that shouldn't be too hard, so\nif there's interest in that I could look into that.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"102434","messageId":"20090129114834.GA10792@coredump.intra.peff.net","threadId":"17428","inReplyTo":"351A6988-32EB-473F-B6E5-8FBB38D91F88@ai.rug.nl","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-29T11:48:34Z","receivedAt":"2009-01-29T11:48:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 29, 2009 at 11:40:42AM +0000, Pieter de Bie wrote:\n\n> This is true in all cases. If you create a new branch in any\n> repository, push that, and later do a 'git pull', you get that\n> message. I agree it's not the nicest way to handle things, but this is\n> not an issue with the clone, it's an issue of pushing new branches in\n> general.\n\nRight. I guess I was hoping by cloning an existing repository, even one\nwith no commits on the branch, that we could somehow remember that we\nare \"on\" the master branch. I think that is what people who ask for\nempty cloning really want:\n\n 1. make a bare upstream\n\n 2. clone empty repo\n\n 3. create commits\n\n 4. git push / git pull, as if we had cloned non-empty repo\n\nAnd I know that it is not very \"git\" to talk about empty branches, since\nbranches are pointers into the DAG. But we already do similar trickery\nwith \"yet to be born\" branches by putting a dangling symref into HEAD.\nBut I don't think there's any way currently to send those dangling\nsymrefs across the git protocol, which is what would be required to do\nthe above accurately.\n\n-Peff\n"},{"id":"102436","messageId":"20090129115026.GB10792@coredump.intra.peff.net","threadId":"17428","inReplyTo":"bd6139dc0901290345u4962f747gbe93c945ab35c9cb@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-29T11:50:26Z","receivedAt":"2009-01-29T11:50:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 29, 2009 at 12:45:23PM +0100, Sverre Rabbelier wrote:\n\n> On Thu, Jan 29, 2009 at 12:40, Pieter de Bie wrote:\n> > This is true in all cases. If you create a new branch in any repository,\n> > push that, and later do a 'git pull', you get that message. I agree it's\n> > not the nicest way to handle things, but this is not an issue with the\n> > clone, it's an issue of pushing new branches in general.\n> \n> Mhhh, so maybe we want a way to set up tracking branches when pushing,\n> yes? From what I've seen a patch to do that shouldn't be too hard, so\n> if there's interest in that I could look into that.\n\nI think that would be reasonable. It wouldn't help the case of \"somebody\nelse pushed some content that you want to pull\", but like you said, I\nthink the primary workflow is that you immediately push after cloning\nthe empty repo.\n\n-Peff\n"},{"id":"102438","messageId":"20090129120455.GD3027@denkbrett.schottelius.org","threadId":"17428","inReplyTo":"20090129114834.GA10792@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Nico -telmich- Schottelius","fromEmail":"nico-linux-git@schottelius.org","sentAt":"2009-01-29T12:04:55Z","receivedAt":"2009-01-29T12:04:55Z","isPatch":false,"sender":{"key":"nico-linux-git@schottelius.org","avatar":null},"body":"Jeff King [Thu, Jan 29, 2009 at 06:48:34AM -0500]:\n> [...] I think that is what people who ask for empty cloning really want:\n> \n> 1. make a bare upstream\n> \n> 2. clone empty repo\n> \n> 3. create commits\n> \n> 4. git push / git pull, as if we had cloned non-empty repo\n\nI must confess, as a user I would like to do\n\n1. create local repo\n\n2. create a remote\n\n3. push it\n\nI don't care about creating empty repos somewhere:\nMy aim is to publish my work, that's it.\n\nComments on the steps:\n\n 1.1. I don't care whether I push a empty repo or not. But pushing an empty\n one does not make much sense, so refusing this would be reasonable\n\n 1.2. When creating a new repo, it would be helpful if I can directly add a\n description: git init [description] would be nice to have\n\n 2.1. I (as a user) understand that I need to create a remote where I have to\n push to. It would be helpful to specify --track-this/--merge-this to\n have it automatically connected to the current branch\n\n 3.1. I would really like to see something like git push\n --create[-if-not-exists]. This makes sense for me, but could also\n be a global configuration option (push.autocreate = true|false).\n\n\nJust a comment from a user's point of view ;-)\n\nSincerly,\n\nNico\n\n-- \nThink about Free and Open Source Software (FOSS).\nhttp://nico.schottelius.org/documentations/foss/the-term-foss/\n\nPGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C\n"},{"id":"102441","messageId":"bd6139dc0901290420x1216a399w656e4d1622178a06@mail.gmail.com","threadId":"17428","inReplyTo":"20090129115026.GB10792@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-29T12:20:20Z","receivedAt":"2009-01-29T12:20:20Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 29, 2009 at 12:50, Jeff King wrote:\n> I think that would be reasonable.\n\nYay :).\n\n> It wouldn't help the case of \"somebody\n> else pushed some content that you want to pull\", but like you said, I\n> think the primary workflow is that you immediately push after cloning\n> the empty repo.\n\nAlso, the only way to support the \"somebody else pushed already\"\nworkflow would be to assume the user wants to name the branch\n'master', which might not be the case at all.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"102543","messageId":"20090130045131.GB18655@coredump.intra.peff.net","threadId":"17428","inReplyTo":"bd6139dc0901290420x1216a399w656e4d1622178a06@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-30T04:51:32Z","receivedAt":"2009-01-30T04:51:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 29, 2009 at 01:20:20PM +0100, Sverre Rabbelier wrote:\n\n> > It wouldn't help the case of \"somebody\n> > else pushed some content that you want to pull\", but like you said, I\n> > think the primary workflow is that you immediately push after cloning\n> > the empty repo.\n> \n> Also, the only way to support the \"somebody else pushed already\"\n> workflow would be to assume the user wants to name the branch\n> 'master', which might not be the case at all.\n\nYou could make a guess that they will use \"master\", and if you are\nwrong, it behaves as now. But if you are right, \"git pull\" pulls down\nmaster automatically.\n\nBut that is getting a little confusing. So let's push this \"git push\n--track\" idea to completion and see how people like it.\n\n-Peff\n"},{"id":"102544","messageId":"20090130045916.GC18655@coredump.intra.peff.net","threadId":"17428","inReplyTo":"20090129120455.GD3027@denkbrett.schottelius.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-30T04:59:16Z","receivedAt":"2009-01-30T04:59:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 29, 2009 at 01:04:55PM +0100, Nico -telmich- Schottelius wrote:\n\n> I must confess, as a user I would like to do\n> \n> 1. create local repo\n> \n> 2. create a remote\n> \n> 3. push it\n> \n> I don't care about creating empty repos somewhere:\n> My aim is to publish my work, that's it.\n\nI think people have asked for that before, too. The fundamental problem\nis that we don't necessarily know how to create the remote repo, or even\nhave permissions to do so.\n\nIf your transport is vanilla ssh, then in theory we could turn\n\"host:path.git\" into \"ssh host 'GIT_DIR=path.git git init'\". But for\nother transports we are out of luck. And for hosting sites like github,\nwe are out of luck, as you use the web interface to make a new repo.\n\n> 1.2. When creating a new repo, it would be helpful if I can directly add a\n> description: git init [description] would be nice to have\n\nI don't think there is any fundamental reason not to allow more setup of\ninternal .git/* files through 'init'. In most cases, you could just as\neasily \"echo description >.git/description\" afterwards, but it might be\nslightly more convenient if you are ssh'ing to do it all in one shot.\n\n> 2.1. I (as a user) understand that I need to create a remote where I have to\n> push to. It would be helpful to specify --track-this/--merge-this to\n> have it automatically connected to the current branch\n\n git remote add -t master origin $URL ?\n\n> 3.1. I would really like to see something like git push\n> --create[-if-not-exists]. This makes sense for me, but could also\n> be a global configuration option (push.autocreate = true|false).\n\nI think this would be better as a feature of \"git remote\". I.e.:\n\n git remote add --create -t master origin $URL\n\nbut again, we can only sanely do creation magic in a subset of cases.\nWhich is why I think nobody has implemented it so far.\n\n-Peff\n"},{"id":"102585","messageId":"alpine.DEB.1.00.0901301415260.3586@pacific.mpi-cbg.de","threadId":"17428","inReplyTo":"20090130045131.GB18655@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-30T13:18:32Z","receivedAt":"2009-01-30T13:18:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Jan 2009, Jeff King wrote:\n\n> On Thu, Jan 29, 2009 at 01:20:20PM +0100, Sverre Rabbelier wrote:\n> \n> > > It wouldn't help the case of \"somebody\n> > > else pushed some content that you want to pull\", but like you said, I\n> > > think the primary workflow is that you immediately push after cloning\n> > > the empty repo.\n> > \n> > Also, the only way to support the \"somebody else pushed already\"\n> > workflow would be to assume the user wants to name the branch\n> > 'master', which might not be the case at all.\n> \n> You could make a guess that they will use \"master\", and if you are\n> wrong, it behaves as now. But if you are right, \"git pull\" pulls down\n> master automatically.\n> \n> But that is getting a little confusing. So let's push this \"git push\n> --track\" idea to completion and see how people like it.\n\nHow about installing\n\n\t[branch \"master\"]\n\t\tremote = origin\n\t\tmerge = refs/heads/master\n\nby default? It is a safe bet that this will be the case for 99% of all \nusers that want to clone an empty repository (especially if they are \nputting their public repositories on something like repo.or.cz, where you \ncannot change the default branch from \"master\" to something else).\n\nAnd if somebody wants to track another branch, tough, she has to call \nthis:\n\n\t$ git checkout -t origin/blablabla\n\nCiao,\nDscho\n"},{"id":"102616","messageId":"20090130162603.GB7065@sigill.intra.peff.net","threadId":"17428","inReplyTo":"alpine.DEB.1.00.0901301415260.3586@pacific.mpi-cbg.de","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-30T16:26:03Z","receivedAt":"2009-01-30T16:26:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 30, 2009 at 02:18:32PM +0100, Johannes Schindelin wrote:\n\n> > You could make a guess that they will use \"master\", and if you are\n> > wrong, it behaves as now. But if you are right, \"git pull\" pulls down\n> > master automatically.\n> > \n> > But that is getting a little confusing. So let's push this \"git push\n> > --track\" idea to completion and see how people like it.\n> \n> How about installing\n> \n> \t[branch \"master\"]\n> \t\tremote = origin\n> \t\tmerge = refs/heads/master\n> \n> by default? It is a safe bet that this will be the case for 99% of all \n> users that want to clone an empty repository (especially if they are \n> putting their public repositories on something like repo.or.cz, where you \n> cannot change the default branch from \"master\" to something else).\n> \n> And if somebody wants to track another branch, tough, she has to call \n> this:\n> \n> \t$ git checkout -t origin/blablabla\n\nI was tempted to suggest that, but I haven't thought through whether\nthere are any lurking corner cases (which empty clone seems to be\nfraught with). So I think it is a reasonable thing to try and play with.\n\n-Peff\n"},{"id":"102618","messageId":"20090130163241.GC26321@hashpling.org","threadId":"17428","inReplyTo":"20090129091611.GB10490@hashpling.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Charles Bailey","fromEmail":"charles@hashpling.org","sentAt":"2009-01-30T16:32:41Z","receivedAt":"2009-01-30T16:32:41Z","isPatch":false,"sender":{"key":"charles@hashpling.org","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Thu, Jan 29, 2009 at 09:16:11AM +0000, Charles Bailey wrote:\n> On Thu, Jan 29, 2009 at 12:26:39AM -0800, Junio C Hamano wrote:\n> > Charles Bailey writes:\n> > \n> > > On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:\n> > >> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit\n> > >> + mergetool: respect autocrlf by using checkout-index\n> > >> \n> > >\n> > > Can you hold off on merging this one? I now think that there's a\n> > > cleaner way of doing this and I would like the opportunity for a\n> > > rethink.\n> > \n> > Sure, it is not in 'master' yet.\n> > \n> > But it's in 'next', so incremental updates from now on, please.\n> > \n> \n> OK, I've thought again and I still think that this patch is good.\n\nExcept that I was completely wrong. Please continue to hold off\nmerging into master until you've rolled in the future patch that fixes\nmergetool in subdirectories which I'll clean-up and send later today.\n\nSorry about this.\n\n-- \nCharles Bailey\nhttp://ccgi.hashpling.plus.com/blog/\n"},{"id":"102734","messageId":"7vr62j0wpc.fsf@gitster.siamese.dyndns.org","threadId":"17428","inReplyTo":"alpine.DEB.1.00.0901301415260.3586@pacific.mpi-cbg.de","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-01T01:31:27Z","receivedAt":"2009-02-01T01:31:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> How about installing\n>\n> \t[branch \"master\"]\n> \t\tremote = origin\n> \t\tmerge = refs/heads/master\n>\n> by default? It is a safe bet that this will be the case for 99% of all \n> users that want to clone an empty repository (especially if they are \n> putting their public repositories on something like repo.or.cz, where you \n> cannot change the default branch from \"master\" to something else).\n\nI think this is a reasonable thing to do. Even though cloning from a void\nis not entirely a reasonable thing to do to begin with, because we are\ngoing ahead to allow it now, it would be the best thing to do when cloning\na repository served by the currently deployed git.\n\nWe _could_ do better if we were to resurrect my earlier series to add\n\"where does the HEAD point at\" protocol extension, but even then we would\nneed a fallback like your suggestion when talking to older servers anyway.\n"},{"id":"102758","messageId":"20090201174505.GA14181@roro3.zxlink","threadId":"17428","inReplyTo":"7vwscej26i.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Kirill Smelkov","fromEmail":"kirr@landau.phys.spbu.ru","sentAt":"2009-02-01T17:45:05Z","receivedAt":"2009-02-01T17:45:05Z","isPatch":false,"sender":{"key":"kirr@navytux.spb.ru","avatar":"https://gravatar.com/avatar/cf3445fdad1849941e17ab25bf1ee7c5ea1be2deb444be25ff5f36b0e50a985f?d=mp&s=160"},"body":"On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:\n\n[...]\n\n> * ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 4 commits\n> + mailinfo: tests for RFC2047 examples\n> + mailinfo: add explicit test for mails like '\n> (A U Thor)'\n> + mailinfo: 'From:' header should be unfold as well\n> + mailinfo: correctly handle multiline 'Subject:' header\n> \n> I just got tired of waiting and cleaned up the series myself.\n\nSorry about that. Here is the missing bit (based on master)\n\n--- 8< ---\n\nSubject: [PATCH] mailinfo: cleanup extra spaces for complex 'From:'\n\ncurrently for cases like\n\n From: A U Thor (Comment)\n\nmailinfo extracts the following 'Author:' field:\n\n Author: A U Thor (Comment)\n ^^\nwhich has two extra spaces left in there after removed email part.\n\nI think this is wrong so here is a fix.\n\nSigned-off-by: Kirill Smelkov \n---\n builtin-mailinfo.c | 19 +++++++++++++++----\n t/t5100/info0001 | 2 +-\n t/t5100/rfc2047-info-0004 | 2 +-\n t/t5100/sample.mbox | 4 ++--\n 4 files changed, 19 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin-mailinfo.c b/builtin-mailinfo.c\nindex d4dc23a..2789ccd 100644\n--- a/builtin-mailinfo.c\n+++ b/builtin-mailinfo.c\n@@ -29,6 +29,9 @@ static struct strbuf **p_hdr_data, **s_hdr_data;\n #define MAX_HDR_PARSED 10\n #define MAX_BOUNDARIES 5\n \n+static void cleanup_space(struct strbuf *sb);\n+\n+\n static void get_sane_name(struct strbuf *out, struct strbuf *name, struct strbuf *email)\n {\n \tstruct strbuf *src = name;\n@@ -109,11 +112,19 @@ static void handle_from(const struct strbuf *from)\n \tstrbuf_add(&email, at, el);\n \tstrbuf_remove(&f, at - f.buf, el + (at[el] ? 1 : 0));\n \n-\t/* The remainder is name. It could be \"John Doe \"\n-\t * or \"john.doe@xz (John Doe)\", but we have removed the\n-\t * email part, so trim from both ends, possibly removing\n-\t * the () pair at the end.\n+\t/* The remainder is name. It could be\n+\t *\n+\t * - \"John Doe \"\t\t\t(a), or\n+\t * - \"john.doe@xz (John Doe)\"\t\t\t(b), or\n+\t * - \"John (zzz) Doe (Comment)\"\t(c)\n+\t *\n+\t * but we have removed the email part, so\n+\t *\n+\t * - remove extra spaces which could stay after email (case 'c'), and\n+\t * - trim from both ends, possibly removing the () pair at the end\n+\t * (cases 'a' and 'b').\n \t */\n+\tcleanup_space(&f);\n \tstrbuf_trim(&f);\n \tif (f.buf[0] == '(' && f.len && f.buf[f.len - 1] == ')') {\n \t\tstrbuf_remove(&f, 0, 1);\ndiff --git a/t/t5100/info0001 b/t/t5100/info0001\nindex 8c05277..f951538 100644\n--- a/t/t5100/info0001\n+++ b/t/t5100/info0001\n@@ -1,4 +1,4 @@\n-Author: A U Thor\n+Author: A (zzz) U Thor (Comment)\n Email: a.u.thor@example.com\n Subject: a commit.\n Date: Fri, 9 Jun 2006 00:44:16 -0700\ndiff --git a/t/t5100/rfc2047-info-0004 b/t/t5100/rfc2047-info-0004\nindex 0ca7ff0..f67a90a 100644\n--- a/t/t5100/rfc2047-info-0004\n+++ b/t/t5100/rfc2047-info-0004\n@@ -1,4 +1,4 @@\n-Author: Nathaniel Borenstein (םולש ןב ילטפנ)\n+Author: Nathaniel Borenstein (םולש ןב ילטפנ)\n Email: nsb@thumper.bellcore.com\n Subject: Test of new header generator\n \ndiff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox\nindex 85df55f..c5ad206 100644\n--- a/t/t5100/sample.mbox\n+++ b/t/t5100/sample.mbox\n@@ -2,10 +2,10 @@\n \t\n \n From nobody Mon Sep 17 00:00:00 2001\n-From: A\n+From: A (zzz)\n U\n Thor\n- \n+ (Comment)\n Date: Fri, 9 Jun 2006 00:44:16 -0700\n Subject: [PATCH] a commit.\n \n-- \n1.6.1.284.g5dc13\n\n--- 8< ---\n\n\nThanks,\nKirill\n"},{"id":"102781","messageId":"7v4ozdsuyd.fsf@gitster.siamese.dyndns.org","threadId":"17428","inReplyTo":"20090201174505.GA14181@roro3.zxlink","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-01T21:34:02Z","receivedAt":"2009-02-01T21:34:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks, will apply.\n"},{"id":"104346","messageId":"7v3aekqhpo.fsf@gitster.siamese.dyndns.org","threadId":"17428","inReplyTo":"7vr62j0wpc.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-12T06:42:27Z","receivedAt":"2009-02-12T06:42:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Schindelin writes:\n>\n>> How about installing\n>>\n>> \t[branch \"master\"]\n>> \t\tremote = origin\n>> \t\tmerge = refs/heads/master\n>>\n>> by default? It is a safe bet that this will be the case for 99% of all \n>> users that want to clone an empty repository (especially if they are \n>> putting their public repositories on something like repo.or.cz, where you \n>> cannot change the default branch from \"master\" to something else).\n>\n> I think this is a reasonable thing to do.\n\nSo I've been sort of waiting for a trivial patch to materialize, and then\nalmost forgot about it like everybody else did. Before all of us forget,\nhere is my attempt to do the above.\n\nWe seem to have acquired a bad habit of discussing and agreeing on a\npotential improvement and then not following through, forgetting it\naltogether.\n\nExciting new features we can count on original submitters to stick to them\nand push them forward whether we go into a release freeze, but the more\nboring kind of patches that we already know what we want to see by the\nnext release are actually the more important to the overall project;\nsadly, they tend to get lost somewhere in the crack. I wonder if we can\ndo anything about it.\n\nAnd no, a bug tracker is not the answer, even though it could be a (small)\npart of the solution.\n\n-- >8 --\nSubject: Install the default \"master\" branch configuration after cloning a void\n\nAfter \"cloning from an empty repository\", we have a configuration to\ndescribe the remote's URL and the default ref mappings, but we lack the\nbranch configuration for the default branch we create on our end,\n\"master\".\n\nIt is likely that the empty repository we cloned from will point the\ndefault \"master\" branch with its HEAD, so prepare the local configuration\nto match.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-clone.c | 22 +++++++++++++++++-----\n 1 files changed, 17 insertions(+), 5 deletions(-)\n\ndiff --git a/builtin-clone.c b/builtin-clone.c\nindex f73029e..431c136 100644\n--- a/builtin-clone.c\n+++ b/builtin-clone.c\n@@ -350,6 +350,18 @@ static struct ref *write_remote_refs(const struct ref *refs,\n \treturn local_refs;\n }\n \n+static void install_branch_config(const char *origin, const char *local,\n+\t\t\t\t const char *remote)\n+{\n+\tstruct strbuf key = STRBUF_INIT;\n+\tstrbuf_addf(&key, \"branch.%s.remote\", local);\n+\tgit_config_set(key.buf, origin);\n+\tstrbuf_reset(&key);\n+\tstrbuf_addf(&key, \"branch.%s.merge\", local);\n+\tgit_config_set(key.buf, remote);\n+\tstrbuf_release(&key);\n+}\n+\n int cmd_clone(int argc, const char **argv, const char *prefix)\n {\n \tint use_local_hardlinks = 1;\n@@ -539,6 +551,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\thead_points_at = NULL;\n \t\tremote_head = NULL;\n \t\toption_no_checkout = 1;\n+\t\tif (!option_bare)\n+\t\t\tinstall_branch_config(option_origin, \"master\",\n+\t\t\t\t\t \"refs/heads/master\");\n \t}\n \n \tif (head_points_at) {\n@@ -567,11 +582,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\t\t\t head_points_at->peer_ref->name,\n \t\t\t\t reflog_msg.buf);\n \n-\t\t\tstrbuf_addf(&key, \"branch.%s.remote\", head);\n-\t\t\tgit_config_set(key.buf, option_origin);\n-\t\t\tstrbuf_reset(&key);\n-\t\t\tstrbuf_addf(&key, \"branch.%s.merge\", head);\n-\t\t\tgit_config_set(key.buf, head_points_at->name);\n+\t\t\tinstall_branch_config(option_origin, head,\n+\t\t\t\t\t head_points_at->name);\n \t\t}\n \t} else if (remote_head) {\n \t\t/* Source had detached HEAD pointing somewhere. */\n"},{"id":"104367","messageId":"bd6139dc0902120251g6b1ee6d0i688c9f1a4b003a4e@mail.gmail.com","threadId":"17428","inReplyTo":"7v3aekqhpo.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-12T10:51:21Z","receivedAt":"2009-02-12T10:51:21Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Feb 12, 2009 at 07:42, Junio C Hamano wrote:\n> Exciting new features we can count on original submitters to stick to them\n> and push them forward whether we go into a release freeze, but the more\n> boring kind of patches that we already know what we want to see by the\n> next release are actually the more important to the overall project;\n> sadly, they tend to get lost somewhere in the crack.  I wonder if we can\n> do anything about it.\n\nI'm sorry for not picking up on this, the deadline Melange being done\nis getting closer (GSoC org applications are starting in less than a\nmonth), that together with school having started again results in me\nhaving little time left.\n\nThanks for following up on this!\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"104369","messageId":"alpine.DEB.1.00.0902121200420.10279@pacific.mpi-cbg.de","threadId":"17428","inReplyTo":"7v3aekqhpo.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-12T11:04:32Z","receivedAt":"2009-02-12T11:04:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Feb 2009, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > Johannes Schindelin writes:\n> >\n> >> How about installing\n> >>\n> >> \t[branch \"master\"]\n> >> \t\tremote = origin\n> >> \t\tmerge = refs/heads/master\n> >>\n> >> by default? It is a safe bet that this will be the case for 99% of all \n> >> users that want to clone an empty repository (especially if they are \n> >> putting their public repositories on something like repo.or.cz, where you \n> >> cannot change the default branch from \"master\" to something else).\n> >\n> > I think this is a reasonable thing to do.\n> \n> So I've been sort of waiting for a trivial patch to materialize, and then\n> almost forgot about it like everybody else did. Before all of us forget,\n> here is my attempt to do the above.\n\nThanks.\n\n> We seem to have acquired a bad habit of discussing and agreeing on a \n> potential improvement and then not following through, forgetting it \n> altogether.\n\nYeah, I am pretty excited at my rebase -i -p branch at the moment, so I am \nprone to forget other things (push --track included).\n\n> And no, a bug tracker is not the answer, even though it could be a \n> (small) part of the solution.\n\nIf you really want to know how much a bug tracker is not the solution, \nbecause it is a fire-and-forget (as in post, and never come back, \neven with a small little message that the fix actually worked) place for \nmany bug reporters, just look at msysGit's bug tracker and weep.\n\n> diff --git a/builtin-clone.c b/builtin-clone.c\n> index f73029e..431c136 100644\n> --- a/builtin-clone.c\n> +++ b/builtin-clone.c\n> @@ -350,6 +350,18 @@ static struct ref *write_remote_refs(const struct ref *refs,\n> \treturn local_refs;\n> }\n> \n> +static void install_branch_config(const char *origin, const char *local,\n> +\t\t\t\t const char *remote)\n\nI would have used a different order (local, origin, remote), but that's \nokay, I guess.\n\nCiao,\nDscho\n"},{"id":"104377","messageId":"20090212123207.GA5397@sigill.intra.peff.net","threadId":"17428","inReplyTo":"7v3aekqhpo.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-12T12:32:08Z","receivedAt":"2009-02-12T12:32:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 11, 2009 at 10:42:27PM -0800, Junio C Hamano wrote:\n\n> We seem to have acquired a bad habit of discussing and agreeing on a\n> potential improvement and then not following through, forgetting it\n> altogether.\n> \n> Exciting new features we can count on original submitters to stick to them\n> and push them forward whether we go into a release freeze, but the more\n> boring kind of patches that we already know what we want to see by the\n> next release are actually the more important to the overall project;\n> sadly, they tend to get lost somewhere in the crack. I wonder if we can\n> do anything about it.\n\nI used to be more diligent about making a note of such things in my todo\nlist and then actually trying to reduce the size of that todo list\noccasionally. But my git time has shrunk a bit lately due to my day job,\nand I have been spending more time reviewing patches and discussing\nideas on the list, so it has been a while since I have actually sat down\nto check something off of my todo.\n\nI think in this case it was a matter of \"it didn't make it onto\nanybody's todo list\". So I think it is nice that you put together the\npatch; but I also think a gentle nudge of \"so is anybody going to do\nthis?\" would have worked, since it gives another chance for people to\nclaim ownership.\n\n> And no, a bug tracker is not the answer, even though it could be a (small)\n> part of the solution.\n\nMaybe it would be sufficient to simply keep a public record of\nintent-to-work on certain topics. Usually it is obvious from the mail\nexchange what is going to happen next, but sometimes (as I think in this\ncase) it is left somewhat ambiguous.\n\n> -- >8 --\n> Subject: Install the default \"master\" branch configuration after cloning a void\n\nThe patch looks good to me.\n\n-Peff\n"},{"id":"104420","messageId":"7vzlgrjrjz.fsf@gitster.siamese.dyndns.org","threadId":"17428","inReplyTo":"alpine.DEB.1.00.0902121200420.10279@pacific.mpi-cbg.de","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-12T21:04:00Z","receivedAt":"2009-02-12T21:04:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> diff --git a/builtin-clone.c b/builtin-clone.c\n>> index f73029e..431c136 100644\n>> --- a/builtin-clone.c\n>> +++ b/builtin-clone.c\n>> @@ -350,6 +350,18 @@ static struct ref *write_remote_refs(const struct ref *refs,\n>> \treturn local_refs;\n>> }\n>> \n>> +static void install_branch_config(const char *origin, const char *local,\n>> +\t\t\t\t const char *remote)\n>\n> I would have used a different order (local, origin, remote), but that's \n> okay, I guess.\n\nOk, here is an incremental that will be squashed.\n\n builtin-clone.c | 7 ++++---\n t/t5601-clone.sh | 15 +++++++++++++++\n 2 files changed, 19 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-clone.c b/builtin-clone.c\nindex 431c136..c338910 100644\n--- a/builtin-clone.c\n+++ b/builtin-clone.c\n@@ -350,7 +350,8 @@ static struct ref *write_remote_refs(const struct ref *refs,\n \treturn local_refs;\n }\n \n-static void install_branch_config(const char *origin, const char *local,\n+static void install_branch_config(const char *local,\n+\t\t\t\t const char *origin,\n \t\t\t\t const char *remote)\n {\n \tstruct strbuf key = STRBUF_INIT;\n@@ -552,7 +553,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\tremote_head = NULL;\n \t\toption_no_checkout = 1;\n \t\tif (!option_bare)\n-\t\t\tinstall_branch_config(option_origin, \"master\",\n+\t\t\tinstall_branch_config(\"master\", option_origin,\n \t\t\t\t\t \"refs/heads/master\");\n \t}\n \n@@ -582,7 +583,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\t\t\t head_points_at->peer_ref->name,\n \t\t\t\t reflog_msg.buf);\n \n-\t\t\tinstall_branch_config(option_origin, head,\n+\t\t\tinstall_branch_config(head, option_origin,\n \t\t\t\t\t head_points_at->name);\n \t\t}\n \t} else if (remote_head) {\ndiff --git a/t/t5601-clone.sh b/t/t5601-clone.sh\nindex fe287d3..44793f2 100755\n--- a/t/t5601-clone.sh\n+++ b/t/t5601-clone.sh\n@@ -144,4 +144,19 @@ test_expect_success 'clone to an existing path' '\n \ttest_must_fail git clone src target-5\n '\n \n+test_expect_success 'clone a void' '\n+\tmkdir src-0 &&\n+\t(\n+\t\tcd src-0 && git init\n+\t) &&\n+\tgit clone src-0 target-6 &&\n+\t(\n+\t\tcd src-0 && test_commit A\n+\t) &&\n+\tgit clone src-0 target-7 &&\n+\t# There is no reason to insist they are bit-for-bit\n+\t# identical, but this test should suffice for now.\n+\ttest_cmp target-6/.git/config target-7/.git/config\n+'\n+\n test_done\n"},{"id":"104436","messageId":"alpine.DEB.1.00.0902122251120.10279@pacific.mpi-cbg.de","threadId":"17428","inReplyTo":"7vzlgrjrjz.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-12T21:51:26Z","receivedAt":"2009-02-12T21:51:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 12 Feb 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> diff --git a/builtin-clone.c b/builtin-clone.c\n> >> index f73029e..431c136 100644\n> >> --- a/builtin-clone.c\n> >> +++ b/builtin-clone.c\n> >> @@ -350,6 +350,18 @@ static struct ref *write_remote_refs(const struct ref *refs,\n> >> \treturn local_refs;\n> >> }\n> >> \n> >> +static void install_branch_config(const char *origin, const char *local,\n> >> +\t\t\t\t const char *remote)\n> >\n> > I would have used a different order (local, origin, remote), but that's \n> > okay, I guess.\n> \n> Ok, here is an incremental that will be squashed.\n\nThanks, very much appreciated,\nDscho\n"}]}