* Re: [PATCH] git-pickaxe: blame rewritten.
From: Junio C Hamano @ 2006-10-13 21:38 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061013205418.5087.qmail@web31803.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> 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?
>
> The parent commit.
There is no single "the parent commit" in general. Which side
of the merge would you take?
Also remeber, when we blame a line to a revision (unless we do
not limit the blame with v2.6.18.. and --since=2.weeks which
only git-pickaxe can do), the line is known to have been
introduced by _that_ commit. If there were a corresponding line
in "the parent commit" for that line, we would not have assigned
the blame to the commit, but the blame would have been passed
down to "the parent commit" already.
^ permalink raw reply
* Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset
From: Jakub Narebski @ 2006-10-13 21:29 UTC (permalink / raw)
To: git
In-Reply-To: <7v64endi6x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> So how about
>
> [core]
> repackUseDeltaBase = true
+1, but I'd rather first it default to false.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset
From: Junio C Hamano @ 2006-10-13 21:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610130912500.2435@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Thu, 12 Oct 2006, Junio C Hamano wrote:
>
>> This new option makes the resulting pack express the delta base
>> with more compact "offset" format.
>
> Actually I thought about making it the default whenever git-pack-objects
> supported it, and use a negative option with git-repack to disable it
> instead.
>
> The fact is that there is little reason for not using delta base offsets
> in most cases and specifying -b all the time would become more of an
> annoyance.
>
> What do you think?
The only time it matters is if the packs in repository being
repacked needs to be readable by older git, which I think is
only when somebody with older git uses commit walkers to
download the pack into a remote repository to use. Using or not
using delta-base-offset is tied to each repository, and in a
sense that is similar to "repository format version".
So how about
[core]
repackUseDeltaBase = true
^ permalink raw reply
* Re: [PATCH] git-pickaxe: blame rewritten.
From: Luben Tuikov @ 2006-10-13 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz81kwh3.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> 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?
The parent commit.
For example,
Annotation/blame of A:File
C 1 line 1
2 line 2
D 3 line 3
B 4 line 4
The parent commit of C, such that,
git-diff parent(C) C -- A:File
will give me the diff which introduced
the "first block", or more generally,
all lines annotated with C.
Then when I click on 1 or 2, I'd like to
see Annotation/blame of parent(C):File,
on the line number where the C "block" was
introduced.
Luben
^ permalink raw reply
* Re: [PATCH] git-pickaxe: blame rewritten.
From: Junio C Hamano @ 2006-10-13 20:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7viripnyfh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> (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);
>
This is not quite right. The above code tries to avoid passing
blames to the boundary revisions, so "v2.6.18.." makes every old
line to be blamed on one revision after v2.6.18, which might be
technically correct but not what we want.
Instead, we should pass blame, and then prevent boundary
revisions to pass blame further down. The code in "pu" today
has seen slight restructure of this part and this change should
be easier to implement there, something along the lines of...
--- l/builtin-pickaxe.c
+++ k/builtin-pickaxe.c
@@ -450,8 +450,7 @@ static int pass_blame_to_parent(struct s
}
#define MAXPARENT 16
-static void pass_blame(struct scoreboard *sb, struct origin *origin,
- struct rev_info *revs)
+static void pass_blame(struct scoreboard *sb, struct origin *origin)
{
int i, parent_ix;
struct commit *commit = origin->commit;
@@ -469,10 +468,6 @@ static void pass_blame(struct scoreboard
if (parse_commit(p))
continue;
- if (p->object.flags & UNINTERESTING)
- continue;
- if (revs->max_age != -1 && p->date < revs->max_age)
- continue;
porigin = find_origin(sb, parent->item, origin->path);
if (!porigin)
@@ -516,6 +511,7 @@ static void assign_blame(struct scoreboa
while (1) {
int i;
struct origin *suspect = NULL;
+ struct commit *commit;
/* find one suspect to break down */
for (i = 0; !suspect && i < sb->num_entries; i++) {
@@ -525,7 +521,10 @@ static void assign_blame(struct scoreboa
if (!suspect)
return; /* all done */
- pass_blame(sb, suspect, revs);
+ commit = suspect->commit;
+ if (!(commit->object.flags & UNINTERESTING) &&
+ !(revs->max_age != -1 && commit->date < revs->max_age))
+ pass_blame(sb, suspect, revs);
/* Take responsibility for the remaining entries */
for (i = 0; i < sb->num_entries; i++)
^ permalink raw reply
* Re: git-svnimport and tags
From: Petr Baudis @ 2006-10-13 20:15 UTC (permalink / raw)
To: Nicolas Stroppa; +Cc: git
In-Reply-To: <452FA667.1060003@computing.dcu.ie>
Hello,
Dear diary, on Fri, Oct 13, 2006 at 04:44:55PM CEST, I got a letter
where Nicolas Stroppa <nstroppa@computing.dcu.ie> said that...
> A small report. (I am using cogito-0.18 and git 1.4.2.3.)
> I have imported an SVN project using git-svnimport.
> This project has several tags. Here is what I get with one the tags.
>
> tricatel $ git-cat-file tag `cat .git/refs/tags/alanis-0.9.4`
> object [...]
> type commit
> tag alanis-0.9.4
> tagger nico <nico>
>
>
> If I do the same thing on a git repository created from scratch, I get:
>
> tricatel $ git-cat-file tag `cat .git/refs/tags/alanis-0.9.4`
> object [...]
> type commit
> tag alanis-0.9.4
> tagger nico <nico@[...]> 1160736694 +0100
>
> The date information is missing in the first case, which confuses
> cg-tag-show:
> tricatel $ cg-tag-show alanis-0.9.4
> [...]
> cg-Xlib: line 215: nico <n (nic * 3600 + co> * 60):
> syntax error in expression (error token is "(nic * 3600 + co> * 60)")
>
> I don't know if cg-tag-show should be more robust or if the date
> information should be in the tag.
I think git-svnimport is broken here, the tagger line is clearly
defined that it must contain the time specification. And git-mktag is
broken as well since the verification of that line is a TODO so we let
the user put any garbage there.
--
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: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-10-13 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7rlq2aq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This is only lightly tested. I haven't done test suite nor
> documentation, which the list should be able to take care of,
> now my git day for this week is over ;-).
>
> -- >8 --
> [PATCH] diff --numstat
Does for example
git diff-tree --numstat --patch-with-stat <tree-ish>
or
git diff-tree --numstat -p <tree-ish>
work as expected, i.e. prepend diffstat in machine friendly (numstat)
format? What happens if one uses both --stat and --numstat?
-- >8 --
Documenting diff --numstat
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Is it enough documentation? Should we provide also numstat format
description in Documentation/diff-format.txt?
Documentation/diff-options.txt | 5 +++++
diff.h | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 7b7b9e8..e112172 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -16,6 +16,11 @@
The width of the filename part can be controlled by
giving another width to it separated by a comma.
+--numstat::
+ Similar to \--stat, but shows number of added and
+ deleted lines in decimal notation and pathname without
+ abbreviation, to make it more machine friendly.
+
--summary::
Output a condensed summary of extended header information
such as creations, renames and mode changes.
diff --git a/diff.h b/diff.h
index 435c70c..ce3058e 100644
--- a/diff.h
+++ b/diff.h
@@ -171,6 +171,7 @@ #define COMMON_DIFF_OPTIONS_HELP \
" --patch-with-raw\n" \
" output both a patch and the diff-raw format.\n" \
" --stat show diffstat instead of patch.\n" \
+" --numstat show numeric diffstat instead of patch.\n" \
" --patch-with-stat\n" \
" output a patch and prepend its diffstat.\n" \
" --name-only show only names of changed files.\n" \
--
Jakub Narebski
Poland
^ permalink raw reply related
* RE: git-svn and u-boot broken.
From: Joakim Tjernlund @ 2006-10-13 19:43 UTC (permalink / raw)
To: 'Randal L. Schwartz'; +Cc: git
In-Reply-To: <86slhsgg3f.fsf@blue.stonehenge.com>
>
> >>>>> "Joakim" == Joakim Tjernlund
> <joakim.tjernlund@transmode.se> writes:
>
> Joakim> First, I had to change this (from memory) in git-svn:
> Joakim> my $got = SVN::TxDelta::send_stream($fh, @$atd,
> $self->{pool});
> Joakim> to
> Joakim> my $got;
> Joakim> if ( $got ) {
> Joakim> $got = SVN::TxDelta::send_stream($fh, @$atd,
> $self->{pool});
> Joakim> } else {
> Joakim> $got = $exp
> Joakim> }
> Joakim> I am no perl programmer so please change as you se fit.
>
> That doesn't make any sense. You'll never run the if-true
> branch there.
> The value of $got immediately following "my $got;" is always undef.
Typo, should be 'if( $atd )', sorry
^ permalink raw reply
* Re: git-svn and u-boot broken.
From: Randal L. Schwartz @ 2006-10-13 19:39 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <00ad01c6eefc$84298280$1267a8c0@Jocke>
>>>>> "Joakim" == Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
Joakim> First, I had to change this (from memory) in git-svn:
Joakim> my $got = SVN::TxDelta::send_stream($fh, @$atd, $self->{pool});
Joakim> to
Joakim> my $got;
Joakim> if ( $got ) {
Joakim> $got = SVN::TxDelta::send_stream($fh, @$atd, $self->{pool});
Joakim> } else {
Joakim> $got = $exp
Joakim> }
Joakim> I am no perl programmer so please change as you se fit.
That doesn't make any sense. You'll never run the if-true branch there.
The value of $got immediately following "my $got;" is always undef.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* git-svn and u-boot broken.
From: Joakim Tjernlund @ 2006-10-13 19:19 UTC (permalink / raw)
To: git
I am trying to create a SVN tree using git-svn from the u-boot git tree and it doesn't work.
First, I had to change this (from memory) in git-svn:
my $got = SVN::TxDelta::send_stream($fh, @$atd, $self->{pool});
to
my $got;
if ( $got ) {
$got = SVN::TxDelta::send_stream($fh, @$atd, $self->{pool});
} else {
$got = $exp
}
I am no perl programmer so please change as you se fit.
Secondly I ran out of open file descriptors which I "fixed" with ulimit -n 10000, maybe there is a leak
in git-svn?
Then it still failed, but this I could not fix. Don't have the error msg atm as I am home now, but
it should be easy enough to reproduce, just clone current u-boot tree and try :)
What I really would like to do is merge all u-boot commits up to a point into one commit
and then commit that single git commit to a clean SVN repo. Then I want merge the
remaining git commits(my own stuff).
Tried to import a tar tree into the SVN repo with svn import and then merge
the remain commits on top of that using git-svn but that didn't work, lots of conflicts.
Jocke
^ permalink raw reply
* Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset
From: Nicolas Pitre @ 2006-10-13 18:29 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Junio C Hamano, GIT Mailing List
In-Reply-To: <200610131805.k9DI5QDH016016@laptop13.inf.utfsm.cl>
On Fri, 13 Oct 2006, Horst H. von Brand wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > This new option makes the resulting pack express the delta base
> > with more compact "offset" format.
> >
> > Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> [...]
>
> > @@ -35,6 +35,12 @@ OPTIONS
> > about people fetching via dumb protocols from it. Use
> > with '-d'.
> >
> > +-b::
> > + Pass the `--delta-base-offset` to `git pack-objects`;
> > + see gitlink:git-pack-objects[1]. Do not use this option
> > + if you want the repository to be accessible by older
> > + versions of git.
> > +
>
> Need to tell which version is the cutoff (say before 1.4.3 won't work).
Before and including 1.4.3 actually.
Oh and the description should be augmented with "... if you want the
repository to be accessible by older versions of git when _not_ using
the native GIT protocol." as the native protocol is able to select
between either format on the fly regardless of the on-disk pack format.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset
From: Horst H. von Brand @ 2006-10-13 18:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing List, Nicolas Pitre
In-Reply-To: <11607177024171-git-send-email-junkio@cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> This new option makes the resulting pack express the delta base
> with more compact "offset" format.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
[...]
> @@ -35,6 +35,12 @@ OPTIONS
> about people fetching via dumb protocols from it. Use
> with '-d'.
>
> +-b::
> + Pass the `--delta-base-offset` to `git pack-objects`;
> + see gitlink:git-pack-objects[1]. Do not use this option
> + if you want the repository to be accessible by older
> + versions of git.
> +
Need to tell which version is the cutoff (say before 1.4.3 won't work).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [PATCH] Removes the <?xml?> declaration from gitweb.pl
From: Jakub Narebski @ 2006-10-13 15:09 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200610131605.56913.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> torsdag 12 oktober 2006 23:21 skrev Jakub Narebski:
>> 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?
>
> It isn't required by the standard. Why not just drop it?
>From http://www.w3.org/TR/xhtml1/#docconf
An XML declaration is not required in all XML documents; however XHTML
document authors are strongly encouraged to use XML declarations in all
their documents. Such a declaration is required when the character
encoding of the document is other than the default UTF-8 or UTF-16 and
no encoding was determined by a higher-level protocol.
So even if it is not required, it is recommended. But yes, removing
<?xml?> for bug-compatibility conformance is better idea than mucking
with browser detection... if we sould need browser detection to avoid
other bugs (like non-W3C CSS box model in IE), then perhaps we could
reintroduce <?xml?> in standards-conforming browsers.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Removes the <?xml?> declaration from gitweb.pl
From: Robin Rosenberg @ 2006-10-13 14:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610122321.18630.jnareb@gmail.com>
torsdag 12 oktober 2006 23:21 skrev Jakub Narebski:
> 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?
It isn't required by the standard. Why not just drop it?
-- robin
^ permalink raw reply
* git-svnimport and tags
From: Nicolas Stroppa @ 2006-10-13 14:44 UTC (permalink / raw)
To: git
Hello,
A small report. (I am using cogito-0.18 and git 1.4.2.3.)
I have imported an SVN project using git-svnimport.
This project has several tags. Here is what I get with one the tags.
tricatel $ git-cat-file tag `cat .git/refs/tags/alanis-0.9.4`
object [...]
type commit
tag alanis-0.9.4
tagger nico <nico>
If I do the same thing on a git repository created from scratch, I get:
tricatel $ git-cat-file tag `cat .git/refs/tags/alanis-0.9.4`
object [...]
type commit
tag alanis-0.9.4
tagger nico <nico@[...]> 1160736694 +0100
The date information is missing in the first case, which confuses
cg-tag-show:
tricatel $ cg-tag-show alanis-0.9.4
[...]
cg-Xlib: line 215: nico <n (nic * 3600 + co> * 60):
syntax error in expression (error token is "(nic * 3600 + co> * 60)")
I don't know if cg-tag-show should be more robust or if the date
information should be in the tag.
Cheers,
nicolas
--
_____________________________________________________________
/
| Nicolas Stroppa - nstroppa@computing.dcu.ie - +353-1-7006912
| School of Computing, Dublin City University,
| Glasnevin, Dublin 9, Ireland.
| http://www.computing.dcu.ie/~nstroppa
\_____________________________________________________________
^ permalink raw reply
* Re: [PATCH] Removes the <?xml?> declaration from gitweb.pl
From: Pazu @ 2006-10-13 14:09 UTC (permalink / raw)
To: git
In-Reply-To: <ego331$568$2@sea.gmane.org>
Jakub Narebski wrote:
> Well, there is yet another solution. Do browser detection, and do not output
> <?xml ... ?> declaration for IE. Perhaps that would be best solution.
Well, there's now drawback in removing the XML declaration (no browser
requires it), so why even worry about browser detection?
-- Marcus
^ permalink raw reply
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: apodtele @ 2006-10-13 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlknlmc9y.fsf@assigned-by-dhcp.cox.net>
On 10/12/06, Junio C Hamano <junkio@cox.net> wrote:
> 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.
> 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
>
> For obvious reasons, the total length of A and B exceeds half of
> C, which looks quite misleading.
>
> A | ++++++++++++--------
> B | ++++++++------------
> C | +++++++++++++++---------------
Before my patch is completely forgotten, let me critique the current
approach. Currently everything is great and beautiful unless one
particular change adds a couple of hundred lines, say, to a man page.
With large changes in play, small changes are squashed to a single
character. Would you argue that this scenario correctly represent
importance of man pages? Would you say, that it's not misleading that
1-, 2-, and 5-liners all look the same as long as a man page is
prominently shown? Moreover, 1-, 2-, and 5- liners may look different
depending on the size of that man page. The current approach is not
invariant; it is, however, normalized as needed. "Normalized" is good,
"as needed" is bad.
With asymptotic scaling, 1-, 2-, and 5- liners are correctly
represented by a correct number of characters, regardless of the size
of that man page. 10- and 20- liners are _slightly_ distorted. I
cannot stress it more: the representation will not depend on the size
of changes in other files! You will be able to tell where truly large
changes happened too! The price for this is that you won't be able to
precisely compare the sizes of added man pages.
It is your choice...
^ permalink raw reply
* Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset
From: Jakub Narebski @ 2006-10-13 13:51 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610130912500.2435@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 12 Oct 2006, Junio C Hamano wrote:
>
>> This new option makes the resulting pack express the delta base
>> with more compact "offset" format.
>
> Actually I thought about making it the default whenever git-pack-objects
> supported it, and use a negative option with git-repack to disable it
> instead.
>
> The fact is that there is little reason for not using delta base offsets
> in most cases and specifying -b all the time would become more of an
> annoyance.
Perhaps we should leave it to configuretion variable, instead?
And turn the new format on by default, like core.legacyHeaders
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: Andy Whitcroft @ 2006-10-13 13:31 UTC (permalink / raw)
To: apodtele; +Cc: Nicolas Pitre, A Large Angry SCM, Martin Waitz, git
In-Reply-To: <d620685f0610130625o2d5f70c5p7cb41f567093df32@mail.gmail.com>
apodtele wrote:
> Hi!
>
> On 10/12/06, Nicolas Pitre <nico@cam.org> wrote:
>> On Thu, 12 Oct 2006, A Large Angry SCM wrote:
>> > Martin Waitz wrote:
>> > > 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...
>> > >
>> >
>> > OK:
>> > return (it * width + (it + width)/2)) / (it + width - 1)
>> >
>> > Now it's back at 4. ;-)
>>
>> Sure, but at this point the original conditional is probably more
>> efficient.
>>
>
> Don't make me use
> return it * width / (it + width) + !!it;
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
return it * width / (it + width) + (it != 0)
Perhaps?
-apw
^ permalink raw reply
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: apodtele @ 2006-10-13 13:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: A Large Angry SCM, Martin Waitz, git
In-Reply-To: <Pine.LNX.4.64.0610122038330.2435@xanadu.home>
Hi!
On 10/12/06, Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 12 Oct 2006, A Large Angry SCM wrote:
> > Martin Waitz wrote:
> > > 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...
> > >
> >
> > OK:
> > return (it * width + (it + width)/2)) / (it + width - 1)
> >
> > Now it's back at 4. ;-)
>
> Sure, but at this point the original conditional is probably more
> efficient.
>
Don't make me use
return it * width / (it + width) + !!it;
^ permalink raw reply
* Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset
From: Nicolas Pitre @ 2006-10-13 13:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing List
In-Reply-To: <11607177024171-git-send-email-junkio@cox.net>
On Thu, 12 Oct 2006, Junio C Hamano wrote:
> This new option makes the resulting pack express the delta base
> with more compact "offset" format.
Actually I thought about making it the default whenever git-pack-objects
supported it, and use a negative option with git-repack to disable it
instead.
The fact is that there is little reason for not using delta base offsets
in most cases and specifying -b all the time would become more of an
annoyance.
What do you think?
Nicolas
^ permalink raw reply
* Re: [PATCH] Removes the <?xml?> declaration from gitweb.pl
From: Jakub Narebski @ 2006-10-13 13:07 UTC (permalink / raw)
To: git
In-Reply-To: <ego2nk$3nm$1@sea.gmane.org>
Pazu wrote:
> Jakub Narebski wrote:
>
>> 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?
>
> My bad here. In my first email I said that using the Transitional DTD
> would fix the problem, but I was wrong. It doesn't matter the DTD you
> use, if you add a <?xml?> declaration, IE will get it wrong and activate
> quirks mode.
Well, there is yet another solution. Do browser detection, and do not output
<?xml ... ?> declaration for IE. Perhaps that would be best solution.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-fetch: Allow branch."branchname".remote=.
From: Jakub Narebski @ 2006-10-13 13:06 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0610131448390.14200@wbgn013.biozentrum.uni-wuerzburg.de>
<opublikowany i wysłany>
Johannes Schindelin wrote:
> On Fri, 13 Oct 2006, Jakub Narebski wrote:
>
>> Johannes Schindelin wrote:
>>
>> > There is a subtle problem here. Up until now, "remote" meant a short cut.
>> > You either had a file with that name in .git/remotes/ or .git/branches, or
>> > an entry in the config (remote.<name>.url).
>>
>> Not exactly. "git-pull . <branch>" and "git-peek-remote ." meant use
>> _current_ repository. "." as remote name means "current", i.e. local
>> repository.
>
> From Documentation/git-pull.txt:
>
> SYNOPSIS
> --------
> 'git-pull' <options> <repository> <refspec>...
>
> It says "repository", not "remote". As for the name "git-peek-remote":
> yes, it is a short cut for "remote repository".
>
> The thing is, if you say you pull "from a remote", then it is not
> sufficient to specify just a URL of a repository. You also have to specify
> a branch.
O.K. "remote" = "repository + set of branches". But we can say that "."
is a default remote, which points to local repository (".") and has
no branches information.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Removes the <?xml?> declaration from gitweb.pl
From: Pazu @ 2006-10-13 13:01 UTC (permalink / raw)
To: git
In-Reply-To: <200610122321.18630.jnareb@gmail.com>
Jakub Narebski wrote:
> 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?
My bad here. In my first email I said that using the Transitional DTD
would fix the problem, but I was wrong. It doesn't matter the DTD you
use, if you add a <?xml?> declaration, IE will get it wrong and activate
quirks mode.
-- Marcus
^ permalink raw reply
* Re: t4015-diff-whitespace broken on cygwin's bash
From: Johannes Schindelin @ 2006-10-13 12:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0610130212uca8371fg92db5081a8175cb3@mail.gmail.com>
Hi,
On Fri, 13 Oct 2006, Alex Riesen wrote:
> It seem to cut off the last CR from text-here. I.e.
>
> cat <<EOF >x
> ...
> CR at end^M
> EOF
>
> becomes just "CR at end" in the output file, that is ^M (aka CR) stripped.
I can confirm this problem. Strange. I always thought that "cat << EOF"
was meant to copy verbatim. I think it is a bug in cygwin.
The only sensible workaround I can think of is to put the files into a
directory t4015/ like t4013 does.
Ciao,
Dscho
^ 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