* Re: [PATCH] git-pickaxe: blame rewritten.
From: Petr Baudis @ 2006-10-12 22:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egmdkv$k33$1@sea.gmane.org>
Dear diary, on Thu, Oct 12, 2006 at 11:55:49PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Junio C Hamano wrote:
>
> > Currently it does what git-blame does, but only faster.
> >
> > More importantly, its internal structure is designed to support
> > content movement (aka cut-and-paste) more easily by allowing
> > more than one paths to be taken from the same commit.
> >
> > Signed-off-by: Junio C Hamano <junkio@cox.net>
> > ---
> >
> > I really hate to do this immediately after writing obituary for
> > annotate, but I had a solid 24-hour to work on git, which is a
> > rare opportunity for me these days, so here it is.
>
> Why not reuse git-annotate name? git-pickaxe doesn't do pickaxe...
I agree that git-pickaxe is wrong, and luckily Junio does too,
apparently.
But please, let's not go right back to the git-annotate / git-blame
situation. It's just confusing to have two tools that do the same thing,
perhaps subtly differently. If it's gonna replace git-blame, it should
either do that right away or live as git-blame2 for some time, but not
play any confusing games with the names.
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] git-pickaxe: blame rewritten.
From: Jakub Narebski @ 2006-10-12 21:55 UTC (permalink / raw)
To: git
In-Reply-To: <7v7iz5rk4b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Currently it does what git-blame does, but only faster.
>
> More importantly, its internal structure is designed to support
> content movement (aka cut-and-paste) more easily by allowing
> more than one paths to be taken from the same commit.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> I really hate to do this immediately after writing obituary for
> annotate, but I had a solid 24-hour to work on git, which is a
> rare opportunity for me these days, so here it is.
Why not reuse git-annotate name? git-pickaxe doesn't do pickaxe...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-revert with conflicts to behave as git-merge with conflicts
From: Junio C Hamano @ 2006-10-12 22:27 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061012215242.16419.qmail@web31810.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- a/git-commit.sh
> +++ b/git-commit.sh
> @@ -441,7 +441,7 @@ then
> elif test "$use_commit" != ""
> then
> git-cat-file commit "$use_commit" | sed -e '1,/^$/d'
> -elif test -f "$GIT_DIR/MERGE_HEAD" && test -f "$GIT_DIR/MERGE_MSG"
> +elif test -f "$GIT_DIR/MERGE_MSG"
> then
> cat "$GIT_DIR/MERGE_MSG"
> elif test -f "$GIT_DIR/SQUASH_MSG"
If you rely on MERGE_MSG then you would need to clean it after
commit is done. Currently it does not and checks MERGE_HEAD,
and cleans up MERGE_HEAD when it is done. MERGE_MSG is not
cleaned.
^ permalink raw reply
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: Martin Waitz @ 2006-10-12 22:27 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: apodtele, git
In-Reply-To: <452EBF99.5020108@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
hoi :)
On Thu, Oct 12, 2006 at 03:20:09PM -0700, A Large Angry SCM wrote:
> >+ if (it)
> >+ return it * width / (it + width) + 1;
> >+ else
> >+ return 0;
>
> No conditional needed:
>
> return it * width / (it + width - 1)
But then it would start scaling much earlier
(for width 10: at 2 instead of 4).
This is not bad per se, but different...
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-imap-send: Strip smtp From_ header from imap message.
From: Markus Amsler @ 2006-10-12 22:19 UTC (permalink / raw)
To: git; +Cc: Mike McCormack
Cyrus imap refuses messages with a 'From ' Header.
Signed-off-by: Markus Amsler <markus.amsler@oribi.org>
---
imap-send.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 362e474..16804ab 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1226,6 +1226,14 @@ split_msg( msg_data_t *all_msgs, msg_dat
if (msg->len < 5 || strncmp( data, "From ", 5 ))
return 0;
+ p = strchr( data, '\n' );
+ if (p) {
+ p = &p[1];
+ msg->len -= p-data;
+ *ofs += p-data;
+ data = p;
+ }
+
p = strstr( data, "\nFrom " );
if (p)
msg->len = &p[1] - data;
^ permalink raw reply related
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: Junio C Hamano @ 2006-10-12 22:24 UTC (permalink / raw)
To: Alexei Podtelezhnikov; +Cc: git
In-Reply-To: <7vlknlmc9y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Missing e-mail address on S-o-b line. If your mail From: line
> does not say who you are, please add an extra From: line in the
> body, like this:
>
> From: Alexei Podtelezhnikov <apodtele@gmail.com>
> Subject: [PATCH 1/2] diff --stat: ...
>
> Instead of ...
>
> Signed-off-by: Alexei Podtelezhnikov <apodtele@gmail.com>
Eh, no.
Sorry, what I meant was:
Not like this:
From: apodtele <apodtele@gmail.com>
Subject: [PATCH 1/2] diff --stat: ...
Instead of ...
Signed-off-by: Alexei Podtelezhnikov
But like this:
From: apodtele <apodtele@gmail.com>
Subject: [PATCH 1/2] diff --stat: ...
From: Alexei Podtelezhnikov <apodtele@gmail.com>
Instead of ...
Signed-off-by: Alexei Podtelezhnikov <apodtele@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: A Large Angry SCM @ 2006-10-12 22:20 UTC (permalink / raw)
To: apodtele; +Cc: Martin Waitz, git
In-Reply-To: <d620685f0610121437m38eb454g7597b2a93010b023@mail.gmail.com>
apodtele wrote:
> On 10/12/06, Martin Waitz <tali@admingilde.org> wrote:
>> On Thu, Oct 12, 2006 at 03:37:17PM -0400, apodtele wrote:
>> > Instead of conditionally scaling the stat graph for large changes,
>> > always scale it asymptotically: small changes shall appear without any
>> > distortions.
>>
>> very nice idea!
>>
>> > + return it * width / (it + width) + 1;
>>
>> but wouldn't this formula result in at least 1, even for a 0 change?
>> Perhaps we'd have to special case an input of 0?
[...]
> + if (it)
> + return it * width / (it + width) + 1;
> + else
> + return 0;
No conditional needed:
return it * width / (it + width - 1)
^ permalink raw reply
* Re: [PATCH] git-pickaxe: blame rewritten.
From: Junio C Hamano @ 2006-10-12 22:20 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061012193107.44651.qmail@web31805.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Junio, is it possible to also print the "previous" commit?
> I mean, is it tenable to print the commit such that
> a "git-diff C B -- A:file" will give a diff of the block of lines
> we're looking at?
There is no single "previous" in general. Which side of the
merge would you take?
^ permalink raw reply
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: A Large Angry SCM @ 2006-10-12 22:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexei Podtelezhnikov, git
In-Reply-To: <7vlknlmc9y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
[...]
>
> We could align things in the middle, like this, though:
>
> A | ++++++++++++--------
> B | ++++++++------------
> C | +++++++++++++++---------------
This is more diff like and makes comparing the right and left side
changes easier.
A | --------@++++++++++++ |
B | ------------@++++++++ |
C | ---------------@+++++++++++++++ |
^ permalink raw reply
* [PATCH] git-revert: use GIT_DIR shell variable for the MERGE_MSG
From: Luben Tuikov @ 2006-10-12 22:11 UTC (permalink / raw)
To: git
Ooops!
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
git-revert.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-revert.sh b/git-revert.sh
index 2e23cf4..6eab3c7 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -145,7 +145,7 @@ git-read-tree -m -u --aggressive $base $
result=$(git-write-tree 2>/dev/null) || {
echo >&2 "Simple $me fails; trying Automatic $me."
git-merge-index -o git-merge-one-file -a || {
- mv -f .msg .git/MERGE_MSG
+ mv -f .msg "$GIT_DIR/MERGE_MSG"
{
echo '
Conflicts:
--
1.4.3.rc2.gd9edb
^ permalink raw reply related
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: Junio C Hamano @ 2006-10-12 21:53 UTC (permalink / raw)
To: Alexei Podtelezhnikov; +Cc: git
In-Reply-To: <d620685f0610121237k458665c5m7bbde2d565d7ef81@mail.gmail.com>
apodtele <apodtele@gmail.com> writes:
> Instead of conditionally scaling the stat graph for large changes,
> always scale it asymptotically: small changes shall appear without any
> distortions.
>
> Signed-off-by: Alexei Podtelezhnikov
Missing e-mail address on S-o-b line. If your mail From: line
does not say who you are, please add an extra From: line in the
body, like this:
From: Alexei Podtelezhnikov <apodtele@gmail.com>
Subject: [PATCH 1/2] diff --stat: ...
Instead of ...
Signed-off-by: Alexei Podtelezhnikov <apodtele@gmail.com>
I am not sure if any non-linear scaling is worth pursuing.
Suppose your change set has three files modified:
A adds 20 lines, deletes 10 lines
B adds 10 lines, deletes 20 lines
C adds 30 lines, deletes 30 lines
When drawing into a specified width that leaves 20-column for
the graph part, what would we see? What would we see if the
graph part is 21-column wide? 59-column wide? 80-column wide?
For obvious reasons, the total length of A and B exceeds half of
C, which looks quite misleading.
A | ++++++++++++--------
B | ++++++++------------
C | +++++++++++++++---------------
We could align things in the middle, like this, though:
A | ++++++++++++--------
B | ++++++++------------
C | +++++++++++++++---------------
^ permalink raw reply
* [PATCH] git-revert with conflicts to behave as git-merge with conflicts
From: Luben Tuikov @ 2006-10-12 21:52 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
In a busy project, reverting a commit almost always results
in a conflict between one or more files (depending on the
commit being reverted). It is useful to record this
conflict in the commit-to-be message of the resulting commit
(after the resolve). The process now becomes:
git-revert <SHA-1>
<git complains and prints failed automatic>
<user manually resolves>
git-update-index <resolved files>
git-commit -s
And the commit message is now a merge of the revert commit
message and the conflict commit message, giving the user a
chance to edit it or add more information:
---cut---
Revert "title of reverted commit"
This reverts commit <SHA-1>
Conflicts:
<filename>
...
---cut---
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
git-commit.sh | 4 ++--
git-revert.sh | 11 ++++++++++-
2 files changed, 12 insertions(+), 3 deletions(-)
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 1624 bytes --]
diff --git a/git-commit.sh b/git-commit.sh
index 4bd0e46..81c3a0c 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -441,7 +441,7 @@ then
elif test "$use_commit" != ""
then
git-cat-file commit "$use_commit" | sed -e '1,/^$/d'
-elif test -f "$GIT_DIR/MERGE_HEAD" && test -f "$GIT_DIR/MERGE_MSG"
+elif test -f "$GIT_DIR/MERGE_MSG"
then
cat "$GIT_DIR/MERGE_MSG"
elif test -f "$GIT_DIR/SQUASH_MSG"
@@ -607,7 +607,7 @@ then
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
rlogm=$(sed -e 1q "$GIT_DIR"/COMMIT_MSG) &&
git-update-ref -m "$rloga: $rlogm" HEAD $commit "$current" &&
- rm -f -- "$GIT_DIR/MERGE_HEAD" &&
+ rm -f -- "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/MERGE_MSG" &&
if test -f "$NEXT_INDEX"
then
mv "$NEXT_INDEX" "$THIS_INDEX"
diff --git a/git-revert.sh b/git-revert.sh
index 4fd81b6..2e23cf4 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -145,9 +145,18 @@ git-read-tree -m -u --aggressive $base $
result=$(git-write-tree 2>/dev/null) || {
echo >&2 "Simple $me fails; trying Automatic $me."
git-merge-index -o git-merge-one-file -a || {
+ mv -f .msg .git/MERGE_MSG
+ {
+ echo '
+Conflicts:
+'
+ git ls-files --unmerged |
+ sed -e 's/^[^ ]* / /' |
+ uniq
+ } >>"$GIT_DIR/MERGE_MSG"
echo >&2 "Automatic $me failed. After resolving the conflicts,"
echo >&2 "mark the corrected paths with 'git-update-index <paths>'"
- echo >&2 "and commit with 'git commit -F .msg'"
+ echo >&2 "and commit the result."
case "$me" in
cherry-pick)
echo >&2 "You may choose to use the following when making"
--
1.4.3.rc2.g6f09-dirty
^ permalink raw reply related
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: apodtele @ 2006-10-12 21:37 UTC (permalink / raw)
To: Martin Waitz, git
In-Reply-To: <20061012201646.GC10922@admingilde.org>
On 10/12/06, Martin Waitz <tali@admingilde.org> wrote:
> On Thu, Oct 12, 2006 at 03:37:17PM -0400, apodtele wrote:
> > Instead of conditionally scaling the stat graph for large changes,
> > always scale it asymptotically: small changes shall appear without any
> > distortions.
>
> very nice idea!
>
> > + return it * width / (it + width) + 1;
>
> but wouldn't this formula result in at least 1, even for a 0 change?
> Perhaps we'd have to special case an input of 0?
Corrected patch follows.
--- diff.c 2006-10-12 14:45:13.000000000 -0400
+++ diff.c 2006-10-12 17:32:15.000000000 -0400
@@ -637,15 +637,12 @@
const char mime_boundary_leader[] = "------------";
-static int scale_linear(int it, int width, int max_change)
+static int scale_nonlinear(int it, int width)
{
- /*
- * make sure that at least one '-' is printed if there were deletions,
- * and likewise for '+'.
- */
- if (max_change < 2)
- return it;
- return ((it - 1) * (width - 1) + max_change - 1) / (max_change - 1);
+ if (it)
+ return it * width / (it + width) + 1;
+ else
+ return 0;
}
static void show_name(const char *prefix, const char *name, int len,
@@ -776,11 +773,9 @@
adds += add;
dels += del;
- if (width <= max_change) {
- add = scale_linear(add, width, max_change);
- del = scale_linear(del, width, max_change);
- total = add + del;
- }
+ add = scale_nonlinear(add, width / 2);
+ del = scale_nonlinear(del, width / 2);
+ total = add + del;
show_name(prefix, name, len, reset, set);
printf("%5d ", added + deleted);
show_graph('+', add, add_c, reset);
^ permalink raw reply
* Re: [PATCH] Removes the <?xml?> declaration from gitweb.pl
From: Jakub Narebski @ 2006-10-12 21:21 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200610120745.00909.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> onsdag 11 oktober 2006 23:27 skrev Jakub Narebski:
> > Pazu wrote:
> > > The XML declaration forces IE6 into quirks mode, breaking our
> > > nice standards compliant stylesheet.
> >
> > But isn't it _required_ by XML/XHTML?
>
> For pure XML document it is required, but not for XHTML, unless the encoding
> is something other than UTF-8 or (shudder) UTF-16. W3C recommends it though.
So what should be our decision? Honor IE quirks ;-) and either remove
XML declaration, or use Transitional DTD? Add back SPC to conversion
in esc_html? Ignore broken browsers?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Public Gitweb Hosting Service
From: Nico -telmich- Schottelius @ 2006-10-12 21:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060920004828.GI8259@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
Petr Baudis [Wed, Sep 20, 2006 at 02:48:28AM +0200]:
> [long introduction, pasky seems to have too much time, perhaps
> he should investigate more time in gitweb's character problems? ;-)]
>
> http://repo.or.cz/
Very nice service!
In fact I am currently building a oss-site for a small community
called !eof and your repo service looks EXTREMLY interesting!
Will have a look at it at the weekend!
Nico
--
``...if there's one thing about Linux users, they're do-ers, not whiners.''
(A quotation of Andy Patrizio I completely agree with)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* gitweb / kernel.org
From: Nico -telmich- Schottelius @ 2006-10-12 21:08 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Hoi!
Just interested, what's the reason that gitweb is extremly slow
on kernel.org?
Just asking because when I see no problem at
http://unix.schottelius.org/cgi-bin/gitweb.cgi on my
dual xeon 2.4ghz / 1 GiB ram / 100Mbit inet / lighttpd 1.4.13.
Yes, I'll have some thousand less hits than kernel.org, but
simulating load with ab does not show any problem either.
Just interested, what the bottleneck is.
Sincerly
Nico
--
``...if there's one thing about Linux users, they're do-ers, not whiners.''
(A quotation of Andy Patrizio I completely agree with)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] diff: fix 2 whitespace issues
From: Johannes Schindelin @ 2006-10-12 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pu9pjwe.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1781 bytes --]
Hi,
On Thu, 12 Oct 2006, Junio C Hamano wrote:
> I noticed this breakage sometime last week and it was sitting at near
> the bottom of my stack of things to look at.
I actually enjoyed tracking your todo "branch", although lately, there is
substantially less traffic there. Maybe git is finished ;-)
> You mentioned six whitespace problems but I counted only three
> and the test failed on "CR at the end"; the test vector was easy
> to hand-fix thanks to the "index" line.
>
> This patch is an example that we do not want to transmit files
> that has CRs in e-mail. These CRs appear in format-patch
> output, so either the user needs to do --attach (and perhaps the
> option needs to do base64 or qp in such a case) or format-patch
> needs to treat a blob with CR as binary and emit binary diff?
> The latter is not appropriate since patches apply just fine with
> CR in them.
The problem is more likely my (strange) workflow. I never use
git-send-email. Not only because I am a bit wary of the Perl stuff, but
also because I cannot use sendmail directly (some stoopid "firewall"
pretending to fix spamming from %&/%&/ users with their %&"§ infected
Windows machines).
Thus, I used ^R in my venerable patched pine to insert the file, and (just
a guess) pine -- in its infinite wisdom -- decided I'd probably not want
the carriage return, when I put it there on purpose, using my l33t sk1llz.
In hindsight, it might be not _that_ important to test for a carriage
return, but testing _any_ whitespace should do (which I put in also, for
good measure). However, carriage returns from my beloved friends using the
Most Stupid operating system were the reason I hacked in the whitespace
options, and therefore I wanted to test this case specifically.
Ciao,
Dscho
^ permalink raw reply
* Re: Standard cogito + patches: Changes to 'master'
From: Nico -telmich- Schottelius @ 2006-10-12 21:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060924172845.GT20017@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
Petr Baudis [Sun, Sep 24, 2006 at 07:28:45PM +0200]:
> Dear diary, on Fri, Aug 18, 2006 at 08:01:43PM CEST, I got a letter
> where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> said that...
> > nico-linux-git@schottelius.org [Fri, Aug 18, 2006 at 05:54:54PM -0000]:
> > > [Commits]
> >
> > For those who do not know where to find that branch:
> >
> > Gitweb: http://unix.schottelius.org/cgi-bin/gitweb.cgi
> > Git-repo:http://unix.schottelius.org/git/cogito-original.git/
>
> I've decided to bite the bullet wrt. the messy history (since I feel so
> lonely in the Cogito repository ;) and merged it. Thanks! :-)
>
> Is there anything new in the POSIX shell porting mission?
Not yet, still having problems because I moved to another place.
Currently online via notebook directly attached to a ugly zyxel :(
But yes, that'll be finished sometime ;-)
Nico
--
``...if there's one thing about Linux users, they're do-ers, not whiners.''
(A quotation of Andy Patrizio I completely agree with)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: Martin Waitz @ 2006-10-12 20:16 UTC (permalink / raw)
To: apodtele; +Cc: git
In-Reply-To: <d620685f0610121237k458665c5m7bbde2d565d7ef81@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
hoi :)
On Thu, Oct 12, 2006 at 03:37:17PM -0400, apodtele wrote:
> Instead of conditionally scaling the stat graph for large changes,
> always scale it asymptotically: small changes shall appear without any
> distortions.
very nice idea!
> + return it * width / (it + width) + 1;
but wouldn't this formula result in at least 1, even for a 0 change?
Perhaps we'd have to special case an input of 0?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-pickaxe: blame rewritten.
From: Luben Tuikov @ 2006-10-12 20:10 UTC (permalink / raw)
To: Junio C Hamano, Linus Torvalds; +Cc: git
In-Reply-To: <7viripnyfh.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Side note: I do not intend to keep it named pickaxe -- only
> while it is in "pu".
Yes, I was going to mention something about that, but hesitated
and didn't.
What name is a good name? Reuse and old one? "blame", "annotate"?
Luben
^ permalink raw reply
* [PATCH 2/2] diff --stat: clean up unused code
From: apodtele @ 2006-10-12 19:40 UTC (permalink / raw)
To: git
Clean up unused code.
Signed-off-by: Alexei Podtelezhnikov
--- diff.c 2006-10-12 15:07:30.000000000 -0400
+++ diff.c 2006-10-12 15:17:15.000000000 -0400
@@ -660,8 +660,8 @@
static void show_stats(struct diffstat_t* data, struct diff_options *options)
{
- int i, len, add, del, total, adds = 0, dels = 0;
- int max_change = 0, max_len = 0;
+ int i, len, add, del, adds = 0, dels = 0;
+ int max_len = 0;
int total_files = data->nr;
int width, name_width;
const char *reset, *set, *add_c, *del_c;
@@ -706,8 +706,6 @@
if (file->is_binary || file->is_unmerged)
continue;
- if (max_change < change)
- max_change = change;
}
/* Compute the width of the graph part;
@@ -718,10 +716,7 @@
* and width is the width of the graph area.
*/
name_width = (name_width < max_len) ? name_width : max_len;
- if (width < (name_width + 10) + max_change)
- width = width - (name_width + 10);
- else
- width = max_change;
+ width = width - (name_width + 10);
for (i = 0; i < data->nr; i++) {
const char *prefix = "";
@@ -766,13 +761,11 @@
*/
add = added;
del = deleted;
- total = add + del;
adds += add;
dels += del;
add = scale_nonlinear(add, width / 2);
del = scale_nonlinear(del, width / 2);
- total = add + del;
show_name(prefix, name, len, reset, set);
printf("%5d ", added + deleted);
show_graph('+', add, add_c, reset);
^ permalink raw reply
* [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: apodtele @ 2006-10-12 19:37 UTC (permalink / raw)
To: git
Instead of conditionally scaling the stat graph for large changes,
always scale it asymptotically: small changes shall appear without any
distortions.
Signed-off-by: Alexei Podtelezhnikov
--- diff.c 2006-10-12 14:45:13.000000000 -0400
+++ diff.c 2006-10-12 15:07:30.000000000 -0400
@@ -637,15 +637,9 @@
const char mime_boundary_leader[] = "------------";
-static int scale_linear(int it, int width, int max_change)
+static int scale_nonlinear(int it, int width)
{
- /*
- * make sure that at least one '-' is printed if there were deletions,
- * and likewise for '+'.
- */
- if (max_change < 2)
- return it;
- return ((it - 1) * (width - 1) + max_change - 1) / (max_change - 1);
+ return it * width / (it + width) + 1;
}
static void show_name(const char *prefix, const char *name, int len,
@@ -776,11 +770,9 @@
adds += add;
dels += del;
- if (width <= max_change) {
- add = scale_linear(add, width, max_change);
- del = scale_linear(del, width, max_change);
- total = add + del;
- }
+ add = scale_nonlinear(add, width / 2);
+ del = scale_nonlinear(del, width / 2);
+ total = add + del;
show_name(prefix, name, len, reset, set);
printf("%5d ", added + deleted);
show_graph('+', add, add_c, reset);
^ permalink raw reply
* Re: [PATCH] git-pickaxe: blame rewritten.
From: Luben Tuikov @ 2006-10-12 19:31 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7v7iz5rk4b.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Currently it does what git-blame does, but only faster.
>
> More importantly, its internal structure is designed to support
> content movement (aka cut-and-paste) more easily by allowing
> more than one paths to be taken from the same commit.
Good work.
> I have given only cursory check to its output (some files are
> blamed slightly differently from how git-blame does), but it
Details? How differently?
> appears that there is no major breakage. You can see for
> example try annotating builtin-apply.c starting from v1.4.0;
> there are two differences, which pickaxe assigns blame to older
> commits and both of them seem to be sensible.
Renames are naturally supported?
> diff --git a/Documentation/git-pickaxe.txt b/Documentation/git-pickaxe.txt
> new file mode 100644
> index 0000000..7f30cdf
> --- /dev/null
> +++ b/Documentation/git-pickaxe.txt
> @@ -0,0 +1,104 @@
> +git-pickaxe(1)
> +==============
> +
> +NAME
> +----
> +git-pickaxe - Show what revision and author last modified each line of a file
[...]
> +THE PORCELAIN FORMAT
> +--------------------
> +
Let's quantify the output:
---cut---
The porcelain format is as follows:
<SHA-1> <orig line> <line> [<num lines>
author <name>
author-mail <email format>
author-time <time>
author-tz <TZ>
committer <name>
committer-mail <email format>
committer-time <time>
committer-tz <TZ>
filename <string>
summary <string>]
<TAB><line data>
Where
<SHA-1> is the SHA-1 of the commit which introduces this line.
<orig line> it the line number where this line is introduced.
<line> is the line number of the final file (at SHA-1 commit)
Then, if <SHA-1> is different from the previous line's SHA-1 (if no
previous then always different), a header follows. It starts by the
number of lines that this <SHA-1> commit introduces, then on a new
line, information about about the commit is printed for the following
seveal lines, then newline, TAB, and the line data.
If, OTOH, <SHA-1> is the same as the previous line's <SHA-1> then the
header is not printed as indicated by brackets. Just newline,
TAB, and the line data.
---cut----
This kind of makes it slightly clearer.
Junio, is it possible to also print the "previous" commit?
I mean, is it tenable to print the commit such that
a "git-diff C B -- A:file" will give a diff of the block of lines
we're looking at?
Picture:
Annotate A:file
C B line 1
X D line 2
C B line 3
F G line 4
...
Currently we do not print "C, X, F", but only "B, D, G".
So in effect, <orig line> is the line of, wlg, "C:file"
where line 1 was introduced (by commit B). I.e.
the "parent" commit of that commit, which doesn't always
exist. (e.g. if the commit added the file)
Is this tenable? If it is not or if it is going to make
it slow or ambiguous, lets forget about it.
Luben
^ permalink raw reply
* Re: [PATCH] git-pickaxe: blame rewritten.
From: Junio C Hamano @ 2006-10-12 19:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610120854440.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, could we please get rid of this horrible command line syntax.
>
> Pretty much _every_ other git command takes the form
>
> git cmd [<rev>] [--] <path>
>
> but for some reason annotate and blame (and now pickaxe) do it the wrong
> way around, and do
>
> git cmd [--] <path> [<rev>]
>
> which is just irritating to somebody who has grown very used to being able
> to specify revisions first.
Side note: I do not intend to keep it named pickaxe -- only
while it is in "pu".
I think we could support all of them to retain backward
compatibility:
git blame [-options] <path> [<rev>] (*1*)
git blame [-options] -- <path> [<rev>] (*2*)
git blame [-options] [<rev>] [--] <path> (*3*)
(*1*) Only for path that does not start with a '-'; we should
tighten the input to make sure <path> lstat()'s fine
(which we currently do with pickaxe), <path> cannot be
interpreted as a valud rev, and when <rev> is given, <rev>
does not lstat() Ok, to avoid ambiguity. Other cases we
should require the newer format with explicit -- (*3*).
(*2*) Backward compatible canoncal format. The above comment
for validation does not apply, as (*3*) never has more
than one path for 'annotate/blame/pickaxe'
(*3*) The canonical format for ohter git commands. Without
an explicit --, <rev> should not lstat() Ok, and <path>
should, to avoid ambiguity.
> (I'd actually also like to have a range-modifier, so that I could do
>
> git annotate --since=2.weeks.ago v2.6.18.. <path>
>
> that didn't go back beyond a certain point,...
I am not sure about revision bottom (v.2.6.18..) offhand, but
the age limit (--since=2.weeks) should be trivial.
Inside pass_blame() while we iterate over the parents of the
suspect we are looking at, you can skip the parent if it is
older than the age limit, or an ancestor of revision bottom,
like this:
--- l/builtin-pickaxe.c
+++ k/builtin-pickaxe.c
@@ -450,6 +450,12 @@ static void pass_blame(struct scoreboard
parent = parent->next, parent_ix++) {
if (parse_commit(parent->item))
continue;
+
+ if (parent is older than age limit)
+ continue;
+ if (parent is an ancestor of revision bottom)
+ continue;
+
porigin = find_origin(sb, parent->item, origin->path);
if (!porigin)
porigin = find_rename(sb, parent->item, origin);
I think we can get away by checking if the parent _is_ the
revision bottom (or one of the bottoms, if you say "--not
v2.6.18 v2.6.17.13") instead of doing "is it an ancestor" check,
in practice. But that is not correct when a merge is involved.
^ permalink raw reply
* Re: cg-commit does not run pre-commit hook?
From: Linus Torvalds @ 2006-10-12 17:20 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Andreas Ericsson, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0610120957460.3952@g5.osdl.org>
On Thu, 12 Oct 2006, Linus Torvalds wrote:
>
> Why? That's just stupid.
Btw, let me explain that strong statement, because it _is_ a strong
statement, but it's true.
The problem with trying to generate a changelog entry at commit time is
that it is fundamentally a broken concept in a distributed environment.
What happens at a merge event? Sure, you can have special merge magic to
try to sort out the mess, but it _is_ a mess. You can make things "work",
but you can never actually make the result really make _sense_. The
changelog is fundamentally a serialization of something that wasn't
serial.
Now, the same serialization problem obviously exists when you
auto-generate the changelog file when doing a release tar-ball or
something like that, but at that point you basically "fix" it in time, so
at that point the changelog actually makes sense.
It also turns out that in many situations, you can sort the result in
other ways: the shortlog format, for example, is often superior to the
default "git log" ordering, just because sorting things by person tends to
actually result in a better view of what changed (it tells you something
new: clumping by author not onyl tends to clump similar commits together
and thus tell more of a "story", but it also has the added advantage of
telling people who does what).
Generating things after-the-fact would also allow ordering things by what
files (or subdirectories) they touch, although we've never done such a
script. I do that quite often privately by just restricting the log to
certain subsystems, though, and it's a damn useful thing to have. I would
not be surprised at all if it might make sense to actually do a "tar-ball"
changelog that way for certain projects - especially if they have clearly
separated sub-components.
[ Btw, this whole "do things by pathname" has been so successful, that
I've come to realize that I would probably never accept an SCM that
doesn't allow something like that. Being able to do
gitk some/random/set of/directories and/files
is just _incredibly_ useful. Maybe others don't do it as much as I do,
but as a top-level maintainer, being able to look at history from the
viewpoint of just a random subset of the tree is incredibly powerful.
I very strongly suspect that doing logs that way is often a good idea
too. ]
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox