{"thread":{"id":"43164","subject":"Re: git-shortlog mailmap","startedAt":"2006-10-26T08:47:12Z","lastAt":"2006-10-27T01:10:54Z","messageCount":26,"participants":["Andreas Ericsson","Johannes Schindelin","Jakub Narebski","Petr Baudis","Andy Whitcroft","Nicolas Pitre","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296784","messageId":"7vk62npipb.fsf@assigned-by-dhcp.cox.net","threadId":"43164","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T08:47:12Z","receivedAt":"2006-10-26T08:47:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"* The 'maint' branch has produced 1.4.3.3 and has these fixes\n since the last announcement (some of them are post 1.4.3.3).\n\n Christian Couder (1):\n Remove --syslog in git-daemon inetd documentation examples.\n\n Eric Wong (1):\n git-svn: fix symlink-to-file changes when using command-line svn 1.4.0\n\n Gerrit Pape (1):\n Set $HOME for selftests\n\n J. Bruce Fields (1):\n Documentation: updates to \"Everyday GIT\"\n\n Jakub Narebski (1):\n diff-format.txt: Combined diff format documentation supplement\n\n Junio C Hamano (6):\n Documentation: note about contrib/.\n RPM package re-classification.\n Refer to git-rev-parse:Specifying Revisions from git.txt\n Update cherry documentation.\n Documentation/SubmittingPatches: 3+1 != 6\n Documentation: clarify refname disambiguation rules.\n\n Petr Baudis (1):\n xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines\n\n Tuncer Ayaz (1):\n git-fetch.sh printed protocol fix\n\n\n* The 'master' branch has these since the last announcement.\n\n I've flushed all the 'gitweb/' changes from \"next\" and core\n support that some of them needed; notably \"for-each-ref\" and\n \"blame --porcelain\" is now in \"master\". Oh, and \"annotate\"\n is now a mere synonym for \"blame -c\".\n\n Alan Chandler (1):\n Gitweb - provide site headers and footers\n\n Andy Whitcroft (2):\n cvsimport: move over to using git-for-each-ref to read refs.\n git-for-each-ref: improve the documentation on scripting modes\n\n Christian Couder (1):\n Remove --syslog in git-daemon inetd documentation examples.\n\n Eric Wong (1):\n git-svn: fix symlink-to-file changes when using command-line svn 1.4.0\n\n Gerrit Pape (1):\n Set $HOME for selftests\n\n J. Bruce Fields (1):\n Documentation: updates to \"Everyday GIT\"\n\n Jakub Narebski (4):\n gitweb: Get rid of git_print_simplified_log\n gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff\n gitweb: Print commit message without title in commitdiff only if there is any\n diff-format.txt: Combined diff format documentation supplement\n\n Junio C Hamano (20):\n Add git-for-each-ref: helper for language bindings\n gitweb: make leftmost column of blame less cluttered.\n gitweb: prepare for repositories with packed refs.\n Revert 954a6183756a073723a7c9fd8d2feb13132876b0\n blame.c: whitespace and formatting clean-up.\n git-blame: --show-name (and -f)\n git-blame: --show-number (and -n)\n blame.c: move code to output metainfo into a separate function.\n git-blame --porcelain\n gitweb: use blame --porcelain\n blame: Document and add help text for -f, -n, and -p\n gitweb: spell \"blame --porcelain\" with -p\n gitweb: use for-each-ref to show the latest activity across branches\n Documentation: note about contrib/.\n RPM package re-classification.\n Refer to git-rev-parse:Specifying Revisions from git.txt\n Update cherry documentation.\n Documentation/SubmittingPatches: 3+1 != 6\n Documentation: clarify refname disambiguation rules.\n combine-diff: a few more finishing touches.\n\n Luben Tuikov (3):\n gitweb: blame: print commit-8 on the leading row of a commit-block\n gitweb: blame: Mouse-over commit-8 shows author and date\n gitweb: blame porcelain: lineno and orig lineno swapped\n\n Petr Baudis (5):\n gitweb: Restore object-named links in item lists\n gitweb: Make search type a popup menu\n gitweb: Do not automatically append \" git\" to custom site name\n gitweb: Show project's README.html if available\n xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines\n\n Ryan Anderson (1):\n Remove git-annotate.perl and create a builtin-alias for git-blame\n\n Tuncer Ayaz (1):\n git-fetch.sh printed protocol fix\n\n\n* The 'next' branch, in addition, has these.\n\n The next series to graduate is Linus's \"packed-ref\" and\n associated changes, including rewrite of \"branch\" in C,\n perhaps early next week.\n\n Christian Couder (12):\n Add [-s|--hash] option to Linus' show-ref.\n Use Linus' show ref in \"git-branch.sh\".\n Document git-show-ref [-s|--hash] option.\n Fix show-ref usage for --dereference.\n Add pack-refs and show-ref test cases.\n When creating branch c/d check that branch c does not already exists.\n Uncomment test case: git branch c/d should barf if branch c exists.\n Fix a remove_empty_dir_recursive problem.\n Clean up \"git-branch.sh\" and add remove recursive dir test cases.\n Use git-update-ref to delete a tag instead of rm()ing the ref file.\n Check that a tag exists using show-ref instead of looking for the ref file.\n Do not create tag leading directories since git update-ref does it.\n\n Dennis Stosberg (2):\n lock_ref_sha1_basic does not remove empty directories on BSD\n Remove bashism from t3210-pack-refs.sh\n\n Jeff King (3):\n wt-status: use simplified resolve_ref to find current branch\n gitignore: git-pack-refs is a generated file.\n gitignore: git-show-ref is a generated file.\n\n Johannes Schindelin (2):\n Fix git-update-index --again\n show-branch: mark active branch with a '*' again\n\n Jonas Fonseca (1):\n Add man page for git-show-ref\n\n Junio C Hamano (47):\n upload-pack: stop the other side when they have more roots than we do.\n Fix t1400-update-ref test minimally\n fsck-objects: adjust to resolve_ref() clean-up.\n symbolit-ref: fix resolve_ref conversion.\n Add callback data to for_each_ref() family.\n Tell between packed, unpacked and symbolic refs.\n pack-refs: do not pack symbolic refs.\n git-pack-refs --prune\n pack-refs: fix git_path() usage.\n lock_ref_sha1_basic: remove unused parameter \"plen\".\n Clean-up lock-ref implementation\n update-ref: -d flag and ref creation safety.\n update a few Porcelain-ish for ref lock safety.\n Teach receive-pack about ref-log\n receive-pack: call setup_ident before git_config\n ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.\n refs: minor restructuring of cached refs data.\n lock_ref_sha1(): do not sometimes error() and sometimes die().\n lock_ref_sha1(): check D/F conflict with packed ref when creating.\n delete_ref(): delete packed ref\n git-branch: remove D/F check done by hand.\n show-ref --hash=len, --abbrev=len, and --abbrev\n git-fetch: adjust to packed-refs.\n Fix refs.c;:repack_without_ref() clean-up path\n git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.\n pack-refs: use lockfile as everybody else does.\n pack-refs: call fflush before fsync.\n ref-log: allow ref@{count} syntax.\n core.logallrefupdates create new log file only for branch heads.\n git-pack-refs --all\n core.logallrefupdates thinko-fix\n pack-objects: use of version 3 delta is now optional.\n Revert \"pack-objects: use of version 3 delta is now optional.\"\n ref-log: fix D/F conflict coming from deleted refs.\n git-pickaxe: blame rewritten.\n git-pickaxe -M: blame line movements within a file.\n git-pickaxe -C: blame cut-and-pasted lines.\n git-pickaxe: pagenate output by default.\n git-pickaxe: fix nth_line()\n git-pickaxe: improve \"best match\" heuristics\n git-pickaxe: introduce heuristics to avoid \"trivial\" chunks\n git-pickaxe: do not keep commit buffer.\n git-pickaxe: do not confuse two origins that are the same.\n git-pickaxe: get rid of wasteful find_origin().\n git-pickaxe: swap comparison loop used for -C\n sha1_name.c: avoid compilation warnings.\n t3200: git-branch testsuite update\n\n Lars Hjemli (1):\n Make git-branch a builtin\n\n Linus Torvalds (6):\n Add \"git show-ref\" builtin command\n Teach \"git checkout\" to use git-show-ref\n Start handling references internally as a sorted in-memory list\n Add support for negative refs\n Make ref resolution saner\n Enable the packed refs file format\n\n Luben Tuikov (1):\n git-revert with conflicts to behave as git-merge with conflicts\n\n Nicolas Pitre (1):\n enable index-pack streaming capability\n\n Petr Baudis (2):\n Fix broken sha1 locking\n Fix buggy ref recording\n\n Rene Scharfe (1):\n Built-in cherry\n\n\n* The 'pu' branch, in addition, has these.\n\n We'd still need more work on merge-recursive to fix the\n overcautious \"working file will be overwritten by merge\" --\n this is really needed for usability.\n\n The diff/apply change I am holding back is the one that\n appends an extra tab after \"---/+++\" filename to the diff\n output, when the filename has an embedded SP in it, to make it\n compatible with GNU diff. Updates to git-apply to understand\n the new output is already in \"master\" but not in 1.4.3 series,\n and until it propagates to majority of users, this change\n cannot be unleashed, in order to keep people with older git\n who use such a pathname happy.\n\n I did not hear any comments on the left-right stuff; perhaps\n it is not needed, or it is not useful as its current shape (it\n could be enhanced to say which starting commits each of the\n commit is reachable from, by borrowing much of show-branch\n code).\n\n I looked at Pasky's \"project forks\" gitweb code, and while I\n liked it a lot (having a demonstration site repo.or.cz really\n helps), I read on #git log that Pasky himself was having\n doubt, so it is parked in \"pu\", not in \"next\".\n\n Nico's 3-patch index-pack rework is quite nice; unfortunately\n the last one in the series seems to make the test fail so it\n is not included here, and I did not find enough time to see if\n the other two are \"next\" material. They are parked in \"pu\" in\n the meantime.\n\n Junio C Hamano (7):\n merge: loosen overcautious \"working file will be lost\" check.\n merge-recursive: use abbreviated commit object name.\n merge-recursive: make a few functions static.\n git-commit: show --summary after successful commit.\n para-walk: walk n trees, index and working tree in parallel\n git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)\n rev-list --left-right\n\n Nicolas Pitre (2):\n make index-pack able to complete thin packs.\n add progress status to index-pack\n\n Petr Baudis (1):\n gitweb: Support for 'forks'\n\n"},{"id":"295090","messageId":"ehpu4t$ch2$1@sea.gmane.org","threadId":"43164","inReplyTo":"7vk62npipb.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T09:12:36Z","receivedAt":"2006-10-26T09:12:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> * The 'master' branch has these since the last announcement.\n> \n> I've flushed all the 'gitweb/' changes from \"next\" and core\n> support that some of them needed; notably \"for-each-ref\" and\n> \"blame --porcelain\" is now in \"master\". Oh, and \"annotate\"\n> is now a mere synonym for \"blame -c\".\n[...]\n> Junio C Hamano (20):\n[...]\n> gitweb: prepare for repositories with packed refs.\n[...]\n> gitweb: use for-each-ref to show the latest activity across branches\n\nThis unfortunately means that I cannot test gitweb based on 'master'\nbranch using _released_ git core, git version 1.4.3.3, as it doesn't have\ngit-for-each-ref nor git-show-ref.\n\nBTW. do people often use latest gitweb with older git binaries? Should\nwe try to wait for core feature to mature to released version before using\nit in gitweb? Or perhaps we should add some kind of version checking, and\nprovide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support\n--git-dir option, pathlimit filtering using git-rev-list piped to \ngit-diff-tree --stdin in git_history if there is no --full-history\noption, show always HEAD activity if there is no git-for-each-ref\netc.; well the latest we can do without checking for git core version, just\n\n if -x qx($GIT --exec-path)/git-for-each-ref\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297044","messageId":"Pine.LNX.4.63.0610261114520.3286@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43164","inReplyTo":"7vk62npipb.fsf@assigned-by-dhcp.cox.net","subject":"merge-recursive, was Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-26T09:18:23Z","receivedAt":"2006-10-26T09:18:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 26 Oct 2006, Junio C Hamano wrote:\n\n> We'd still need more work on merge-recursive to fix the\n> overcautious \"working file will be overwritten by merge\" --\n> this is really needed for usability.\n\nI am sorry, but I do not have the time to wrap my head around this for at \nleast another week. It seems to be a complicated problem (not the fix, \nmind you, but the side effects you have to think of!), and I stupidly \nstarted to play with shallow clones when I knew I had no time already.\n\nBTW what happened to the builtin shortlog? It is the last Perl script I \nuse regularly... (should make people happy who are stuck with Activision \nPerl...)\n\nCiao,\nDscho\n"},{"id":"298313","messageId":"ehpuid$ch2$2@sea.gmane.org","threadId":"43164","inReplyTo":"7vk62npipb.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T09:19:49Z","receivedAt":"2006-10-26T09:19:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>   I did not hear any comments on the left-right stuff; perhaps\n>   it is not needed, or it is not useful as its current shape (it\n>   could be enhanced to say which starting commits each of the\n>   commit is reachable from, by borrowing much of show-branch\n>   code).\n\nIt looks reasonable, and useful.\n\n>   I looked at Pasky's \"project forks\" gitweb code, and while I\n>   liked it a lot (having a demonstration site repo.or.cz really\n>   helps), I read on #git log that Pasky himself was having\n>   doubt, so it is parked in \"pu\", not in \"next\".\n\nPerhaps that's for the best.\n\nBy the way, Pasky, where one can find your changes to gitweb?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298398","messageId":"7v7iynpgza.fsf@assigned-by-dhcp.cox.net","threadId":"43164","inReplyTo":"ehpu4t$ch2$1@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T09:24:25Z","receivedAt":"2006-10-26T09:24:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> I've flushed all the 'gitweb/' changes from \"next\" and core\n>> support that some of them needed; notably \"for-each-ref\" and\n>> \"blame --porcelain\" is now in \"master\". Oh, and \"annotate\"\n>> is now a mere synonym for \"blame -c\".\n>> gitweb: prepare for repositories with packed refs.\n>> gitweb: use for-each-ref to show the latest activity across branches\n>\n> This unfortunately means that I cannot test gitweb based on 'master'\n> branch using _released_ git core, git version 1.4.3.3, as it doesn't have\n> git-for-each-ref nor git-show-ref.\n\nAs long as \"master\" version of gitweb goes with \"master\" version\nof the core, I do not see it as a problem. Otherwise how would\nyou make any progress?\n\n> ... Should\n> we try to wait for core feature to mature to released version before using\n> it in gitweb?\n\nThat's both insulting and inconsistent.\n\nInsulting in that somehow you seem to feel \"master\" is lessor\nquality than \"maint\", and inconsistent in that you seem to find\n\"gitweb\" is somehow more special than other scripts we ship as\npart of the git.git project sources.\n\nAnyhow, I have done my fair share of git hacking for the week,\nso I'll stop venting and go to bed.\n"},{"id":"296152","messageId":"ehputm$ch2$3@sea.gmane.org","threadId":"43164","inReplyTo":"Pine.LNX.4.63.0610261114520.3286@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: merge-recursive, was Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T09:25:50Z","receivedAt":"2006-10-26T09:25:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> BTW what happened to the builtin shortlog? It is the last Perl script I \n> use regularly... (should make people happy who are stuck with Activision \n> Perl...)\n\nBTW. both Perl version and builtin shorlog have email->real name translation\ntable built in. In Perl script version it is in __DATA__ section, and we\ncould update it using Inline::Files module, in C version it was in table.\nBut in fact this list is project specific. Shouldn't we make it customizable\n(::sigh::, yet another file in $GIT_DIR...).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298595","messageId":"7v3b9bpgvs.fsf@assigned-by-dhcp.cox.net","threadId":"43164","inReplyTo":"Pine.LNX.4.63.0610261114520.3286@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: merge-recursive, was Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T09:26:31Z","receivedAt":"2006-10-26T09:26:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 26 Oct 2006, Junio C Hamano wrote:\n>\n>> We'd still need more work on merge-recursive to fix the\n>> overcautious \"working file will be overwritten by merge\" --\n>> this is really needed for usability.\n>\n> I am sorry, but I do not have the time to wrap my head around this for at \n> least another week. It seems to be a complicated problem (not the fix, \n> mind you, but the side effects you have to think of!), and I stupidly \n> started to play with shallow clones when I knew I had no time already.\n\nNo need to worry nor feel pressure; it's all volunteer work and\nwe do this for fun.\n\n> BTW what happened to the builtin shortlog? It is the last Perl script I \n> use regularly... (should make people happy who are stuck with Activision \n> Perl...)\n\nYeah, I was wondering about it too, when I was looking for\nsomething readily mergeable to \"next\" today. I must have\nmisplaced it.\n\n"},{"id":"298697","messageId":"7vlkn3o1w1.fsf@assigned-by-dhcp.cox.net","threadId":"43164","inReplyTo":"ehputm$ch2$3@sea.gmane.org","subject":"Re: merge-recursive, was Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T09:35:42Z","receivedAt":"2006-10-26T09:35:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Johannes Schindelin wrote:\n>\n>> BTW what happened to the builtin shortlog? It is the last Perl script I \n>> use regularly... (should make people happy who are stuck with Activision \n>> Perl...)\n>\n> BTW. both Perl version and builtin shorlog have email->real name translation\n> table built in. In Perl script version it is in __DATA__ section, and we\n> could update it using Inline::Files module, in C version it was in table.\n> But in fact this list is project specific. Shouldn't we make it customizable\n> (::sigh::, yet another file in $GIT_DIR...).\n\nIt already reads from .mailmap which could be tracked as part of\nthe sources (if it is project specific it would be better if it\ncan be shared among members).\n"},{"id":"294892","messageId":"ehq06d$i44$1@sea.gmane.org","threadId":"43164","inReplyTo":"7vlkn3o1w1.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge-recursive, was Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T09:47:34Z","receivedAt":"2006-10-26T09:47:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> BTW. both Perl version and builtin shorlog have email->real name translation\n>> table built in. In Perl script version it is in __DATA__ section, and we\n>> could update it using Inline::Files module, in C version it was in table.\n>> But in fact this list is project specific. Shouldn't we make it customizable\n>> (::sigh::, yet another file in $GIT_DIR...).\n> \n> It already reads from .mailmap which could be tracked as part of\n> the sources (if it is project specific it would be better if it\n> can be shared among members).\n\nBy the way, if I read code correctly, it read '.mailmap' from _current_\ndirectory. Shouldn't it read qx(git-rev-parse --show-cdup)/.mailmap ?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297952","messageId":"7v7iyno0qk.fsf@assigned-by-dhcp.cox.net","threadId":"43164","inReplyTo":"7v3b9bpgvs.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge-recursive, was Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T10:00:35Z","receivedAt":"2006-10-26T10:00:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> BTW what happened to the builtin shortlog? It is the last Perl script I \n>> use regularly... (should make people happy who are stuck with Activision \n>> Perl...)\n>\n> Yeah, I was wondering about it too, when I was looking for\n> something readily mergeable to \"next\" today. I must have\n> misplaced it.\n\nI looked at the code again.\n\nThis is a prime demonstration that it makes more sense to keep\nscript version until we flush out configurability issues.\n\nThe built-in mailmap list is easily overridden with \".mailmap\"\nwhich presumably projects would want to keep under version\ncontrol, so it is less of an issue, but not everybody would\nnecessarily want to name that file \".mailmap\".\n\nThere is a \"dot3\" merge source shortening logic that is very\nspecific to the kernel, and this cannot be customized per\nproject. If it were kept as Perl script, each project could\nlimp along with a copy of this script, modified for their needs,\nwithout making the script itself customizable. Rewriting it\ninto C does not _forbid_ that kind of use, but certainly it\nmakes it more cumbersome to do so.\n\nFirst I'd probably ask kernel folks to maintain their own\ncopy of .mailmap at the toplevel of their source tree, so that\nwe can remove this kernel specific built-in mailmap from\nshortlog (I'd even do so before switching from the Perl\nversion).\n\nThe dot3 logic is probably best substituted with config, a\nversion controllable file similar to .mailmap, or command line\nparameters, but I am not sure which one is the best way to go.\nWhatever mechanism is used, It essentially is to define a\nmapping from a long string to its abbreviation (currently there\nis one hardcoded one, that replaces /pub/scm/linux/kernel/git/\nto /.../), to be applied to the first line of log message body.\nPresumably other projects could have more than one \"popular\"\nprefixes that appear often, so (if we take command line\napproach, which I think is the worst of the three possibilities)\nthe \"slightly more generalized\" version would look something\nlike this perhaps?\n\n git-shortlog --mailmapfile=.mailmap \\\n \t--abbrev=/pub/scm/linux/kernel/git/,/.../ \\\n --abbrev=/pub/scm/,/.../../\n\nWe could even define the --abbrev stuff as 's/from/to/' but that\nwould make it harder for us to shake Perl off, and in practice\nthis is to shorten the merge source repository name, so\ndeliberately limiting its feature to simple string replace like\nthe above might make more sense.\n\n\n"},{"id":"293961","messageId":"Pine.LNX.4.63.0610261252480.3286@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43164","inReplyTo":"7v7iyno0qk.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge-recursive, was Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-26T10:56:26Z","receivedAt":"2006-10-26T10:56:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 26 Oct 2006, Junio C Hamano wrote:\n\n> This is a prime demonstration that it makes more sense to keep script \n> version until we flush out configurability issues.\n\nOkay, I agree.\n\nBTW before somebody asks: No, I did _not_ implement the .mailmap \nfunctionality. But once things are flushed out with the configuration, and \n_if_ the builtin is not undesired, I will implement it.\n\nSince Linux really is a special guest, maybe we'd want to integrate the \ndot3 thing in .mailmap, and override the Linux defaults _only_ if .mailmap \nexists. Thoughts?\n\nCiao,\nDscho\n"},{"id":"296959","messageId":"45409D79.8010909@op5.se","threadId":"43164","inReplyTo":"Pine.LNX.4.63.0610261114520.3286@wbgn013.biozentrum.uni-wuerzburg.de","subject":"shortlog, was Re: merge-recursive, was Re: What's in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-26T11:35:21Z","receivedAt":"2006-10-26T11:35:21Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> \n> BTW what happened to the builtin shortlog? It is the last Perl script I \n> use regularly... (should make people happy who are stuck with Activision \n> Perl...)\n> \n\nI keep writing\n\tgit log --short\n\nwhen I really want\n\tgit log --pretty=short | git shortlog\n\n\nI'll have a look at making it work if I get a spare moment.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"295492","messageId":"20061026120824.GO20017@pasky.or.cz","threadId":"43164","inReplyTo":"ehpu4t$ch2$1@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-26T12:08:24Z","receivedAt":"2006-10-26T12:08:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter\nwhere Jakub Narebski said that...\n> This unfortunately means that I cannot test gitweb based on 'master'\n> branch using _released_ git core, git version 1.4.3.3, as it doesn't have\n> git-for-each-ref nor git-show-ref.\n> \n> BTW. do people often use latest gitweb with older git binaries? Should\n> we try to wait for core feature to mature to released version before using\n> it in gitweb? Or perhaps we should add some kind of version checking, and\n> provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support\n> --git-dir option, pathlimit filtering using git-rev-list piped to \n> git-diff-tree --stdin in git_history if there is no --full-history\n> option, show always HEAD activity if there is no git-for-each-ref\n> etc.; well the latest we can do without checking for git core version, just\n> \n> if -x qx($GIT --exec-path)/git-for-each-ref\n\nI can't imagine a situation where you would _want_ to use latest gitweb\nbut refuse to use older git binaries - can you explain why do you want\nto do that?\n\nIf you don't want to install the latest master systemwide, that's\nreasonable, but you can just keep the latest master for the gitweb\nscript and/or your personal use.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter\n> where Jakub Narebski said that...\n>> This unfortunately means that I cannot test gitweb based on 'master'\n>> branch using _released_ git core, git version 1.4.3.3, as it doesn't have\n>> git-for-each-ref nor git-show-ref.\n>> \n>> BTW. do people often use latest gitweb with older git binaries? Should\n>> we try to wait for core feature to mature to released version before using\n>> it in gitweb? Or perhaps we should add some kind of version checking, and\n>> provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support\n>> --git-dir option, pathlimit filtering using git-rev-list piped to \n>> git-diff-tree --stdin in git_history if there is no --full-history\n>> option, show always HEAD activity if there is no git-for-each-ref\n>> etc.; well the latest we can do without checking for git core version, just\n>> \n>> if -x qx($GIT --exec-path)/git-for-each-ref\n> \n> I can't imagine a situation where you would _want_ to use latest gitweb\n> but refuse to use older git binaries - can you explain why do you want\n> to do that?\n\nTheoretically? I could have Perl installed, have installed tools Git\nrequires to use but not have installed tools Git require to compile.\nHence forced to use pre-compiled binaries.\n \nBut that is not my situation.\n\n> If you don't want to install the latest master systemwide, that's\n> reasonable, but you can just keep the latest master for the gitweb\n> script and/or your personal use.\n\nWell, I'd use compiled 'master' version of git for gitweb, then...\n-- \nJakub Narebski\n"},{"id":"294228","messageId":"20061026122248.GP20017@pasky.or.cz","threadId":"43164","inReplyTo":"7vk62npipb.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-26T12:22:48Z","receivedAt":"2006-10-26T12:22:48Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 26, 2006 at 10:47:12AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> gitweb: use for-each-ref to show the latest activity across branches\n\nIt's a pity that for-each-ref is used only for that, I'd appreciate a\nlot if git_get_refs_list() could use it too, for the sake of\nrepo.or.cz:glibc-cvs.git summary view, which is massive. :-)\n\n> I looked at Pasky's \"project forks\" gitweb code, and while I\n> liked it a lot (having a demonstration site repo.or.cz really\n> helps), I read on #git log that Pasky himself was having\n> doubt, so it is parked in \"pu\", not in \"next\".\n\nI had doubts in the middle of implementing it, but now I don't - for\nsummary of why, please see\n\n\thttp://news.gmane.org/find-root.php?message_id=<20061024173943.GF20017@pasky.or.cz>\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> Johannes Schindelin wrote:\n> \n> > BTW what happened to the builtin shortlog? It is the last Perl script I \n> > use regularly... (should make people happy who are stuck with Activision \n> > Perl...)\n> \n> BTW. both Perl version and builtin shorlog have email->real name translation\n> table built in. In Perl script version it is in __DATA__ section, and we\n> could update it using Inline::Files module, in C version it was in table.\n> But in fact this list is project specific. Shouldn't we make it customizable\n> (::sigh::, yet another file in $GIT_DIR...).\n\nI really dislike the fact that we _do_ this mapping at all, this seems\nso much a totally wrong point at which to do it. The information tracked\nin Git is still wrong and all the tools except shortlog still display it\nwrong - why should shortlog in particular be special? Why don't we do\nthis at the git-am time instead?\n\nAnd overally, things would be simpler if people would just require the\nauthor name to be recorded in the mail properly when applying the patch;\nAIUI at least in case of the kernel this mapping shouldn't really be\nneeded anymore anyway since with the signoff protocol, you already\nrequire all the contributors to reveal their realnames in signoffs?\nPeople can then as well just write that in their from headers as well.\nLinus?\n\nSo what about making git-am by default refuse to apply patches with\nmissing author realnames?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i I think I've complained about this in the past, but can't find the mail.\n> \n> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter\n> where Jakub Narebski said that...\n>> Johannes Schindelin wrote:\n>> \n>> > BTW what happened to the builtin shortlog? It is the last Perl script I \n>> > use regularly... (should make people happy who are stuck with Activision \n>> > Perl...)\n>> \n>> BTW. both Perl version and builtin shorlog have email->real name translation\n>> table built in. In Perl script version it is in __DATA__ section, and we\n>> could update it using Inline::Files module, in C version it was in table.\n>> But in fact this list is project specific. Shouldn't we make it customizable\n>> (::sigh::, yet another file in $GIT_DIR...).\n> \n> I really dislike the fact that we _do_ this mapping at all, this seems\n> so much a totally wrong point at which to do it. The information tracked\n> in Git is still wrong and all the tools except shortlog still display it\n> wrong - why should shortlog in particular be special? Why don't we do\n> this at the git-am time instead?\n\nBecause git-shortlog has to deal also with _historical_ data, which caused\none way or the other to have only email and not realname recorded. So till\nhistory gets rewritteen, and tags resigned, git-shortlog has to do the\nmapping to have meaningfull output.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"293953","messageId":"4540AD6E.6070201@op5.se","threadId":"43164","inReplyTo":"ehqaco$r4l$1@sea.gmane.org","subject":"Re: git-shortlog mailmap","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-26T12:43:26Z","receivedAt":"2006-10-26T12:43:26Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> Petr Baudis wrote:\n> \n>> I think I've complained about this in the past, but can't find the mail.\n>>\n>> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter\n>> where Jakub Narebski said that...\n>>> Johannes Schindelin wrote:\n>>>\n>>>> BTW what happened to the builtin shortlog? It is the last Perl script I \n>>>> use regularly... (should make people happy who are stuck with Activision \n>>>> Perl...)\n>>> BTW. both Perl version and builtin shorlog have email->real name translation\n>>> table built in. In Perl script version it is in __DATA__ section, and we\n>>> could update it using Inline::Files module, in C version it was in table.\n>>> But in fact this list is project specific. Shouldn't we make it customizable\n>>> (::sigh::, yet another file in $GIT_DIR...).\n>> I really dislike the fact that we _do_ this mapping at all, this seems\n>> so much a totally wrong point at which to do it. The information tracked\n>> in Git is still wrong and all the tools except shortlog still display it\n>> wrong - why should shortlog in particular be special? Why don't we do\n>> this at the git-am time instead?\n> \n> Because git-shortlog has to deal also with _historical_ data, which caused\n> one way or the other to have only email and not realname recorded. So till\n> history gets rewritteen, and tags resigned, git-shortlog has to do the\n> mapping to have meaningfull output.\n\nWouldn't this be better implemented in the rev-list code then, so all \nlog viewers can benefit from it?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"295985","messageId":"ehqc8r$2nc$1@sea.gmane.org","threadId":"43164","inReplyTo":"4540AD6E.6070201@op5.se","subject":"Re: git-shortlog mailmap","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T13:13:40Z","receivedAt":"2006-10-26T13:13:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> Jakub Narebski wrote:\n>> Petr Baudis wrote:\n>>>\n>>> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter\n>>> where Jakub Narebski said that...\n>>>>\n>>>> BTW. both Perl version and builtin shorlog have email->real name translation\n>>>> table built in. In Perl script version it is in __DATA__ section, and we\n>>>> could update it using Inline::Files module, in C version it was in table.\n>>>> But in fact this list is project specific. Shouldn't we make it customizable\n>>>> (::sigh::, yet another file in $GIT_DIR...).\n>>>>\n>>> I really dislike the fact that we _do_ this mapping at all, this seems\n>>> so much a totally wrong point at which to do it. The information tracked\n>>> in Git is still wrong and all the tools except shortlog still display it\n>>> wrong - why should shortlog in particular be special? Why don't we do\n>>> this at the git-am time instead?\n>> \n>> Because git-shortlog has to deal also with _historical_ data, which caused\n>> one way or the other to have only email and not realname recorded. So till\n>> history gets rewritteen, and tags resigned, git-shortlog has to do the\n>> mapping to have meaningfull output.\n> \n> Wouldn't this be better implemented in the rev-list code then, so all \n> log viewers can benefit from it?\n\nBecause this belongs to porcelain. Plumbing shouldn't show something\nthat isn't there.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294146","messageId":"Pine.LNX.4.63.0610261514160.3286@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43164","inReplyTo":"ehqc8r$2nc$1@sea.gmane.org","subject":"Re: git-shortlog mailmap","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-26T13:16:00Z","receivedAt":"2006-10-26T13:16:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 26 Oct 2006, Jakub Narebski wrote:\n\n> Andreas Ericsson wrote:\n> \n> > Wouldn't this be better implemented in the rev-list code then, so all \n> > log viewers can benefit from it?\n> \n> Because this belongs to porcelain. Plumbing shouldn't show something\n> that isn't there.\n\nActually, I think it would make sense. Since log viewers are \nporcelain-ish, they could transform the author/committer data according \nto .mailmap. Of course, that means that if two people have different \nmailmaps, they have to be aware of that fact when disagreeing over some \nauthorship.\n\nCiao,\nDscho\n"},{"id":"296483","messageId":"Pine.LNX.4.64.0610260921550.12418@xanadu.home","threadId":"43164","inReplyTo":"7vlkn3o1w1.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge-recursive, was Re: What's in git.git","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-26T13:23:28Z","receivedAt":"2006-10-26T13:23:28Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 26 Oct 2006, Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n> > Johannes Schindelin wrote:\n> >\n> >> BTW what happened to the builtin shortlog? It is the last Perl script I \n> >> use regularly... (should make people happy who are stuck with Activision \n> >> Perl...)\n> >\n> > BTW. both Perl version and builtin shorlog have email->real name translation\n> > table built in. In Perl script version it is in __DATA__ section, and we\n> > could update it using Inline::Files module, in C version it was in table.\n> > But in fact this list is project specific. Shouldn't we make it customizable\n> > (::sigh::, yet another file in $GIT_DIR...).\n> \n> It already reads from .mailmap which could be tracked as part of\n> the sources (if it is project specific it would be better if it\n> can be shared among members).\n\nThe C version was missing that support if I remember right.\n\nActually I think that the email table should be removed out of the tool \nentirely and always read from .mailmap instead.\n\n\n"},{"id":"294767","messageId":"20061026132922.GR20017@pasky.or.cz","threadId":"43164","inReplyTo":"ehqaco$r4l$1@sea.gmane.org","subject":"Re: git-shortlog mailmap","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-26T13:29:22Z","receivedAt":"2006-10-26T13:29:22Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 26, 2006 at 02:41:38PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Because git-shortlog has to deal also with _historical_ data, which caused\n> one way or the other to have only email and not realname recorded.\n\nWhen does it in practice have to deal also with historical data, these\ndays?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i I keep writing\n> \tgit log --short\n> \n> when I really want\n> \tgit log --pretty=short | git shortlog\n> \n> \n> I'll have a look at making it work if I get a spare moment.\n\nWhy don't you simply drop the --pretty=short altogether?\n\n\tgit log | git shortlog\n\n\n"},{"id":"293964","messageId":"4540BBDF.1020204@op5.se","threadId":"43164","inReplyTo":"Pine.LNX.4.64.0610260937070.12418@xanadu.home","subject":"Re: shortlog, was Re: merge-recursive, was Re: What's in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-26T13:45:03Z","receivedAt":"2006-10-26T13:45:03Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n> On Thu, 26 Oct 2006, Andreas Ericsson wrote:\n> \n>> I keep writing\n>> \tgit log --short\n>>\n>> when I really want\n>> \tgit log --pretty=short | git shortlog\n>>\n>>\n>> I'll have a look at making it work if I get a spare moment.\n> \n> Why don't you simply drop the --pretty=short altogether?\n> \n> \tgit log | git shortlog\n> \n\nDunno. Mainly because I saw the \"git log --pretty=short | git shortlog\" \nconstruct somewhere, I guess. Either way, it would make more sense to \nhave it as --pretty=by-author or something like that instead.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294398","messageId":"4540F00B.9070504@shadowen.org","threadId":"43164","inReplyTo":"7vk62npipb.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-10-26T17:27:39Z","receivedAt":"2006-10-26T17:27:39Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n> I did not hear any comments on the left-right stuff; perhaps\n> it is not needed, or it is not useful as its current shape (it\n> could be enhanced to say which starting commits each of the\n> commit is reachable from, by borrowing much of show-branch\n> code).\n\nThat was the stuff which kinda did cherry in rev-list. It seemed to\nproduce interesting output, but nothing I couldn't do with cherry.\nStill interesting tho. The sort of thing that if it was in there\nsomeone would find a use for, think lazers.\n\n"},{"id":"294308","messageId":"20061027011054.GT20017@pasky.or.cz","threadId":"43164","inReplyTo":"ehpuid$ch2$2@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-27T01:10:54Z","receivedAt":"2006-10-27T01:10:54Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 26, 2006 at 11:19:49AM CEST, I got a letter\nwhere Jakub Narebski said that...\n> By the way, Pasky, where one can find your changes to gitweb?\n\nhttp://repo.or.cz/w/git/repo.git\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i