* Re: Closing the merge window for 1.6.0
From: Nicolas Pitre @ 2008-07-14 17:54 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Johannes Schindelin, Petr Baudis, Junio C Hamano, git
In-Reply-To: <20080714124109.25414.qmail@06d015ec9c6744.315fe32.mid.smarden.org>
On Mon, 14 Jul 2008, Gerrit Pape wrote:
> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > I'm saying this because I believe the best conservative upper bound for
> > > backwards compatibility is Git version in Debian stable. It gets
> > > probably the most stale from all the widely used software distributions
> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > > fails miserably on the new packs.
> >
> > Can't we just hit Debian's Git maintainer with a clue bat or a bus,
>
> Please don't. It wouldn't help, rather the opposite I think, espacially
> the bus. We don't introduce new upstream versions into a Debian stable
> release, there's a great effort done for each stable release to reach
> high quality integration of all the software packages available in
> Debian. Once that status is reached, only security fixes and criticial
> usability fixes are added.
Please consider it as a critical usability problem.
Maybe we can release 1.4.5 with the ability to read index v2? That
wouldn't be hard to backport the reading part of it.
Nicolas
^ permalink raw reply
* Re: [git pull] core/softirq for v2.6.27
From: Linus Torvalds @ 2008-07-14 17:46 UTC (permalink / raw)
To: Andrew Morton, Junio C Hamano
Cc: Ingo Molnar, Git Mailing List, Thomas Gleixner
In-Reply-To: <alpine.LFD.1.10.0807141019010.3305@woody.linux-foundation.org>
On Mon, 14 Jul 2008, Linus Torvalds wrote:
>
> Some really ugly scripting like this will do it:
>
> #!/bin/sh
> git log --pretty='format:commit %H
> Author: %an <%ae>
Side note: you can make it a one-liner with '%n' (not \n') if you want, ie
#!/bin/sh
git log --pretty='format:commit %H%nAuthor: %an <%ae>%n%n %s (%h)%n' $@ | git shortlog
if you want to make it look even more like line noise.
And if you want to be _really_ fancy, you can even make it a git
alias. Just add somethign like this to your ~/.gitconfig file:
[alias]
mylog=!GIT_PAGER='git --no-pager shortlog' git log --pretty='format:commit %H%nAuthor: %an <%ae>%n%n %s (%h)%n'
which is the _real_ git-mans way to do it.
It does the "shortlog" output by using "git shortlog" as a pager, but then
to avoid recursion, we have to turn off paging of shortlog output itself.
Heh. And the reason to do that is that the arguments always go to the end,
so since we want to give the args to "git log", we can't put the pipe at
the end.
I will have to go wash up after writing the above.
Linus
^ permalink raw reply
* Re: [git pull] core/softirq for v2.6.27
From: Johannes Schindelin @ 2008-07-14 17:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Junio C Hamano, Ingo Molnar, Git Mailing List,
Thomas Gleixner
In-Reply-To: <alpine.LFD.1.10.0807141019010.3305@woody.linux-foundation.org>
Hi,
On Mon, 14 Jul 2008, Linus Torvalds wrote:
> git log --pretty='format:commit %H
> Author: %an <%ae>
>
> %s (%h)
> ' $@ | git shortlog
Surely you meant
git log --pretty='format:commit %H%nAuthor: %an <%ae>%n%n %s (%h)' \
$@ | git shortlog
Note that I do not think it would be all that hard to teach shortlog the
--pretty option.
Ciao,
Dscho
^ permalink raw reply
* Re: [git pull] core/softirq for v2.6.27
From: Linus Torvalds @ 2008-07-14 17:23 UTC (permalink / raw)
To: Andrew Morton, Junio C Hamano
Cc: Ingo Molnar, Git Mailing List, Thomas Gleixner
In-Reply-To: <alpine.LFD.1.10.0807140948220.3305@woody.linux-foundation.org>
On Mon, 14 Jul 2008, Linus Torvalds wrote:
>
> As it is, that is one ugly function that only takes the one-liner thing -
> at least partly because of how it traditionally worked (as a a filter over
> the log messages, rather than as a "git shortlog xyz..abc" kind of
> stand-alone thing).
Heh. I guess you _could_ use the filter capability here (but it will
sometimes truncate the line, so..)
Some really ugly scripting like this will do it:
#!/bin/sh
git log --pretty='format:commit %H
Author: %an <%ae>
%s (%h)
' $@ | git shortlog
where we use the regular "git log" with a user-supplied format to generate
a log with the subject line and the shortened hash appended (the "%s (%h)"
part) and then we use "git shortlog" as a filter to sort things together
by author etc.
There is absolutely _nothing_ that git won't do with a little bit of
scripting, but I do have to admit that this one isn't a wonderfully
beautiful script ;)
Linus
^ permalink raw reply
* Re: [git pull] core/softirq for v2.6.27
From: Linus Torvalds @ 2008-07-14 17:11 UTC (permalink / raw)
To: Andrew Morton, Junio C Hamano
Cc: Ingo Molnar, Git Mailing List, Thomas Gleixner
In-Reply-To: <20080714094422.e7ae255a.akpm@linux-foundation.org>
On Mon, 14 Jul 2008, Andrew Morton wrote:
>
> This was a git-shortlog feature request ;)
Heh. You should cc git or Junio if so.
The way shortlog is done (very different from regular logs, due to the
whole organize-by-name etc thing) that is sadly pretty ugly to do: we
don't support the pretty-formats etc. And the way things are done, adding
support for the generic "--pretty=xyz" (including custom formats) would be
pretty painful.
So it would have to be a total special-case.
Junio, git people - what Andrew is asking for is for git shortlog to show
the commit ID (in shortened form) at the end:
> > It would be nice if these short-form summaries were to include the
> > commit IDs. eg:
> >
> > Carlos R. Mafra (1):
> > Remove argument from open_softirq which is always NULL (962cf36)
and I do think it would be nice. I've had some other things I would find
shortlog format additions useful for (size of patch etc), so if it could
be somehow generalized that would be wonderful.
As it is, that is one ugly function that only takes the one-liner thing -
at least partly because of how it traditionally worked (as a a filter over
the log messages, rather than as a "git shortlog xyz..abc" kind of
stand-alone thing).
Linus
^ permalink raw reply
* Re: I want delete fault commit from my git repository
From: Jakub Narebski @ 2008-07-14 16:41 UTC (permalink / raw)
To: chongyc; +Cc: git
In-Reply-To: <9f01c190-73b6-48b1-88d9-ed67d0945d81@k13g2000hse.googlegroups.com>
chongyc <chongyc27@gmail.com> writes:
> I have found buggy commit object which I had committed into git
> repository wrongly
>
> So I am going to delete it from my git repository
>
> How to do it ?
If it is just created commit (and not yet published), use
"git commit --amend" to correct it, or "git reset --hard HEAD^"
to just drop it.
If you have published history (somebody is relying on history
containing broken commit) the only way is to add commit reverting
changes brought by broken commit using git-revert.
If you can rewrite history, use "git rebase --interactive" and simply
remove the commit from instructions/series file if the commit you want
to remove is not too deep in history, or use git-filter-branch if
broken commit is somewhere deeper. See documentation for details.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] typo
From: Frederik Schwarzer @ 2008-07-14 16:30 UTC (permalink / raw)
To: git; +Cc: gitster
>From ffa0baf13d033b3dc6b49e86ed3de9fb3003ec4e Mon Sep 17 00:00:00 2001
From: Frederik Schwarzer <schwarzerf@gmail.com>
Date: Mon, 14 Jul 2008 18:22:52 +0200
Subject: [PATCH] typo
full stop in the middle of the sentence
Signed-off-by: Frederik Schwarzer <schwarzerf@gmail.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a366c89..8478ca6 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4619,7 +4619,7 @@ sub migrate_from_v1 {
mkpath([$svn_dir]);
print STDERR "Data from a previous version of git-svn exists, but\n\t",
"$svn_dir\n\t(required for this version ",
- "($::VERSION) of git-svn) does not. exist\n";
+ "($::VERSION) of git-svn) does not exist.\n";
my ($fh, $ctx) = command_output_pipe(qw/rev-parse --symbolic --all/);
while (<$fh>) {
my $x = $_;
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] git-svn: find-rev and rebase for SVN::Mirror repositories
From: João Abecasis @ 2008-07-14 15:28 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <7bf6f1d20807140827u56abc74fs4e289384db054a0e@mail.gmail.com>
find-rev and rebase error out on svm because git-svn doesn't trace the
original svn revision numbers back to git commits. The updated test
case, included in the patch, shows the issue and passes with the rest of
the patch applied.
This fixes Git::SVN::find_by_url to find branches based on the
svm:source URL, where useSvmProps is set. Also makes sure cmd_find_rev
and working_head_info use the information they have to correctly track
the source repository. This is enough to get find-rev and rebase
working.
Signed-off-by: João Abecasis <joao@abecasis.name>
---
git-svn.perl | 39 ++++++++++++++++++++++++++++++++++---
t/t9110-git-svn-use-svm-props.sh | 9 ++++++++
2 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a366c89..0aa994a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -537,13 +537,13 @@ sub cmd_find_rev {
my $head = shift;
$head ||= 'HEAD';
my @refs;
- my (undef, undef, undef, $gs) = working_head_info($head, \@refs);
+ my (undef, undef, $uuid, $gs) = working_head_info($head, \@refs);
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"$head history\n";
}
my $desired_revision = substr($revision_or_hash, 1);
- $result = $gs->rev_map_get($desired_revision);
+ $result = $gs->rev_map_get($desired_revision, $uuid);
} else {
my (undef, $rev, undef) = cmt_metadata($revision_or_hash);
$result = $rev;
@@ -1162,7 +1162,7 @@ sub working_head_info {
if (defined $url && defined $rev) {
next if $max{$url} and $max{$url} < $rev;
if (my $gs = Git::SVN->find_by_url($url)) {
- my $c = $gs->rev_map_get($rev);
+ my $c = $gs->rev_map_get($rev, $uuid);
if ($c && $c eq $hash) {
close $fh; # break the pipe
return ($url, $rev, $uuid, $gs);
@@ -1416,11 +1416,17 @@ sub fetch_all {
sub read_all_remotes {
my $r = {};
+ my $use_svm_props = eval { command_oneline(qw/config --bool
+ svn.useSvmProps/) };
+ $use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=\s*(.*)\s*:\s*refs/remotes/(.+)\s*$!) {
my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
$local_ref =~ s{^/}{};
$r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
+ $r->{$remote}->{svm} = {} if $use_svm_props;
+ } elsif (m!^(.+)\.usesvmprops=\s*(.*)\s*$!) {
+ $r->{$1}->{svm} = {};
} elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
$r->{$1}->{url} = $2;
} elsif (m!^(.+)\.(branches|tags)=
@@ -1437,6 +1443,23 @@ sub read_all_remotes {
}
}
}
+
+ map {
+ if (defined $r->{$_}->{svm}) {
+ my $svm;
+ eval {
+ my $section = "svn-remote.$_";
+ $svm = {
+ source => tmp_config('--get',
+ "$section.svm-source"),
+ replace => tmp_config('--get',
+ "$section.svm-replace"),
+ }
+ };
+ $r->{$_}->{svm} = $svm;
+ }
+ } keys %$r;
+
$r;
}
@@ -1563,13 +1586,21 @@ sub find_by_url { # repos_root and, path are optional
}
my $p = $path;
my $rwr = rewrite_root({repo_id => $repo_id});
+ my $svm = $remotes->{$repo_id}->{svm}
+ if defined $remotes->{$repo_id}->{svm};
unless (defined $p) {
$p = $full_url;
my $z = $u;
+ my $prefix = '';
if ($rwr) {
$z = $rwr;
+ } elsif (defined $svm) {
+ $z = $svm->{source};
+ $prefix = $svm->{replace};
+ $prefix =~ s#^\Q$u\E(?:/|$)##;
+ $prefix =~ s#/$##;
}
- $p =~ s#^\Q$z\E(?:/|$)## or next;
+ $p =~ s#^\Q$z\E(?:/|$)#$prefix# or next;
}
foreach my $f (keys %$fetch) {
next if $f ne $p;
diff --git a/t/t9110-git-svn-use-svm-props.sh b/t/t9110-git-svn-use-svm-props.sh
index 047659f..04d2a65 100755
--- a/t/t9110-git-svn-use-svm-props.sh
+++ b/t/t9110-git-svn-use-svm-props.sh
@@ -49,4 +49,13 @@ test_expect_success 'verify metadata for /dir' "
grep '^git-svn-id: $dir_url@1 $uuid$'
"
+test_expect_success 'find commit based on SVN revision number' "
+ git-svn find-rev r12 |
+ grep `git rev-parse HEAD`
+ "
+
+test_expect_success 'empty rebase' "
+ git-svn rebase
+ "
+
test_done
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] git-svn: find-rev and rebase for SVN::Mirror repositories
From: João Abecasis @ 2008-07-14 15:27 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20080714091243.GA27794@untitled>
Hi Eric,
Thanks for your reply and comments.
Eric Wong <normalperson@yhbt.net> wrote:
> João Abecasis <joao@abecasis.name> wrote:
>> find-rev and rebase error out on svm because git-svn doesn't trace the original
>> svn revision numbers back to git commits. The updated test case, included in the
>> patch, shows the issue and passes with the rest of the patch applied.
>>
>> This fixes Git::SVN::find_by_url to find branches based on the svm:source URL,
>> where useSvmProps is set. Also makes sure cmd_find_rev and working_head_info use
>> the information they have to correctly track the source repository. This is
>> enough to get find-rev and rebase working.
>>
>> Signed-off-by: João Abecasis <joao@abecasis.name>
>> ---
>> Incidentally, I've tried submitting these fixes before, but failed to
>> get much attention, so I could be doing something wrong... Any input
>> on the patch or my approach to this list is appreciated. This time I
>> reworded the commit message and added Eric Wong to the CC list, since
>> he seems to be Ack'ing git-svn patches.
>
> Hi João,
>
> Sorry, I haven't been following the mailing list much lately, and
> even keeping up with my inbox is getting to be a chore :(
I can relate to that ;-)
> The commit message should be wrapped at 72 characters or less.
> Some further notes below (mostly whitespace issues, but one
> regression).
Noted.
>> sub read_all_remotes {
>> my $r = {};
>> + my $usesvmprops = eval { command_oneline(qw/config --bool
>> + svn.useSvmProps/) };
>> + $usesvmprops = $usesvmprops eq 'true' if $usesvmprops;
>
> Always use tabs for indentation (but spaces for alignment is alright).
>
> I'd also rather not propagate the crazy alllowercasewithoutunderscores
> convention of git-config into code, either. $uses_svm_props is much
> easier to parse when I'm half-awake :)
Done!
>> foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
>> if (m!^(.+)\.fetch=\s*(.*)\s*:\s*refs/remotes/(.+)\s*$!) {
>> my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
>> $local_ref =~ s{^/}{};
>> $r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
>> + $r->{$remote}->{svm} = {} if $usesvmprops;
>> + } elsif (m!^(.+)\.usesvmprops=\s*(.*)\s*$!) {
>> + $r->{$1}->{svm} = {};
>> } elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
>> $r->{$1}->{url} = $2;
>> } elsif (m!^(.+)\.(branches|tags)=
>> @@ -1437,6 +1443,21 @@ sub read_all_remotes {
>> }
>> }
>> }
>> +
>> + map {
>> + if (defined $r->{$_}->{svm}) {
>> + my $svm;
>> + eval {
>> + my $section = "svn-remote.$_";
>> + $svm = {
>> + source => tmp_config('--get', "$section.svm-source"),
>> + replace => tmp_config('--get', "$section.svm-replace"),
>> + }
>> + };
>> + $r->{$_}->{svm} = $svm;
>> + }
>> + } keys %$r;
>> +
>
> Please wrap all code at 80-columns.
Okidoki. I just wasn't sure how wide was a tab ;-)
>> @@ -1563,13 +1584,21 @@ sub find_by_url { # repos_root and, path are optional
>> }
>> my $p = $path;
>> my $rwr = rewrite_root({repo_id => $repo_id});
>> + my $svm = $remotes->{$repo_id}->{svm}
>> + if defined $remotes->{$repo_id}->{svm};
>> unless (defined $p) {
>> $p = $full_url;
>> my $z = $u;
>> + my $prefix = '';
>> if ($rwr) {
>> $z = $rwr;
>> + } elsif (defined $svm) {
>> + $z = $svm->{source};
>> + $prefix = $svm->{replace};
>> + $prefix =~ s#^\Q$u\E(?:/|$)##;
>> + $prefix =~ s#/$##;
>> }
>> - $p =~ s#^\Q$z\E(?:/|$)## or next;
>> + $p =~ s#^\Q$z\E(?=/|$)#$prefix# or next;
>
> This broke t9100 for me at: 'able to dcommit to a subdirectory'
> Changing the ?= back to ?: works.
Duh! Missed that. I had to make a couple of tweaks after the tests
were working, because I had some another test case that was breaking
somewhere. Anyway, my other test case (which is the one where I need
it to work) works without that change after all.
> Thanks for the patch, please let us know if that change is OK.
Let's go with that, since it works. If I do find a test case where it
breaks we'll fix it later.
Updated patch coming up.
Cheers,
João
^ permalink raw reply
* Re: git-rebase eats empty commits
From: Michael J Gruber @ 2008-07-14 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <20080712221207.GB22323@leksak.fem-net>
Stephan Beyer venit, vidit, dixit 13.07.2008 00:12:
> Hi,
>
> Michael J Gruber wrote:
>> "git commit" allows empty commits with the "--allow-empty" option, i.e.
>> commits which introduce no change at all. This is sometimes useful for
>> keeping a log of untracked work related to tracked content.
>>
>> "git rebase" removes empty commits, for the good reason that rebasing
>> may make certain commits obsolete; but I don't want that in the case
>> mentioned above. Is there any way to specify "--preserve-empty" or
>> similar?
>
> First I can speak for git-sequencer: there is no such thing as a
> "preserve empty" option, but currently, when you are picking a commit
> that has already been applied so that no changes occur, it will pause.
> (It will not pause if it is a fast-forward.)
> Yet, I was unsure if this is a "correct" behavior, but it seemed to be
> useful, because you can inspect the situation.
>
> In my mind, the same should happen with an empty commit, so I tested it:
> 1. It pauses.
> 2. In that pause I only need to run "git commit --allow-empty" and I have
> the picked empty patch with that commit message.
>
> So if this behavior is kept, there is no such need for such an option.
>
> Now I'm checking it with the old rebase-i (I'm always referring to
> git-rebase--interactive as rebase-i) and exactly the same behavior
> occurs.
>
> But rebase is not rebase-i.
> So I've also checked both, pure rebase and rebase-m: then the empty commit
> is lost.
>
> To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty"
> and then "git rebase --continue" and you have what you want.
I assume this is with git from master? With git 1.5.6.2 rebase -i
doesn't stop there, not even when I change "pick" to "edit"!
So, I guess for now I'll use my hacked git-rebase ("-m", I didn't hack
git-format-patch), maybe 1.6.0 will behave as described above. Anyway
thanks for the hint about distinguishing between rebase and rebase -i.
Michael
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Linus Torvalds @ 2008-07-14 14:51 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Shawn O. Pearce, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080714065018.GB26446@atjola.homenet>
On Mon, 14 Jul 2008, Björn Steinbrink wrote:
> >
> > Seems that gvfs comes with a completion script that deliberately drops
> > the : from COMP_WORDBREAKS. Do you have that installed Linus?
>
> Ah crap, I should have mentioned which file I'm talking about... It's
> /etc/profile.d/gvfs-bash-completion.sh
Yup. Part of gvfs-0.2.5-1.fc9.x86_64 for me.
Linus
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Linus Torvalds @ 2008-07-14 14:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080714062755.GA15992@spearce.org>
On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>
> What is $COMP_WORDBREAKS set to in your shell? In mine it
> appears to be:
>
> " \"'@><=;|&(:"
>
> which is the I believe the shell default.
Ahhah. Indeed. I don't have the ':'.
> Though we could try to detect : in there and if it is not present
> use the workaround you posted. But I wonder if just asking the
> user to include : is easier.
Umm, if so, git should just set it in the completion script, no?
And doing a google for 'COMP_WORDBREAKS' and 'colon', I don't think I'm
the only one with it unset. In fact, I'm pretty sure I didn't unset it
myself, because I've never heard of that thing. So I think it's a generic
Fedora 9 thing.
(I just checked - that seems to pan out. All the machines with F9 on it I
have access to are missing the ':' - including machines I have not set up
myself like master.kernel.org)
Linus
^ permalink raw reply
* Re: [RFH] Finding all commits that touch the same files as a specific commit
From: Sverre Rabbelier @ 2008-07-14 14:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0807141311520.8950@racer>
On Mon, Jul 14, 2008 at 2:13 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> IMO following the file renames/code moves precisely is really worth the
> time it takes to calculate. Otherwise, the statistics will not reflect
> what was going on in the project, right?
Ah, I did not mean to imply that it is not worth the time it takes to
calculate, more that I do not know how to implement it that way. Of
course if someone has the time/motivation to do so I would very much
make use of it, but I do not have time to do so myself (at least not
until after GSoC). I can have GitStats just ignore the subtree merge
cases (and say that it is not beyond the scope of my project to take
such into account) and have a working program by the end of GSoC. But
if I spend time on getting this to work instead I might end up with a
program that does follow sub-tree merges but is only half-done, and as
such probably won't receive a "OK" grade. So, yes, I would very much
like to see this, but no time to look into doing so myself until after
GSoC.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Johannes Schindelin @ 2008-07-14 12:58 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, Shawn O. Pearce, Nicolas Pitre, Junio C Hamano,
git, Stephan Hennig
In-Reply-To: <487B4BD8.5030208@op5.se>
Hi,
On Mon, 14 Jul 2008, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 14 Jul 2008, Andreas Ericsson wrote:
> >
> > > Sorry for being clueless here, but why does the older versions need
> > > to be kept in-memory anyway? Aren't we applying the delta each time
> > > we find one, repeatedly creating a new base-object in-memory for
> > > each delta? If we aren't doing that, why do we need more than just
> > > a small amount of memory just for keeping the delta?
> >
> > Think of a delta chain of 49 delta objects, 1 base object. Now reconstruct
> > all of the objects.
> >
> > If you do it one by one, not storing the intermediate results, you end up
> > applying 1 delta for the first, 2 for the second (first the first, then the
> > second), and so on, in total 1 + 2 + 3 + ... + 49 = 49 * 50 / 2 = 1225
> > times.
> >
> > Compare that to the 49 times when reusing the intermediate results.
> >
>
> [...]
>
> while (pop_delta(patch_stack))
> apply_delta(base_object, delta);
>
> where "apply_delta" replaces the base_object->blob with the delta
> applied, releasing the previously used memory?
Delta chains are not (necessarily) independent.
Ciao,
Dscho
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Johannes Schindelin @ 2008-07-14 12:56 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <20080714124109.25414.qmail@06d015ec9c6744.315fe32.mid.smarden.org>
Hi,
On Mon, 14 Jul 2008, Gerrit Pape wrote:
> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > I'm saying this because I believe the best conservative upper bound for
> > > backwards compatibility is Git version in Debian stable. It gets
> > > probably the most stale from all the widely used software distributions
> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > > fails miserably on the new packs.
> >
> > Can't we just hit Debian's Git maintainer with a clue bat or a bus,
>
> Please don't. It wouldn't help, rather the opposite I think, espacially
> the bus.
Heh. It was a feeble attempt at humor production ;-)
> We don't introduce new upstream versions into a Debian stable release,
> there's a great effort done for each stable release to reach high
> quality integration of all the software packages available in Debian.
> Once that status is reached, only security fixes and criticial usability
> fixes are added.
If that is the case, we might need to think about fixing that segmentation
fault to 1.4.4.5... Which would be a minor pain in the donkey, I guess.
> The freeze of the packages for the next stable release is planned a few
> days from now, so it looks like Debian 'lenny' will include git 1.5.6.x.
>From my memories of IRC, it seems that quite a few people do not even
consider upgrading.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Andreas Ericsson @ 2008-07-14 12:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Shawn O. Pearce, Nicolas Pitre, Junio C Hamano,
git, Stephan Hennig
In-Reply-To: <alpine.DEB.1.00.0807141322140.8950@racer>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 14 Jul 2008, Andreas Ericsson wrote:
>
>> Sorry for being clueless here, but why does the older versions need
>> to be kept in-memory anyway? Aren't we applying the delta each time
>> we find one, repeatedly creating a new base-object in-memory for
>> each delta? If we aren't doing that, why do we need more than just
>> a small amount of memory just for keeping the delta?
>
> Think of a delta chain of 49 delta objects, 1 base object. Now
> reconstruct all of the objects.
>
> If you do it one by one, not storing the intermediate results, you end up
> applying 1 delta for the first, 2 for the second (first the first, then
> the second), and so on, in total 1 + 2 + 3 + ... + 49 = 49 * 50 / 2 = 1225
> times.
>
> Compare that to the 49 times when reusing the intermediate results.
>
That's only true if you discard the result of applying D1 to DB though.
What I'm wondering is; Why isn't it done like this (pseudo-code):
while (delta = find_earlier_delta(sha1)) {
if (is_base_object(delta)) {
base_object = delta;
break;
}
push_delta(delta, patch_stack);
}
while (pop_delta(patch_stack))
apply_delta(base_object, delta);
where "apply_delta" replaces the base_object->blob with the delta
applied, releasing the previously used memory?
That way, you'll never use more memory than the largest ever size
of the object + 1 delta at a time and still not apply the delta
more than delta_chain_length-1 times.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Petr Baudis @ 2008-07-14 12:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807141256310.8950@racer>
Hi,
On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> On Mon, 14 Jul 2008, Petr Baudis wrote:
>
> > I'm saying this because I believe the best conservative upper bound for
> > backwards compatibility is Git version in Debian stable. It gets
> > probably the most stale from all the widely used software distributions
> > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > fails miserably on the new packs.
>
> Can't we just hit Debian's Git maintainer with a clue bat or a bus,
> whichever is easier, and force them to upgrade _in_ Etch? It's not like
> we haven't had _several_ stable releases in-between.
the whole point of having a stable distribution is that random version
upgrades don't happen under your hands; sure, 1.4.4.4 can have plenty of
bugs, but it's buggy in a well-defined way, which is better than upgrade
to newer stable version, which may be less buggy, but in a different
way; also, by upgrading to newer version you might find various subtle
compatibility issues, etc.
Upgrading to newer version, *especially* if it's over then 1.4 - 1.5
boundary, is not something you could seriously expect Debian to do.
At least I actually _hope_ so, as a sysadmin of a network of 40 etch
workstations.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Andreas Ericsson @ 2008-07-14 12:39 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Shawn O. Pearce, Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080714065018.GB26446@atjola.homenet>
Björn Steinbrink wrote:
> On 2008.07.14 08:47:19 +0200, Björn Steinbrink wrote:
>> On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:
>>> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>>>>>> Does it fix this one too:
>>>>>>
>>>>>> git show origin/pu:Makef<tab>
>>>>>>
>>>>>> which totally screws up and becomes
>>>>>>
>>>>>> git show Makefile
>>>>>>
>>>>>> dropping the version specifier?
>>> What is $COMP_WORDBREAKS set to in your shell? In mine it
>>> appears to be:
>>>
>>> " \"'@><=;|&(:"
>>>
>>> which is the I believe the shell default.
>>>
>>> Björn Steinbrink (doener on #git) is running bash 3.2.39 from
>>> Debian and has the same setting, and the completion works correctly
>>> there too. He reports that removing : from COMP_WORDBREAKS will
>>> get the behavior you are reporting as broken.
>>>
>>> I have to say, this sounds to me like you (or some package on your
>>> system) modified COMP_WORDBREAKS away from the default that other
>>> distributions use and that is what is breaking us here. Since we
>>> can have only one setting for this variable in the shell I do not
>>> thing it would be a good idea for our completion package to force
>>> a specific setting upon the user.
>> Seems that gvfs comes with a completion script that deliberately drops
>> the : from COMP_WORDBREAKS. Do you have that installed Linus?
>
> Ah crap, I should have mentioned which file I'm talking about... It's
> /etc/profile.d/gvfs-bash-completion.sh
>
I have that file, and I'm seeing the same issue as Linus.
E13 at http://tiswww.case.edu/php/chet/bash/FAQ mentions it, but
doesn't (imo) give a strong reason why it drops colon from
COMP_WORDBREAKS, as filenames with colons in them aren't exactly
common.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Gerrit Pape @ 2008-07-14 12:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807141256310.8950@racer>
On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> On Mon, 14 Jul 2008, Petr Baudis wrote:
> > I'm saying this because I believe the best conservative upper bound for
> > backwards compatibility is Git version in Debian stable. It gets
> > probably the most stale from all the widely used software distributions
> > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > fails miserably on the new packs.
>
> Can't we just hit Debian's Git maintainer with a clue bat or a bus,
Please don't. It wouldn't help, rather the opposite I think, espacially
the bus. We don't introduce new upstream versions into a Debian stable
release, there's a great effort done for each stable release to reach
high quality integration of all the software packages available in
Debian. Once that status is reached, only security fixes and criticial
usability fixes are added.
The freeze of the packages for the next stable release is planned a few
days from now, so it looks like Debian 'lenny' will include git 1.5.6.x.
Regards, Gerrit.
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Johannes Schindelin @ 2008-07-14 12:25 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, Shawn O. Pearce, Nicolas Pitre, Junio C Hamano,
git, Stephan Hennig
In-Reply-To: <487B439F.8040902@op5.se>
Hi,
On Mon, 14 Jul 2008, Andreas Ericsson wrote:
> Sorry for being clueless here, but why does the older versions need
> to be kept in-memory anyway? Aren't we applying the delta each time
> we find one, repeatedly creating a new base-object in-memory for
> each delta? If we aren't doing that, why do we need more than just
> a small amount of memory just for keeping the delta?
Think of a delta chain of 49 delta objects, 1 base object. Now
reconstruct all of the objects.
If you do it one by one, not storing the intermediate results, you end up
applying 1 delta for the first, 2 for the second (first the first, then
the second), and so on, in total 1 + 2 + 3 + ... + 49 = 49 * 50 / 2 = 1225
times.
Compare that to the 49 times when reusing the intermediate results.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation
From: Johannes Schindelin @ 2008-07-14 12:20 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <1216018557.487af87d7bd28@webmail.eunet.at>
Hi,
On Mon, 14 Jul 2008, Johannes Sixt wrote:
> Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Sun, 13 Jul 2008, Johannes Sixt wrote:
> >
> > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> > > *path)
> > > }
> > > }
> > >
> > > -void setup_path(const char *cmd_path)
> > > +void setup_path(void)
> >
> > It seems to me that this patch would not do anything different, but
> > with less code change, if setup_path() would set argv0_path, and not a
> > new function was introduced.
>
> This is just to play a safe game. I had it that way, but I decided to have
> the call to the new git_set_argv0_path() early in git.c because the call
> to setup_path() in git.c is very late, and it could happen that we call
> system_path() (which needs argv0_path) before that. Although I didn't audit
> the code whether this really happens.
Well, okay... I would have rather seen it not change (since there was no
bug to fix), or as a separate patch, but it's Junio's call.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Andreas Ericsson @ 2008-07-14 12:16 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Shawn O. Pearce, Nicolas Pitre,
Junio C Hamano, git, Stephan Hennig
In-Reply-To: <m31w1wu1hc.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>
>>> The only other alternative I can come up with is to change pack-objects
>>> (or at least its defaults) so we don't generate these massive delta
>>> chains. But there are already packs in the wild that use these chains,
>>> resulting in performance problems for clients.
>> But the long chains make the pack actually as efficient as it is...
>
> Perhaps Shawn thought here about limiting delta chain not by its
> *length*, but by its *size* (as required when unpacking last object
> in a delta chanin).
>
> What do you think about this idea?
Sorry for being clueless here, but why does the older versions need
to be kept in-memory anyway? Aren't we applying the delta each time
we find one, repeatedly creating a new base-object in-memory for
each delta? If we aren't doing that, why do we need more than just
a small amount of memory just for keeping the delta?
Feel free to tell me to go away if I'm being stupid. I'm just
curious and probably won't be able to hack up any patches anyway.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFH] Finding all commits that touch the same files as a specific commit
From: Johannes Schindelin @ 2008-07-14 12:13 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <bd6139dc0807140417h7c9cd309g7cf911e78e7f78c5@mail.gmail.com>
Hi,
On Mon, 14 Jul 2008, Sverre Rabbelier wrote:
> For the activity metric I think pretending that all files with the same
> name or renamed versions of those would make sense, which is what
> appending the new name would do. The downside is that all files with the
> same name get grouped together, I'm not sure which is the lesser of two
> evils. Leaving out information, or (possibly) including too much.
IMO following the file renames/code moves precisely is really worth the
time it takes to calculate. Otherwise, the statistics will not reflect
what was going on in the project, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Johannes Schindelin @ 2008-07-14 12:10 UTC (permalink / raw)
To: Jakub Narebski
Cc: Shawn O. Pearce, Nicolas Pitre, Junio C Hamano, git,
Stephan Hennig, Andreas Ericsson
In-Reply-To: <m31w1wu1hc.fsf@localhost.localdomain>
Hi,
On Mon, 14 Jul 2008, Jakub Narebski wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>
> > > The only other alternative I can come up with is to change pack-objects
> > > (or at least its defaults) so we don't generate these massive delta
> > > chains. But there are already packs in the wild that use these chains,
> > > resulting in performance problems for clients.
> >
> > But the long chains make the pack actually as efficient as it is...
>
> Perhaps Shawn thought here about limiting delta chain not by its
> *length*, but by its *size* (as required when unpacking last object
> in a delta chanin).
So you mean once the sizes of the reconstructed objects are too big, i.e.
when the delta chain is actually _most useful_, we should not do it?
Don't think so.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add testcase for merge.log
From: Miklos Vajna @ 2008-07-14 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1215678742-14042-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Thu, Jul 10, 2008 at 10:32:22AM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Jul 10, 2008 at 12:50:59AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > The command forgot the configuration variable when rewritten in C.
>
> Thanks. Here is a testcase.
As far as I see this has been forgotten. Should I resend it on top of
current mv/merge-in-c?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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