From: Junio C Hamano <hidden> Date: 2016-08-11 20:12:19
* 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'
From: Andreas Ericsson <hidden> Date: 2016-08-11 19:19:38
Jakub Narebski wrote:
Petr Baudis wrote:
quoted
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 [off-list ref] said that...
quoted
Johannes Schindelin wrote:
quoted
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
From: Andreas Ericsson <hidden> Date: 2016-08-11 19:19:49
Nicolas Pitre wrote:
On Thu, 26 Oct 2006, Andreas Ericsson wrote:
quoted
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
From: Jakub Narebski <hidden> Date: 2016-08-11 19:21:40
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 [off-list ref] said that...
quoted
Johannes Schindelin wrote:
quoted
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
From: Johannes Schindelin <hidden> Date: 2016-08-11 19:23:21
Hi,
On Thu, 26 Oct 2006, Jakub Narebski wrote:
Andreas Ericsson wrote:
quoted
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
From: Petr Baudis <hidden> Date: 2016-08-11 19:24:53
Dear diary, on Thu, Oct 26, 2006 at 10:47:12AM CEST, I got a letter
where Junio C Hamano [off-list ref] 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=[off-list ref]
--
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
From: Andy Whitcroft <hidden> Date: 2016-08-11 19:27:59
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.
From: Petr Baudis <hidden> Date: 2016-08-11 19:34:51
Dear diary, on Thu, Oct 26, 2006 at 02:41:38PM CEST, I got a letter
where Jakub Narebski [off-list ref] 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
From: Jakub Narebski <hidden> Date: 2016-08-11 19:40:44
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
From: Petr Baudis <hidden> Date: 2016-08-11 19:48:07
Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter
where Jakub Narebski [off-list ref] 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
From: Jakub Narebski <hidden> Date: 2016-08-11 19:57:06
Andreas Ericsson wrote:
Jakub Narebski wrote:
quoted
Petr Baudis wrote:
quoted
Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
where Jakub Narebski [off-list ref] said that...
quoted
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
From: Petr Baudis <hidden> Date: 2016-08-11 20:00:00
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 [off-list ref] said that...
Johannes Schindelin wrote:
quoted
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
From: Jakub Narebski <hidden> Date: 2016-08-11 20:00:10
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
From: Andreas Ericsson <hidden> Date: 2016-08-11 20:15:29
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
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:17:07
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
From: Jakub Narebski <hidden> Date: 2016-08-11 20:23:46
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 [off-list ref] said that...
quoted
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
From: Jakub Narebski <hidden> Date: 2016-08-11 20:39:41
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