What's in git.git

What's in git.git

[Junio C Hamano]

* 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'

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

> * 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

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

[Johannes Schindelin]

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

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>   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

Re: What's in git.git

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> 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.

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

[Jakub Narebski]

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

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> 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.

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

[Junio C Hamano]

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).

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

[Jakub Narebski]

Junio C Hamano wrote:

> 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

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

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

>> 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.

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

[Johannes Schindelin]

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

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

[Andreas Ericsson]

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...)
> 

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

Re: What's in git.git

[Petr Baudis]

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?

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

Re: What's in git.git

[Jakub Narebski]

Dnia czwartek 26. października 2006 14:08, Petr Baudis napisał:
> 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

Re: What's in git.git

[Petr Baudis]

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

git-shortlog mailmap

[Petr Baudis]

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?

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

Re: git-shortlog mailmap

[Jakub Narebski]

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.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git-shortlog mailmap

[Andreas Ericsson]

Jakub Narebski wrote:
> 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

Re: git-shortlog mailmap

[Jakub Narebski]

Andreas Ericsson wrote:

> 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

Re: git-shortlog mailmap

[Johannes Schindelin]

Hi,

On Thu, 26 Oct 2006, Jakub Narebski wrote:

> 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

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

[Nicolas Pitre]

On Thu, 26 Oct 2006, Junio C Hamano wrote:

> 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.

Re: git-shortlog mailmap

[Petr Baudis]

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

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

[Nicolas Pitre]

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

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

[Andreas Ericsson]

Nicolas Pitre wrote:
> 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

Re: What's in git.git

[Andy Whitcroft]

Junio C Hamano wrote:

>   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.

Re: What's in git.git

[Petr Baudis]

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