* What's in git.git
@ 2006-10-26 8:47 Junio C Hamano
2006-10-26 9:12 ` Jakub Narebski
` (4 more replies)
0 siblings, 5 replies; 26+ messages in thread
From: Junio C Hamano @ 2006-10-26 8:47 UTC (permalink / raw
To: 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'
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: What's in git.git
2006-10-26 8:47 What's in git.git Junio C Hamano
@ 2006-10-26 9:12 ` Jakub Narebski
2006-10-26 9:24 ` Junio C Hamano
2006-10-26 12:08 ` Petr Baudis
2006-10-26 9:18 ` merge-recursive, was " Johannes Schindelin
` (3 subsequent siblings)
4 siblings, 2 replies; 26+ messages in thread
From: Jakub Narebski @ 2006-10-26 9:12 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* merge-recursive, was Re: What's in git.git
2006-10-26 8:47 What's in git.git Junio C Hamano
2006-10-26 9:12 ` Jakub Narebski
@ 2006-10-26 9:18 ` Johannes Schindelin
2006-10-26 9:25 ` Jakub Narebski
` (2 more replies)
2006-10-26 9:19 ` Jakub Narebski
` (2 subsequent siblings)
4 siblings, 3 replies; 26+ messages in thread
From: Johannes Schindelin @ 2006-10-26 9:18 UTC (permalink / raw
To: Junio C Hamano; +Cc: 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: What's in git.git
2006-10-26 8:47 What's in git.git Junio C Hamano
2006-10-26 9:12 ` Jakub Narebski
2006-10-26 9:18 ` merge-recursive, was " Johannes Schindelin
@ 2006-10-26 9:19 ` Jakub Narebski
2006-10-27 1:10 ` Petr Baudis
2006-10-26 12:22 ` Petr Baudis
2006-10-26 17:27 ` Andy Whitcroft
4 siblings, 1 reply; 26+ messages in thread
From: Jakub Narebski @ 2006-10-26 9:19 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: What's in git.git
2006-10-26 9:12 ` Jakub Narebski
@ 2006-10-26 9:24 ` Junio C Hamano
2006-10-26 12:08 ` Petr Baudis
1 sibling, 0 replies; 26+ messages in thread
From: Junio C Hamano @ 2006-10-26 9:24 UTC (permalink / raw
To: Jakub Narebski; +Cc: git
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: merge-recursive, was Re: What's in git.git
2006-10-26 9:18 ` merge-recursive, was " Johannes Schindelin
@ 2006-10-26 9:25 ` Jakub Narebski
2006-10-26 9:35 ` Junio C Hamano
2006-10-26 12:34 ` git-shortlog mailmap Petr Baudis
2006-10-26 9:26 ` merge-recursive, was Re: What's in git.git Junio C Hamano
2006-10-26 11:35 ` shortlog, was " Andreas Ericsson
2 siblings, 2 replies; 26+ messages in thread
From: Jakub Narebski @ 2006-10-26 9:25 UTC (permalink / raw
To: 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: merge-recursive, was Re: What's in git.git
2006-10-26 9:18 ` merge-recursive, was " Johannes Schindelin
2006-10-26 9:25 ` Jakub Narebski
@ 2006-10-26 9:26 ` Junio C Hamano
2006-10-26 10:00 ` Junio C Hamano
2006-10-26 11:35 ` shortlog, was " Andreas Ericsson
2 siblings, 1 reply; 26+ messages in thread
From: Junio C Hamano @ 2006-10-26 9:26 UTC (permalink / raw
To: Johannes Schindelin; +Cc: git
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: merge-recursive, was Re: What's in git.git
2006-10-26 9:25 ` Jakub Narebski
@ 2006-10-26 9:35 ` Junio C Hamano
2006-10-26 9:47 ` Jakub Narebski
2006-10-26 13:23 ` Nicolas Pitre
2006-10-26 12:34 ` git-shortlog mailmap Petr Baudis
1 sibling, 2 replies; 26+ messages in thread
From: Junio C Hamano @ 2006-10-26 9:35 UTC (permalink / raw
To: Jakub Narebski; +Cc: git
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).
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: merge-recursive, was Re: What's in git.git
2006-10-26 9:35 ` Junio C Hamano
@ 2006-10-26 9:47 ` Jakub Narebski
2006-10-26 13:23 ` Nicolas Pitre
1 sibling, 0 replies; 26+ messages in thread
From: Jakub Narebski @ 2006-10-26 9:47 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: merge-recursive, was Re: What's in git.git
2006-10-26 9:26 ` merge-recursive, was Re: What's in git.git Junio C Hamano
@ 2006-10-26 10:00 ` Junio C Hamano
2006-10-26 10:56 ` Johannes Schindelin
0 siblings, 1 reply; 26+ messages in thread
From: Junio C Hamano @ 2006-10-26 10:00 UTC (permalink / raw
To: Johannes Schindelin; +Cc: git, Linus Torvalds
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: merge-recursive, was Re: What's in git.git
2006-10-26 10:00 ` Junio C Hamano
@ 2006-10-26 10:56 ` Johannes Schindelin
0 siblings, 0 replies; 26+ messages in thread
From: Johannes Schindelin @ 2006-10-26 10:56 UTC (permalink / raw
To: Junio C Hamano; +Cc: git, Linus Torvalds
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* shortlog, was Re: merge-recursive, was Re: What's in git.git
2006-10-26 9:18 ` merge-recursive, was " Johannes Schindelin
2006-10-26 9:25 ` Jakub Narebski
2006-10-26 9:26 ` merge-recursive, was Re: What's in git.git Junio C Hamano
@ 2006-10-26 11:35 ` Andreas Ericsson
2006-10-26 13:39 ` Nicolas Pitre
2 siblings, 1 reply; 26+ messages in thread
From: Andreas Ericsson @ 2006-10-26 11:35 UTC (permalink / raw
To: Johannes Schindelin; +Cc: Junio C Hamano, 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...)
>
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: What's in git.git
2006-10-26 9:12 ` Jakub Narebski
2006-10-26 9:24 ` Junio C Hamano
@ 2006-10-26 12:08 ` Petr Baudis
2006-10-26 12:17 ` Jakub Narebski
1 sibling, 1 reply; 26+ messages in thread
From: Petr Baudis @ 2006-10-26 12:08 UTC (permalink / raw
To: Jakub Narebski; +Cc: 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...
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: What's in git.git
2006-10-26 12:08 ` Petr Baudis
@ 2006-10-26 12:17 ` Jakub Narebski
0 siblings, 0 replies; 26+ messages in thread
From: Jakub Narebski @ 2006-10-26 12:17 UTC (permalink / raw
To: Petr Baudis; +Cc: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: What's in git.git
2006-10-26 8:47 What's in git.git Junio C Hamano
` (2 preceding siblings ...)
2006-10-26 9:19 ` Jakub Narebski
@ 2006-10-26 12:22 ` Petr Baudis
2006-10-26 17:27 ` Andy Whitcroft
4 siblings, 0 replies; 26+ messages in thread
From: Petr Baudis @ 2006-10-26 12:22 UTC (permalink / raw
To: Junio C Hamano; +Cc: 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* git-shortlog mailmap
2006-10-26 9:25 ` Jakub Narebski
2006-10-26 9:35 ` Junio C Hamano
@ 2006-10-26 12:34 ` Petr Baudis
2006-10-26 12:41 ` Jakub Narebski
1 sibling, 1 reply; 26+ messages in thread
From: Petr Baudis @ 2006-10-26 12:34 UTC (permalink / raw
To: Jakub Narebski; +Cc: torvalds, git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-shortlog mailmap
2006-10-26 12:34 ` git-shortlog mailmap Petr Baudis
@ 2006-10-26 12:41 ` Jakub Narebski
2006-10-26 12:43 ` Andreas Ericsson
2006-10-26 13:29 ` Petr Baudis
0 siblings, 2 replies; 26+ messages in thread
From: Jakub Narebski @ 2006-10-26 12:41 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-shortlog mailmap
2006-10-26 12:41 ` Jakub Narebski
@ 2006-10-26 12:43 ` Andreas Ericsson
2006-10-26 13:13 ` Jakub Narebski
2006-10-26 13:29 ` Petr Baudis
1 sibling, 1 reply; 26+ messages in thread
From: Andreas Ericsson @ 2006-10-26 12:43 UTC (permalink / raw
To: Jakub Narebski; +Cc: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-shortlog mailmap
2006-10-26 12:43 ` Andreas Ericsson
@ 2006-10-26 13:13 ` Jakub Narebski
2006-10-26 13:16 ` Johannes Schindelin
0 siblings, 1 reply; 26+ messages in thread
From: Jakub Narebski @ 2006-10-26 13:13 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-shortlog mailmap
2006-10-26 13:13 ` Jakub Narebski
@ 2006-10-26 13:16 ` Johannes Schindelin
0 siblings, 0 replies; 26+ messages in thread
From: Johannes Schindelin @ 2006-10-26 13:16 UTC (permalink / raw
To: Jakub Narebski; +Cc: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: merge-recursive, was Re: What's in git.git
2006-10-26 9:35 ` Junio C Hamano
2006-10-26 9:47 ` Jakub Narebski
@ 2006-10-26 13:23 ` Nicolas Pitre
1 sibling, 0 replies; 26+ messages in thread
From: Nicolas Pitre @ 2006-10-26 13:23 UTC (permalink / raw
To: Junio C Hamano; +Cc: Jakub Narebski, git
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: git-shortlog mailmap
2006-10-26 12:41 ` Jakub Narebski
2006-10-26 12:43 ` Andreas Ericsson
@ 2006-10-26 13:29 ` Petr Baudis
1 sibling, 0 replies; 26+ messages in thread
From: Petr Baudis @ 2006-10-26 13:29 UTC (permalink / raw
To: Jakub Narebski; +Cc: git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: shortlog, was Re: merge-recursive, was Re: What's in git.git
2006-10-26 11:35 ` shortlog, was " Andreas Ericsson
@ 2006-10-26 13:39 ` Nicolas Pitre
2006-10-26 13:45 ` Andreas Ericsson
0 siblings, 1 reply; 26+ messages in thread
From: Nicolas Pitre @ 2006-10-26 13:39 UTC (permalink / raw
To: Andreas Ericsson; +Cc: Johannes Schindelin, Junio C Hamano, git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: shortlog, was Re: merge-recursive, was Re: What's in git.git
2006-10-26 13:39 ` Nicolas Pitre
@ 2006-10-26 13:45 ` Andreas Ericsson
0 siblings, 0 replies; 26+ messages in thread
From: Andreas Ericsson @ 2006-10-26 13:45 UTC (permalink / raw
To: Nicolas Pitre; +Cc: Johannes Schindelin, Junio C Hamano, git
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: What's in git.git
2006-10-26 8:47 What's in git.git Junio C Hamano
` (3 preceding siblings ...)
2006-10-26 12:22 ` Petr Baudis
@ 2006-10-26 17:27 ` Andy Whitcroft
4 siblings, 0 replies; 26+ messages in thread
From: Andy Whitcroft @ 2006-10-26 17:27 UTC (permalink / raw
To: Junio C Hamano; +Cc: git
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: What's in git.git
2006-10-26 9:19 ` Jakub Narebski
@ 2006-10-27 1:10 ` Petr Baudis
0 siblings, 0 replies; 26+ messages in thread
From: Petr Baudis @ 2006-10-27 1:10 UTC (permalink / raw
To: Jakub Narebski; +Cc: 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
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2006-10-27 1:11 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-26 8:47 What's in git.git Junio C Hamano
2006-10-26 9:12 ` Jakub Narebski
2006-10-26 9:24 ` Junio C Hamano
2006-10-26 12:08 ` Petr Baudis
2006-10-26 12:17 ` Jakub Narebski
2006-10-26 9:18 ` merge-recursive, was " Johannes Schindelin
2006-10-26 9:25 ` Jakub Narebski
2006-10-26 9:35 ` Junio C Hamano
2006-10-26 9:47 ` Jakub Narebski
2006-10-26 13:23 ` Nicolas Pitre
2006-10-26 12:34 ` git-shortlog mailmap Petr Baudis
2006-10-26 12:41 ` Jakub Narebski
2006-10-26 12:43 ` Andreas Ericsson
2006-10-26 13:13 ` Jakub Narebski
2006-10-26 13:16 ` Johannes Schindelin
2006-10-26 13:29 ` Petr Baudis
2006-10-26 9:26 ` merge-recursive, was Re: What's in git.git Junio C Hamano
2006-10-26 10:00 ` Junio C Hamano
2006-10-26 10:56 ` Johannes Schindelin
2006-10-26 11:35 ` shortlog, was " Andreas Ericsson
2006-10-26 13:39 ` Nicolas Pitre
2006-10-26 13:45 ` Andreas Ericsson
2006-10-26 9:19 ` Jakub Narebski
2006-10-27 1:10 ` Petr Baudis
2006-10-26 12:22 ` Petr Baudis
2006-10-26 17:27 ` Andy Whitcroft
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).