threads / discuss / 43164

Re: git-shortlog mailmap

Subject: Re: git-shortlog mailmap

## tl;dr

26 messages between Oct 26, 2006 and Oct 27, 2006.

replies: 25people: 7as markdown or json

Junio C Hamano· Oct 26, 2006, 08:47 UTC · lore

What's in git.git

* The 'maint' branch has produced 1.4.3.3 and has these fixes
  since the last announcement (some of them are post 1.4.3.3).
   Christian Couder (1):
      Remove --syslog in git-daemon inetd documentation examples.
   Eric Wong (1):
      git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
   Gerrit Pape (1):
      Set $HOME for selftests
   J. Bruce Fields (1):
      Documentation: updates to "Everyday GIT"
   Jakub Narebski (1):
      diff-format.txt: Combined diff format documentation supplement
   Junio C Hamano (6):
      Documentation: note about contrib/.
      RPM package re-classification.
      Refer to git-rev-parse:Specifying Revisions from git.txt
      Update cherry documentation.
      Documentation/SubmittingPatches: 3+1 != 6
      Documentation: clarify refname disambiguation rules.
   Petr Baudis (1):
      xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
   Tuncer Ayaz (1):
      git-fetch.sh printed protocol fix
* The 'master' branch has these since the last announcement.
  I've flushed all the 'gitweb/' changes from "next" and core
  support that some of them needed; notably "for-each-ref" and
  "blame --porcelain" is now in "master".  Oh, and "annotate"
  is now a mere synonym for "blame -c".
   Alan Chandler (1):
      Gitweb - provide site headers and footers
   Andy Whitcroft (2):
      cvsimport: move over to using git-for-each-ref to read refs.
      git-for-each-ref: improve the documentation on scripting modes
   Christian Couder (1):
      Remove --syslog in git-daemon inetd documentation examples.
   Eric Wong (1):
      git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
   Gerrit Pape (1):
      Set $HOME for selftests
   J. Bruce Fields (1):
      Documentation: updates to "Everyday GIT"
   Jakub Narebski (4):
      gitweb: Get rid of git_print_simplified_log
      gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
      gitweb: Print commit message without title in commitdiff only if there is any
      diff-format.txt: Combined diff format documentation supplement
   Junio C Hamano (20):
      Add git-for-each-ref: helper for language bindings
      gitweb: make leftmost column of blame less cluttered.
      gitweb: prepare for repositories with packed refs.
      Revert 954a6183756a073723a7c9fd8d2feb13132876b0
      blame.c: whitespace and formatting clean-up.
      git-blame: --show-name (and -f)
      git-blame: --show-number (and -n)
      blame.c: move code to output metainfo into a separate function.
      git-blame --porcelain
      gitweb: use blame --porcelain
      blame: Document and add help text for -f, -n, and -p
      gitweb: spell "blame --porcelain" with -p
      gitweb: use for-each-ref to show the latest activity across branches
      Documentation: note about contrib/.
      RPM package re-classification.
      Refer to git-rev-parse:Specifying Revisions from git.txt
      Update cherry documentation.
      Documentation/SubmittingPatches: 3+1 != 6
      Documentation: clarify refname disambiguation rules.
      combine-diff: a few more finishing touches.
   Luben Tuikov (3):
      gitweb: blame: print commit-8 on the leading row of a commit-block
      gitweb: blame: Mouse-over commit-8 shows author and date
      gitweb: blame porcelain: lineno and orig lineno swapped
   Petr Baudis (5):
      gitweb: Restore object-named links in item lists
      gitweb: Make search type a popup menu
      gitweb: Do not automatically append " git" to custom site name
      gitweb: Show project's README.html if available
      xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
   Ryan Anderson (1):
      Remove git-annotate.perl and create a builtin-alias for git-blame
   Tuncer Ayaz (1):
      git-fetch.sh printed protocol fix
* The 'next' branch, in addition, has these.
  The next series to graduate is Linus's "packed-ref" and
  associated changes, including rewrite of "branch" in C,
  perhaps early next week.
   Christian Couder (12):
      Add [-s|--hash] option to Linus' show-ref.
      Use Linus' show ref in "git-branch.sh".
      Document git-show-ref [-s|--hash] option.
      Fix show-ref usage for --dereference.
      Add pack-refs and show-ref test cases.
      When creating branch c/d check that branch c does not already exists.
      Uncomment test case: git branch c/d should barf if branch c exists.
      Fix a remove_empty_dir_recursive problem.
      Clean up "git-branch.sh" and add remove recursive dir test cases.
      Use git-update-ref to delete a tag instead of rm()ing the ref file.
      Check that a tag exists using show-ref instead of looking for the ref file.
      Do not create tag leading directories since git update-ref does it.
   Dennis Stosberg (2):
      lock_ref_sha1_basic does not remove empty directories on BSD
      Remove bashism from t3210-pack-refs.sh
   Jeff King (3):
      wt-status: use simplified resolve_ref to find current branch
      gitignore: git-pack-refs is a generated file.
      gitignore: git-show-ref is a generated file.
   Johannes Schindelin (2):
      Fix git-update-index --again
      show-branch: mark active branch with a '*' again
   Jonas Fonseca (1):
      Add man page for git-show-ref
   Junio C Hamano (47):
      upload-pack: stop the other side when they have more roots than we do.
      Fix t1400-update-ref test minimally
      fsck-objects: adjust to resolve_ref() clean-up.
      symbolit-ref: fix resolve_ref conversion.
      Add callback data to for_each_ref() family.
      Tell between packed, unpacked and symbolic refs.
      pack-refs: do not pack symbolic refs.
      git-pack-refs --prune
      pack-refs: fix git_path() usage.
      lock_ref_sha1_basic: remove unused parameter "plen".
      Clean-up lock-ref implementation
      update-ref: -d flag and ref creation safety.
      update a few Porcelain-ish for ref lock safety.
      Teach receive-pack about ref-log
      receive-pack: call setup_ident before git_config
      ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
      refs: minor restructuring of cached refs data.
      lock_ref_sha1(): do not sometimes error() and sometimes die().
      lock_ref_sha1(): check D/F conflict with packed ref when creating.
      delete_ref(): delete packed ref
      git-branch: remove D/F check done by hand.
      show-ref --hash=len, --abbrev=len, and --abbrev
      git-fetch: adjust to packed-refs.
      Fix refs.c;:repack_without_ref() clean-up path
      git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
      pack-refs: use lockfile as everybody else does.
      pack-refs: call fflush before fsync.
      ref-log: allow ref@{count} syntax.
      core.logallrefupdates create new log file only for branch heads.
      git-pack-refs --all
      core.logallrefupdates thinko-fix
      pack-objects: use of version 3 delta is now optional.
      Revert "pack-objects: use of version 3 delta is now optional."
      ref-log: fix D/F conflict coming from deleted refs.
      git-pickaxe: blame rewritten.
      git-pickaxe -M: blame line movements within a file.
      git-pickaxe -C: blame cut-and-pasted lines.
      git-pickaxe: pagenate output by default.
      git-pickaxe: fix nth_line()
      git-pickaxe: improve "best match" heuristics
      git-pickaxe: introduce heuristics to avoid "trivial" chunks
      git-pickaxe: do not keep commit buffer.
      git-pickaxe: do not confuse two origins that are the same.
      git-pickaxe: get rid of wasteful find_origin().
      git-pickaxe: swap comparison loop used for -C
      sha1_name.c: avoid compilation warnings.
      t3200: git-branch testsuite update
   Lars Hjemli (1):
      Make git-branch a builtin
   Linus Torvalds (6):
      Add "git show-ref" builtin command
      Teach "git checkout" to use git-show-ref
      Start handling references internally as a sorted in-memory list
      Add support for negative refs
      Make ref resolution saner
      Enable the packed refs file format
   Luben Tuikov (1):
      git-revert with conflicts to behave as git-merge with conflicts
   Nicolas Pitre (1):
      enable index-pack streaming capability
   Petr Baudis (2):
      Fix broken sha1 locking
      Fix buggy ref recording
   Rene Scharfe (1):
      Built-in cherry
* The 'pu' branch, in addition, has these.
  We'd still need more work on merge-recursive to fix the
  overcautious "working file will be overwritten by merge" --
  this is really needed for usability.
  The diff/apply change I am holding back is the one that
  appends an extra tab after "---/+++" filename to the diff
  output, when the filename has an embedded SP in it, to make it
  compatible with GNU diff.  Updates to git-apply to understand
  the new output is already in "master" but not in 1.4.3 series,
  and until it propagates to majority of users, this change
  cannot be unleashed, in order to keep people with older git
  who use such a pathname happy.
  I did not hear any comments on the left-right stuff; perhaps
  it is not needed, or it is not useful as its current shape (it
  could be enhanced to say which starting commits each of the
  commit is reachable from, by borrowing much of show-branch
  code).
  I looked at Pasky's "project forks" gitweb code, and while I
  liked it a lot (having a demonstration site repo.or.cz really
  helps), I read on #git log that Pasky himself was having
  doubt, so it is parked in "pu", not in "next".
  Nico's 3-patch index-pack rework is quite nice; unfortunately
  the last one in the series seems to make the test fail so it
  is not included here, and I did not find enough time to see if
  the other two are "next" material.  They are parked in "pu" in
  the meantime.
   Junio C Hamano (7):
      merge: loosen overcautious "working file will be lost" check.
      merge-recursive: use abbreviated commit object name.
      merge-recursive: make a few functions static.
      git-commit: show --summary after successful commit.
      para-walk: walk n trees, index and working tree in parallel
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      rev-list --left-right
   Nicolas Pitre (2):
      make index-pack able to complete thin packs.
      add progress status to index-pack
   Petr Baudis (1):
      gitweb: Support for 'forks'
Jakub Narebski· Oct 26, 2006, 09:12 UTC · re: Junio C Hamano · lore

Re: What's in git.git

Junio C Hamano wrote:
Show 6 quoted lines
> * The 'master' branch has these since the last announcement.
> 
>   I've flushed all the 'gitweb/' changes from "next" and core
>   support that some of them needed; notably "for-each-ref" and
>   "blame --porcelain" is now in "master".  Oh, and "annotate"
>   is now a mere synonym for "blame -c".
[...]
>    Junio C Hamano (20):
[...]
>       gitweb: prepare for repositories with packed refs.
[...]
>       gitweb: use for-each-ref to show the latest activity across branches

This unfortunately means that I cannot test gitweb based on 'master' branch using _released_ git core, git version 1.4.3.3, as it doesn't have git-for-each-ref nor git-show-ref.

BTW. do people often use latest gitweb with older git binaries? Should we try to wait for core feature to mature to released version before using it in gitweb? Or perhaps we should add some kind of version checking, and provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support --git-dir option, pathlimit filtering using git-rev-list piped to git-diff-tree --stdin in git_history if there is no --full-history option, show always HEAD activity if there is no git-for-each-ref etc.; well the latest we can do without checking for git core version, just

        if -x qx($GIT --exec-path)/git-for-each-ref
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Junio C Hamano· Oct 26, 2006, 09:24 UTC · re: Jakub Narebski · lore

Re: What's in git.git

Jakub Narebski <jnareb@gmail.com> writes:
Show 12 quoted lines
> Junio C Hamano wrote:
>
>>   I've flushed all the 'gitweb/' changes from "next" and core
>>   support that some of them needed; notably "for-each-ref" and
>>   "blame --porcelain" is now in "master".  Oh, and "annotate"
>>   is now a mere synonym for "blame -c".
>>       gitweb: prepare for repositories with packed refs.
>>       gitweb: use for-each-ref to show the latest activity across branches
>
> This unfortunately means that I cannot test gitweb based on 'master'
> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
> git-for-each-ref nor git-show-ref.

As long as "master" version of gitweb goes with "master" version of the core, I do not see it as a problem. Otherwise how would you make any progress?

> ... Should
> we try to wait for core feature to mature to released version before using
> it in gitweb?
That's both insulting and inconsistent.

Insulting in that somehow you seem to feel "master" is lessor quality than "maint", and inconsistent in that you seem to find "gitweb" is somehow more special than other scripts we ship as part of the git.git project sources.

Anyhow, I have done my fair share of git hacking for the week, so I'll stop venting and go to bed.

Petr Baudis· Oct 26, 2006, 12:08 UTC · re: Jakub Narebski · lore

Re: What's in git.git

Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter where Jakub Narebski <jnareb@gmail.com> said that...

Show 14 quoted lines
> This unfortunately means that I cannot test gitweb based on 'master'
> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
> git-for-each-ref nor git-show-ref.
> 
> BTW. do people often use latest gitweb with older git binaries? Should
> we try to wait for core feature to mature to released version before using
> it in gitweb? Or perhaps we should add some kind of version checking, and
> provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support
> --git-dir option, pathlimit filtering using git-rev-list piped to 
> git-diff-tree --stdin in git_history if there is no --full-history
> option, show always HEAD activity if there is no git-for-each-ref
> etc.; well the latest we can do without checking for git core version, just
> 
>         if -x qx($GIT --exec-path)/git-for-each-ref

I can't imagine a situation where you would _want_ to use latest gitweb but refuse to use older git binaries - can you explain why do you want to do that?

If you don't want to install the latest master systemwide, that's reasonable, but you can just keep the latest master for the gitweb script and/or your personal use.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
Jakub Narebski· Oct 26, 2006, 12:17 UTC · re: Petr Baudis · lore

Re: What's in git.git

Dnia czwartek 26. października 2006 14:08, Petr Baudis napisał:
Show 20 quoted lines
> Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> This unfortunately means that I cannot test gitweb based on 'master'
>> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
>> git-for-each-ref nor git-show-ref.
>> 
>> BTW. do people often use latest gitweb with older git binaries? Should
>> we try to wait for core feature to mature to released version before using
>> it in gitweb? Or perhaps we should add some kind of version checking, and
>> provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support
>> --git-dir option, pathlimit filtering using git-rev-list piped to 
>> git-diff-tree --stdin in git_history if there is no --full-history
>> option, show always HEAD activity if there is no git-for-each-ref
>> etc.; well the latest we can do without checking for git core version, just
>> 
>>         if -x qx($GIT --exec-path)/git-for-each-ref
> 
> I can't imagine a situation where you would _want_ to use latest gitweb
> but refuse to use older git binaries - can you explain why do you want
> to do that?
Theoretically? I could have Perl installed, have installed tools Git
requires to use but not have installed tools Git require to compile.
Hence forced to use pre-compiled binaries.
 
But that is not my situation.
> If you don't want to install the latest master systemwide, that's
> reasonable, but you can just keep the latest master for the gitweb
> script and/or your personal use.
Well, I'd use compiled 'master' version of git for gitweb, then...
-- 
Jakub Narebski
Johannes Schindelin· Oct 26, 2006, 09:18 UTC · re: Junio C Hamano · lore

merge-recursive, was Re: What's in git.git

Hi,
On Thu, 26 Oct 2006, Junio C Hamano wrote:
>   We'd still need more work on merge-recursive to fix the
>   overcautious "working file will be overwritten by merge" --
>   this is really needed for usability.

I am sorry, but I do not have the time to wrap my head around this for at least another week. It seems to be a complicated problem (not the fix, mind you, but the side effects you have to think of!), and I stupidly started to play with shallow clones when I knew I had no time already.

BTW what happened to the builtin shortlog? It is the last Perl script I use regularly... (should make people happy who are stuck with Activision Perl...)

Ciao, Dscho

Jakub Narebski· Oct 26, 2006, 09:25 UTC · re: Johannes Schindelin · lore

Re: merge-recursive, was Re: What's in git.git

Johannes Schindelin wrote:
> BTW what happened to the builtin shortlog? It is the last Perl script I 
> use regularly... (should make people happy who are stuck with Activision 
> Perl...)

BTW. both Perl version and builtin shorlog have email->real name translation table built in. In Perl script version it is in __DATA__ section, and we could update it using Inline::Files module, in C version it was in table. But in fact this list is project specific. Shouldn't we make it customizable (::sigh::, yet another file in $GIT_DIR...).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Junio C Hamano· Oct 26, 2006, 09:35 UTC · re: Jakub Narebski · lore

Re: merge-recursive, was Re: What's in git.git

Jakub Narebski <jnareb@gmail.com> writes:
Show 11 quoted lines
> Johannes Schindelin wrote:
>
>> BTW what happened to the builtin shortlog? It is the last Perl script I 
>> use regularly... (should make people happy who are stuck with Activision 
>> Perl...)
>
> BTW. both Perl version and builtin shorlog have email->real name translation
> table built in. In Perl script version it is in __DATA__ section, and we
> could update it using Inline::Files module, in C version it was in table.
> But in fact this list is project specific. Shouldn't we make it customizable
> (::sigh::, yet another file in $GIT_DIR...).

It already reads from .mailmap which could be tracked as part of the sources (if it is project specific it would be better if it can be shared among members).

Jakub Narebski· Oct 26, 2006, 09:47 UTC · re: Junio C Hamano · lore

Re: merge-recursive, was Re: What's in git.git

Junio C Hamano wrote:
Show 11 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> BTW. both Perl version and builtin shorlog have email->real name translation
>> table built in. In Perl script version it is in __DATA__ section, and we
>> could update it using Inline::Files module, in C version it was in table.
>> But in fact this list is project specific. Shouldn't we make it customizable
>> (::sigh::, yet another file in $GIT_DIR...).
> 
> It already reads from .mailmap which could be tracked as part of
> the sources (if it is project specific it would be better if it
> can be shared among members).

By the way, if I read code correctly, it read '.mailmap' from _current_ directory. Shouldn't it read qx(git-rev-parse --show-cdup)/.mailmap ?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Nicolas Pitre· Oct 26, 2006, 13:23 UTC · re: Junio C Hamano · lore

Re: merge-recursive, was Re: What's in git.git

On Thu, 26 Oct 2006, Junio C Hamano wrote:
Show 17 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > Johannes Schindelin wrote:
> >
> >> BTW what happened to the builtin shortlog? It is the last Perl script I 
> >> use regularly... (should make people happy who are stuck with Activision 
> >> Perl...)
> >
> > BTW. both Perl version and builtin shorlog have email->real name translation
> > table built in. In Perl script version it is in __DATA__ section, and we
> > could update it using Inline::Files module, in C version it was in table.
> > But in fact this list is project specific. Shouldn't we make it customizable
> > (::sigh::, yet another file in $GIT_DIR...).
> 
> It already reads from .mailmap which could be tracked as part of
> the sources (if it is project specific it would be better if it
> can be shared among members).
The C version was missing that support if I remember right.

Actually I think that the email table should be removed out of the tool entirely and always read from .mailmap instead.

Petr Baudis· Oct 26, 2006, 12:34 UTC · re: Jakub Narebski · lore

git-shortlog mailmap

I think I've complained about this in the past, but can't find the mail.

Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter where Jakub Narebski <jnareb@gmail.com> said that...

Show 11 quoted lines
> Johannes Schindelin wrote:
> 
> > BTW what happened to the builtin shortlog? It is the last Perl script I 
> > use regularly... (should make people happy who are stuck with Activision 
> > Perl...)
> 
> BTW. both Perl version and builtin shorlog have email->real name translation
> table built in. In Perl script version it is in __DATA__ section, and we
> could update it using Inline::Files module, in C version it was in table.
> But in fact this list is project specific. Shouldn't we make it customizable
> (::sigh::, yet another file in $GIT_DIR...).

I really dislike the fact that we _do_ this mapping at all, this seems so much a totally wrong point at which to do it. The information tracked in Git is still wrong and all the tools except shortlog still display it wrong - why should shortlog in particular be special? Why don't we do this at the git-am time instead?

And overally, things would be simpler if people would just require the author name to be recorded in the mail properly when applying the patch; AIUI at least in case of the kernel this mapping shouldn't really be needed anymore anyway since with the signoff protocol, you already require all the contributors to reveal their realnames in signoffs? People can then as well just write that in their from headers as well. Linus?

So what about making git-am by default refuse to apply patches with missing author realnames?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
Jakub Narebski· Oct 26, 2006, 12:41 UTC · re: Petr Baudis · lore
Petr Baudis wrote:
Show 21 quoted lines
> I think I've complained about this in the past, but can't find the mail.
> 
> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Johannes Schindelin wrote:
>> 
>> > BTW what happened to the builtin shortlog? It is the last Perl script I 
>> > use regularly... (should make people happy who are stuck with Activision 
>> > Perl...)
>> 
>> BTW. both Perl version and builtin shorlog have email->real name translation
>> table built in. In Perl script version it is in __DATA__ section, and we
>> could update it using Inline::Files module, in C version it was in table.
>> But in fact this list is project specific. Shouldn't we make it customizable
>> (::sigh::, yet another file in $GIT_DIR...).
> 
> I really dislike the fact that we _do_ this mapping at all, this seems
> so much a totally wrong point at which to do it. The information tracked
> in Git is still wrong and all the tools except shortlog still display it
> wrong - why should shortlog in particular be special? Why don't we do
> this at the git-am time instead?

Because git-shortlog has to deal also with _historical_ data, which caused one way or the other to have only email and not realname recorded. So till history gets rewritteen, and tags resigned, git-shortlog has to do the mapping to have meaningfull output.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Andreas Ericsson· Oct 26, 2006, 12:43 UTC · re: Jakub Narebski · lore
Jakub Narebski wrote:
Show 26 quoted lines
> Petr Baudis wrote:
> 
>> I think I've complained about this in the past, but can't find the mail.
>>
>> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
>> where Jakub Narebski <jnareb@gmail.com> said that...
>>> Johannes Schindelin wrote:
>>>
>>>> BTW what happened to the builtin shortlog? It is the last Perl script I 
>>>> use regularly... (should make people happy who are stuck with Activision 
>>>> Perl...)
>>> BTW. both Perl version and builtin shorlog have email->real name translation
>>> table built in. In Perl script version it is in __DATA__ section, and we
>>> could update it using Inline::Files module, in C version it was in table.
>>> But in fact this list is project specific. Shouldn't we make it customizable
>>> (::sigh::, yet another file in $GIT_DIR...).
>> I really dislike the fact that we _do_ this mapping at all, this seems
>> so much a totally wrong point at which to do it. The information tracked
>> in Git is still wrong and all the tools except shortlog still display it
>> wrong - why should shortlog in particular be special? Why don't we do
>> this at the git-am time instead?
> 
> Because git-shortlog has to deal also with _historical_ data, which caused
> one way or the other to have only email and not realname recorded. So till
> history gets rewritteen, and tags resigned, git-shortlog has to do the
> mapping to have meaningfull output.

Wouldn't this be better implemented in the rev-list code then, so all log viewers can benefit from it?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Jakub Narebski· Oct 26, 2006, 13:13 UTC · re: Andreas Ericsson · lore
Andreas Ericsson wrote:
Show 25 quoted lines
> Jakub Narebski wrote:
>> Petr Baudis wrote:
>>>
>>> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
>>> where Jakub Narebski <jnareb@gmail.com> said that...
>>>>
>>>> BTW. both Perl version and builtin shorlog have email->real name translation
>>>> table built in. In Perl script version it is in __DATA__ section, and we
>>>> could update it using Inline::Files module, in C version it was in table.
>>>> But in fact this list is project specific. Shouldn't we make it customizable
>>>> (::sigh::, yet another file in $GIT_DIR...).
>>>>
>>> I really dislike the fact that we _do_ this mapping at all, this seems
>>> so much a totally wrong point at which to do it. The information tracked
>>> in Git is still wrong and all the tools except shortlog still display it
>>> wrong - why should shortlog in particular be special? Why don't we do
>>> this at the git-am time instead?
>> 
>> Because git-shortlog has to deal also with _historical_ data, which caused
>> one way or the other to have only email and not realname recorded. So till
>> history gets rewritteen, and tags resigned, git-shortlog has to do the
>> mapping to have meaningfull output.
> 
> Wouldn't this be better implemented in the rev-list code then, so all 
> log viewers can benefit from it?

Because this belongs to porcelain. Plumbing shouldn't show something that isn't there.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Johannes Schindelin· Oct 26, 2006, 13:16 UTC · re: Jakub Narebski · lore
Hi,
On Thu, 26 Oct 2006, Jakub Narebski wrote:
Show 7 quoted lines
> Andreas Ericsson wrote:
> 
> > Wouldn't this be better implemented in the rev-list code then, so all 
> > log viewers can benefit from it?
> 
> Because this belongs to porcelain. Plumbing shouldn't show something
> that isn't there.

Actually, I think it would make sense. Since log viewers are porcelain-ish, they could transform the author/committer data according to .mailmap. Of course, that means that if two people have different mailmaps, they have to be aware of that fact when disagreeing over some authorship.

Ciao, Dscho

Petr Baudis· Oct 26, 2006, 13:29 UTC · re: Jakub Narebski · lore

Dear diary, on Thu, Oct 26, 2006 at 02:41:38PM CEST, I got a letter where Jakub Narebski <jnareb@gmail.com> said that...

> Because git-shortlog has to deal also with _historical_ data, which caused
> one way or the other to have only email and not realname recorded.

When does it in practice have to deal also with historical data, these days?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
Junio C Hamano· Oct 26, 2006, 09:26 UTC · re: Johannes Schindelin · lore

Re: merge-recursive, was Re: What's in git.git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 10 quoted lines
> On Thu, 26 Oct 2006, Junio C Hamano wrote:
>
>>   We'd still need more work on merge-recursive to fix the
>>   overcautious "working file will be overwritten by merge" --
>>   this is really needed for usability.
>
> I am sorry, but I do not have the time to wrap my head around this for at 
> least another week. It seems to be a complicated problem (not the fix, 
> mind you, but the side effects you have to think of!), and I stupidly 
> started to play with shallow clones when I knew I had no time already.

No need to worry nor feel pressure; it's all volunteer work and we do this for fun.

> BTW what happened to the builtin shortlog? It is the last Perl script I 
> use regularly... (should make people happy who are stuck with Activision 
> Perl...)

Yeah, I was wondering about it too, when I was looking for something readily mergeable to "next" today. I must have misplaced it.

Junio C Hamano· Oct 26, 2006, 10:00 UTC · re: Junio C Hamano · lore

Re: merge-recursive, was Re: What's in git.git

Junio C Hamano <junkio@cox.net> writes:
Show 7 quoted lines
>> BTW what happened to the builtin shortlog? It is the last Perl script I 
>> use regularly... (should make people happy who are stuck with Activision 
>> Perl...)
>
> Yeah, I was wondering about it too, when I was looking for
> something readily mergeable to "next" today.  I must have
> misplaced it.
I looked at the code again.

This is a prime demonstration that it makes more sense to keep script version until we flush out configurability issues.

The built-in mailmap list is easily overridden with ".mailmap" which presumably projects would want to keep under version control, so it is less of an issue, but not everybody would necessarily want to name that file ".mailmap".

There is a "dot3" merge source shortening logic that is very specific to the kernel, and this cannot be customized per project. If it were kept as Perl script, each project could limp along with a copy of this script, modified for their needs, without making the script itself customizable. Rewriting it into C does not _forbid_ that kind of use, but certainly it makes it more cumbersome to do so.

First I'd probably ask kernel folks to maintain their own copy of .mailmap at the toplevel of their source tree, so that we can remove this kernel specific built-in mailmap from shortlog (I'd even do so before switching from the Perl version).

The dot3 logic is probably best substituted with config, a version controllable file similar to .mailmap, or command line parameters, but I am not sure which one is the best way to go. Whatever mechanism is used, It essentially is to define a mapping from a long string to its abbreviation (currently there is one hardcoded one, that replaces /pub/scm/linux/kernel/git/ to /.../), to be applied to the first line of log message body. Presumably other projects could have more than one "popular" prefixes that appear often, so (if we take command line approach, which I think is the worst of the three possibilities) the "slightly more generalized" version would look something like this perhaps?

  git-shortlog --mailmapfile=.mailmap \
  	--abbrev=/pub/scm/linux/kernel/git/,/.../ \
        --abbrev=/pub/scm/,/.../../

We could even define the --abbrev stuff as 's/from/to/' but that would make it harder for us to shake Perl off, and in practice this is to shorten the merge source repository name, so deliberately limiting its feature to simple string replace like the above might make more sense.

Johannes Schindelin· Oct 26, 2006, 10:56 UTC · re: Junio C Hamano · lore

Re: merge-recursive, was Re: What's in git.git

Hi,
On Thu, 26 Oct 2006, Junio C Hamano wrote:
> This is a prime demonstration that it makes more sense to keep script 
> version until we flush out configurability issues.
Okay, I agree.

BTW before somebody asks: No, I did _not_ implement the .mailmap functionality. But once things are flushed out with the configuration, and _if_ the builtin is not undesired, I will implement it.

Since Linux really is a special guest, maybe we'd want to integrate the dot3 thing in .mailmap, and override the Linux defaults _only_ if .mailmap exists. Thoughts?

Ciao, Dscho

Andreas Ericsson· Oct 26, 2006, 11:35 UTC · re: Johannes Schindelin · lore

shortlog, was Re: merge-recursive, was Re: What's in git.git

Johannes Schindelin wrote:
Show 5 quoted lines
> 
> BTW what happened to the builtin shortlog? It is the last Perl script I 
> use regularly... (should make people happy who are stuck with Activision 
> Perl...)
> 
I keep writing
	git log --short
when I really want
	git log --pretty=short | git shortlog
I'll have a look at making it work if I get a spare moment.
-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Nicolas Pitre· Oct 26, 2006, 13:39 UTC · re: Andreas Ericsson · lore

Re: shortlog, was Re: merge-recursive, was Re: What's in git.git

On Thu, 26 Oct 2006, Andreas Ericsson wrote:
Show 8 quoted lines
> I keep writing
> 	git log --short
> 
> when I really want
> 	git log --pretty=short | git shortlog
> 
> 
> I'll have a look at making it work if I get a spare moment.
Why don't you simply drop the --pretty=short altogether?
	git log | git shortlog
Andreas Ericsson· Oct 26, 2006, 13:45 UTC · re: Nicolas Pitre · lore

Re: shortlog, was Re: merge-recursive, was Re: What's in git.git

Nicolas Pitre wrote:
Show 15 quoted lines
> On Thu, 26 Oct 2006, Andreas Ericsson wrote:
> 
>> I keep writing
>> 	git log --short
>>
>> when I really want
>> 	git log --pretty=short | git shortlog
>>
>>
>> I'll have a look at making it work if I get a spare moment.
> 
> Why don't you simply drop the --pretty=short altogether?
> 
> 	git log | git shortlog
> 

Dunno. Mainly because I saw the "git log --pretty=short | git shortlog" construct somewhere, I guess. Either way, it would make more sense to have it as --pretty=by-author or something like that instead.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Jakub Narebski· Oct 26, 2006, 09:19 UTC · re: Junio C Hamano · lore

Re: What's in git.git

Junio C Hamano wrote:
Show 5 quoted lines
>   I did not hear any comments on the left-right stuff; perhaps
>   it is not needed, or it is not useful as its current shape (it
>   could be enhanced to say which starting commits each of the
>   commit is reachable from, by borrowing much of show-branch
>   code).
It looks reasonable, and useful.
>   I looked at Pasky's "project forks" gitweb code, and while I
>   liked it a lot (having a demonstration site repo.or.cz really
>   helps), I read on #git log that Pasky himself was having
>   doubt, so it is parked in "pu", not in "next".
Perhaps that's for the best.
By the way, Pasky, where one can find your changes to gitweb?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Petr Baudis· Oct 27, 2006, 01:10 UTC · re: Jakub Narebski · lore

Re: What's in git.git

Dear diary, on Thu, Oct 26, 2006 at 11:19:49AM CEST, I got a letter where Jakub Narebski <jnareb@gmail.com> said that...

> By the way, Pasky, where one can find your changes to gitweb?
http://repo.or.cz/w/git/repo.git
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
Petr Baudis· Oct 26, 2006, 12:22 UTC · re: Junio C Hamano · lore

Re: What's in git.git

Dear diary, on Thu, Oct 26, 2006 at 10:47:12AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> said that...

>       gitweb: use for-each-ref to show the latest activity across branches

It's a pity that for-each-ref is used only for that, I'd appreciate a lot if git_get_refs_list() could use it too, for the sake of repo.or.cz:glibc-cvs.git summary view, which is massive. :-)

>   I looked at Pasky's "project forks" gitweb code, and while I
>   liked it a lot (having a demonstration site repo.or.cz really
>   helps), I read on #git log that Pasky himself was having
>   doubt, so it is parked in "pu", not in "next".

I had doubts in the middle of implementing it, but now I don't - for summary of why, please see

	http://news.gmane.org/find-root.php?message_id=<20061024173943.GF20017@pasky.or.cz>
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
Andy Whitcroft· Oct 26, 2006, 17:27 UTC · re: Junio C Hamano · lore

Re: What's in git.git

Junio C Hamano wrote:
Show 5 quoted lines
>   I did not hear any comments on the left-right stuff; perhaps
>   it is not needed, or it is not useful as its current shape (it
>   could be enhanced to say which starting commits each of the
>   commit is reachable from, by borrowing much of show-branch
>   code).

That was the stuff which kinda did cherry in rev-list. It seemed to produce interesting output, but nothing I couldn't do with cherry. Still interesting tho. The sort of thing that if it was in there someone would find a use for, think lazers.

← back to recent threads