* [JGIT PATCH 1/4] Make the cleanup less verbose when it fails to delete temporary stuff.
From: Robin Rosenberg @ 2008-11-27 21:15 UTC (permalink / raw)
To: spearce; +Cc: git, fonseca, Robin Rosenberg
In-Reply-To: <1227820535-9785-1-git-send-email-robin.rosenberg@dewire.com>
Pass the test case name for easier tracking of the test case that
causes problems.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../org/spearce/jgit/lib/RepositoryTestCase.java | 59 ++++++++++++++-----
1 files changed, 43 insertions(+), 16 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index 9d7d133..9c272f6 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -66,22 +66,43 @@
jcommitter = new PersonIdent("J. Committer", "jcommitter@example.com");
}
- protected static void recursiveDelete(final File dir) {
+ protected static boolean recursiveDelete(final File dir) {
+ return recursiveDelete(dir, false, null);
+ }
+
+ protected static boolean recursiveDelete(final File dir, boolean silent,
+ final String name) {
+ if (!dir.exists())
+ return silent;
final File[] ls = dir.listFiles();
if (ls != null) {
for (int k = 0; k < ls.length; k++) {
final File e = ls[k];
if (e.isDirectory()) {
- recursiveDelete(e);
+ silent = recursiveDelete(e, silent, name);
} else {
- e.delete();
+ if (!e.delete()) {
+ if (!silent) {
+ String msg = "Warning: Failed to delete " + e;
+ if (name != null)
+ msg += " in " + name;
+ System.out.println(msg);
+ }
+ silent = true;
+ }
}
}
}
- dir.delete();
- if (dir.exists()) {
- System.out.println("Warning: Failed to delete " + dir);
+ if (!dir.delete()) {
+ if (!silent) {
+ String msg = "Warning: Failed to delete " + dir;
+ if (name != null)
+ msg += " in " + name;
+ System.out.println(msg);
+ }
+ silent = true;
}
+ return silent;
}
protected static void copyFile(final File src, final File dst)
@@ -121,19 +142,25 @@ protected static void checkFile(File f, final String checkData)
protected Repository db;
+ private static int testcount;
+ private static Thread shutdownhook;
+
public void setUp() throws Exception {
super.setUp();
- recursiveDelete(trashParent);
- trash = new File(trashParent,"trash"+System.currentTimeMillis());
+ System.gc();
+ trash = new File(trashParent,"trash"+System.currentTimeMillis()+"."+(testcount++));
+ final String name = getClass().getName() + "." + getName();
+ recursiveDelete(trashParent, true, name);
trash_git = new File(trash, ".git");
-
- Runtime.getRuntime().addShutdownHook(new Thread() {
- @Override
- public void run() {
- recursiveDelete(trashParent);
- }
- });
-
+ if (shutdownhook == null) {
+ shutdownhook = new Thread() {
+ @Override
+ public void run() {
+ recursiveDelete(trashParent, false, name);
+ }
+ };
+ Runtime.getRuntime().addShutdownHook(shutdownhook);
+ }
db = new Repository(trash_git);
db.create();
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* [JGIT PATCH 0/4] RepositoryTestCase cleanups
From: Robin Rosenberg @ 2008-11-27 21:15 UTC (permalink / raw)
To: spearce; +Cc: git, fonseca, Robin Rosenberg
Ok, so here is an attempt to improve the ability of the JGit's unit
tests to delete temporary repositories. This has probably been seen
by many, but Jonas Fonseca raised the issue.
The background is that on Windows you cannot delete files that are
open and mmapped files are open until they get unmapped, which in
Java is beyond explicit programmer control. You can only free the
resources and pray that the GC does the work. Fortunately it usually
does. It turned out our testcases weren't even trying to clean up
properly.
-- robin
Robin Rosenberg (4):
Make the cleanup less verbose when it fails to delete temporary
stuff.
Add shutdown hooks to try to clean up after unit tests anyway
Cleanup malformed test cases
Automatically clean up any repositories created by the test cases
.../tst/org/spearce/jgit/lib/PackWriterTest.java | 3 +
.../org/spearce/jgit/lib/RepositoryTestCase.java | 82 +++++++++++++++++---
2 files changed, 73 insertions(+), 12 deletions(-)
^ permalink raw reply
* [JGIT PATCH 0/4] RepositoryTestCase cleanups
From: Robin Rosenberg @ 2008-11-27 21:13 UTC (permalink / raw)
To: spearce; +Cc: git, fonseca, Robin Rosenberg
Ok, so here is an attempt to improve the ability of the JGit's unit
tests to delete temporary repositories. This has probably been seen
by many, but Jonas Fonseca raised the issue.
The background is that on Windows you cannot delete files that are
open and mmapped files are open until they get unmapped, which in
Java is beyond explicit programmer control. You can only free the
resources and pray that the GC does the work. Fortunately it usually
does. It turned out our testcases weren't even trying to clean up
properly.
-- robin
Robin Rosenberg (4):
Make the cleanup less verbose when it fails to delete temporary
stuff.
Add shutdown hooks to try to clean up after unit tests anyway
Cleanup malformed test cases
Automatically clean up any repositories created by the test cases
.../tst/org/spearce/jgit/lib/PackWriterTest.java | 3 +
.../org/spearce/jgit/lib/RepositoryTestCase.java | 82 +++++++++++++++++---
2 files changed, 73 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH 5/5] Implement 'l' command to display summaries.
From: William Pursell @ 2008-11-27 21:10 UTC (permalink / raw)
To: git
The summary information is in place to print out
the first added line (NEW), and the first removed
line (OLD), but it seems that just printing the
line number context is adequate. Perhaps one
could add config options to print OLD and NEW,
but this seems good enough for now.
---
git-add--interactive.perl | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index ae785e2..6a3d97d 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -824,6 +824,7 @@ sub help_patch_cmd {
y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
+l - print a brief summary of all the hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
@@ -861,6 +862,24 @@ sub patch_update_cmd {
}
}
+sub display_summaries {
+ my $index = shift;
+ my @hunk = @_;
+ my $i = 0;
+ print "'*' indicates current hunk. '+' stage, '-' don't stage\n";
+ for ( ; $i < @hunk; $i++ ) {
+ my $status = " ";
+ if( defined $hunk[$i]{USE} ) {
+ $status = $hunk[$i]{USE} ? "+" : "-";
+ }
+ printf "%s%d%s: %s",
+ $i == $index ? "*" : " ",
+ $i,
+ $status,
+ $hunk[$i]{SUMMARY}{LINE};
+ }
+}
+
sub patch_update_file {
my ($ix, $num);
my $path = shift;
@@ -904,7 +923,7 @@ sub patch_update_file {
while (1) {
my ($commands, $undecided, $i);
- $commands = 'ynad';
+ $commands = 'ynald';
if ($num <= $ix) {
$ix = 0;
@@ -961,6 +980,10 @@ sub patch_update_file {
}
next;
}
+ elsif ($line =~ /^l/i) {
+ display_summaries ($ix, @hunk);
+ next;
+ }
elsif ($line =~ /^d/i) {
while ($ix < $num) {
if (!defined $hunk[$ix]{USE}) {
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* [PATCH 4/5] Adding SUMMARY lines to hunks.
From: William Pursell @ 2008-11-27 21:10 UTC (permalink / raw)
To: git
The idea is to add a command to allow the hunks to be listed
with a brief summary of each, with an option to determine
what the summary will entail. The current thought is
to be able to display the line summary, the first new
line, and the first removed line.
---
git-add--interactive.perl | 27 ++++++++++++++++++++++++++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 0d51cb2..ae785e2 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -553,7 +553,20 @@ sub parse_diff {
for (my $i = 0; $i < @diff; $i++) {
if ($diff[$i] =~ /^@@ /) {
- push @hunk, { TEXT => [], DISPLAY => [] };
+ push @hunk,
+ { TEXT => [], DISPLAY => [],
+ SUMMARY => {
+ LINE => $diff[$i],
+ NEW => undef,
+ OLD => undef
+ }
+ };
+ }
+ if ($diff[$i] =~ /^\+/ and not $hunk[-1]{SUMMARY}{NEW}) {
+ $hunk[-1]{SUMMARY}{NEW} = $diff[$i];
+ }
+ if ($diff[$i] =~ /^-/ and not $hunk[-1]{SUMMARY}{OLD}) {
+ $hunk[-1]{SUMMARY}{OLD} = $diff[$i];
}
push @{$hunk[-1]{TEXT}}, $diff[$i];
push @{$hunk[-1]{DISPLAY}},
@@ -613,6 +626,11 @@ sub split_hunk {
my $this = +{
TEXT => [],
DISPLAY => [],
+ SUMMARY => {
+ LINE => undef,
+ NEW => undef,
+ OLD => undef
+ },
OLD => $o_ofs,
NEW => $n_ofs,
OCNT => 0,
@@ -658,6 +676,12 @@ sub split_hunk {
push @split, $this;
redo OUTER;
}
+ if ($line =~ /\+/ and not $this->{SUMMARY}{NEW}) {
+ $this->{SUMMARY}{NEW} = $line;
+ }
+ if ($line =~ /-/ and not $this->{SUMMARY}{OLD}) {
+ $this->{SUMMARY}{OLD} = $line;
+ }
push @{$this->{TEXT}}, $line;
push @{$this->{DISPLAY}}, $display;
$this->{ADDDEL}++;
@@ -685,6 +709,7 @@ sub split_hunk {
(($n_cnt != 1) ? ",$n_cnt" : '') .
" @@\n");
my $display_head = $head;
+ $hunk->{SUMMARY}{LINE} = $head;
unshift @{$hunk->{TEXT}}, $head;
if ($diff_use_color) {
$display_head = colored($fraginfo_color, $head);
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* [PATCH 3/5] Removed unused variables prev and next.
From: William Pursell @ 2008-11-27 21:10 UTC (permalink / raw)
To: git
---
git-add--interactive.perl | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b530597..0d51cb2 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -878,7 +878,7 @@ sub patch_update_file {
$ix = 0;
while (1) {
- my ($prev, $next, $commands, $undecided, $i);
+ my ($commands, $undecided, $i);
$commands = 'ynad';
if ($num <= $ix) {
@@ -886,7 +886,6 @@ sub patch_update_file {
}
for ($i = 0; $i < $ix; $i++) {
if (!defined $hunk[$i]{USE}) {
- $prev = 1;
$commands .= 'k';
last;
}
@@ -896,7 +895,6 @@ sub patch_update_file {
}
for ($i = $ix + 1; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
- $next = 1;
$commands .= 'j';
last;
}
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* [PATCH 2/5] Name change: other -> commands.
From: William Pursell @ 2008-11-27 21:10 UTC (permalink / raw)
To: git
This name more accurately reflects the use of the variable.
---
git-add--interactive.perl | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 6e474d0..b530597 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -878,8 +878,8 @@ sub patch_update_file {
$ix = 0;
while (1) {
- my ($prev, $next, $other, $undecided, $i);
- $other = 'ynad';
+ my ($prev, $next, $commands, $undecided, $i);
+ $commands = 'ynad';
if ($num <= $ix) {
$ix = 0;
@@ -887,22 +887,22 @@ sub patch_update_file {
for ($i = 0; $i < $ix; $i++) {
if (!defined $hunk[$i]{USE}) {
$prev = 1;
- $other .= 'k';
+ $commands .= 'k';
last;
}
}
if ($ix) {
- $other .= 'K';
+ $commands .= 'K';
}
for ($i = $ix + 1; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$next = 1;
- $other .= 'j';
+ $commands .= 'j';
last;
}
}
if ($ix < $num - 1) {
- $other .= 'J';
+ $commands .= 'J';
}
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
@@ -913,14 +913,14 @@ sub patch_update_file {
last if (!$undecided);
if (hunk_splittable($hunk[$ix]{TEXT})) {
- $other .= 's';
+ $commands .= 's';
}
- $other .= 'e?';
+ $commands .= 'e?';
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
print colored $prompt_color, "Stage this hunk [" .
- join (",", split( '', $other)) . "]? ";
+ join (",", split( '', $commands)) . "]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
@@ -947,15 +947,15 @@ sub patch_update_file {
}
next;
}
- elsif ($other =~ /K/ && $line =~ /^K/) {
+ elsif ($commands =~ /K/ && $line =~ /^K/) {
$ix--;
next;
}
- elsif ($other =~ /J/ && $line =~ /^J/) {
+ elsif ($commands =~ /J/ && $line =~ /^J/) {
$ix++;
next;
}
- elsif ($other =~ /k/ && $line =~ /^k/) {
+ elsif ($commands =~ /k/ && $line =~ /^k/) {
while (1) {
$ix--;
last if (!$ix ||
@@ -963,7 +963,7 @@ sub patch_update_file {
}
next;
}
- elsif ($other =~ /j/ && $line =~ /^j/) {
+ elsif ($commands =~ /j/ && $line =~ /^j/) {
while (1) {
$ix++;
last if ($ix >= $num ||
@@ -971,7 +971,7 @@ sub patch_update_file {
}
next;
}
- elsif ($other =~ /s/ && $line =~ /^s/) {
+ elsif ($commands =~ /s/ && $line =~ /^s/) {
my @split = split_hunk($hunk[$ix]{TEXT}, $hunk[$ix]{DISPLAY});
if (1 < @split) {
print colored $header_color, "Split into ",
@@ -988,7 +988,7 @@ sub patch_update_file {
}
}
else {
- help_patch_cmd($other);
+ help_patch_cmd($commands);
next;
}
# soft increment
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* [PATCH 1/5] Change separator from '/' to ',' in add --patch
From: William Pursell @ 2008-11-27 21:10 UTC (permalink / raw)
To: git
This also simplifies the code some by localizing the
separator to the join at line 923.
---
git-add--interactive.perl | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..6e474d0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -879,7 +879,7 @@ sub patch_update_file {
while (1) {
my ($prev, $next, $other, $undecided, $i);
- $other = '';
+ $other = 'ynad';
if ($num <= $ix) {
$ix = 0;
@@ -887,22 +887,22 @@ sub patch_update_file {
for ($i = 0; $i < $ix; $i++) {
if (!defined $hunk[$i]{USE}) {
$prev = 1;
- $other .= '/k';
+ $other .= 'k';
last;
}
}
if ($ix) {
- $other .= '/K';
+ $other .= 'K';
}
for ($i = $ix + 1; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$next = 1;
- $other .= '/j';
+ $other .= 'j';
last;
}
}
if ($ix < $num - 1) {
- $other .= '/J';
+ $other .= 'J';
}
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
@@ -913,13 +913,14 @@ sub patch_update_file {
last if (!$undecided);
if (hunk_splittable($hunk[$ix]{TEXT})) {
- $other .= '/s';
+ $other .= 's';
}
- $other .= '/e';
+ $other .= 'e?';
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
- print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
+ print colored $prompt_color, "Stage this hunk [" .
+ join (",", split( '', $other)) . "]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* summaries in git add --patch
From: William Pursell @ 2008-11-27 21:10 UTC (permalink / raw)
To: git
I just implemented a command to give a brief summary
of the patches in the current file. Please note that
I am just rediscovering perl after having abandoned it
years ago, so any criticism is appreciated. 5 patches
to follow. (From aa14a0c3f)
Here's a screen shot:
Stage this hunk [y,n,a,l,d,k,K,j,J,e,?]? l
'*' indicates current hunk. '+' stage, '-' don't stage
0+: @@ -8,9 +8,9 @@ Aani
1 : @@ -48,7 +48,7 @@ abandonable
*2 : @@ -88,7 +88,7 @@ abaton
3 : @@ -128,7 +128,7 @@ abdest
4-: @@ -81192,9 +81192,9 @@ gyrous
5 : @@ -234925,7 +234925,7 @@ zymotic
@@ -88,7 +88,7 @@ abaton
abator
abattoir
Abatua
-abature
+agature
abave
abaxial
abaxile
--
William Pursell
^ permalink raw reply
* Re: git fsck segmentation fault
From: Nicolas Pitre @ 2008-11-27 19:57 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Git Mailing List
In-Reply-To: <200811272021.56108.simon@lst.de>
On Thu, 27 Nov 2008, Simon Hausmann wrote:
> On Thursday 27 November 2008 20:10:20 Simon Hausmann wrote:
> > On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:
> > > On Thu, 27 Nov 2008, Simon Hausmann wrote:
> > > > Hi,
> > > >
> > > > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium
> > > > sized
> > >
> > > That version doesn't exist in the git repo.
> >
> > Ah, oops, it was a merge commit, corresponding to maint as of 5aa3bd.
> >
> > > > (930M) repository I get a segfault.
> > > >
> > > > The backtrace indicates an infinite recursion. Here's the output from
> > > > the last few lines:
> > >
> > > [...]
> > >
> > > Could you try with latest master branch please? It is more robust
> > > against some kind of pack corruptions that could send the code into
> > > infinite loops.
> >
> > Same problem with git version 1.6.0.4.790.gaa14a
>
> Forgot to paste the changed line numbers of the recursion:
[...]
Well... Your initial backtrace showed recursion in unpack_entry() which
was rather odd in the first place. Your latest backtrace shows a loop
in make_object() which has nothing to do what so ever with
unpack_entry(). So the backtrace might not be really useful.
I suspect you'll have to bisect git to find the issue, given that some
old version can be found to be good. For example, does it work with
v1.5.2.5?
Nicolas
^ permalink raw reply
* Re: git fsck segmentation fault
From: Simon Hausmann @ 2008-11-27 19:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <200811272010.20891.simon@lst.de>
On Thursday 27 November 2008 20:10:20 Simon Hausmann wrote:
> On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:
> > On Thu, 27 Nov 2008, Simon Hausmann wrote:
> > > Hi,
> > >
> > > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium
> > > sized
> >
> > That version doesn't exist in the git repo.
>
> Ah, oops, it was a merge commit, corresponding to maint as of 5aa3bd.
>
> > > (930M) repository I get a segfault.
> > >
> > > The backtrace indicates an infinite recursion. Here's the output from
> > > the last few lines:
> >
> > [...]
> >
> > Could you try with latest master branch please? It is more robust
> > against some kind of pack corruptions that could send the code into
> > infinite loops.
>
> Same problem with git version 1.6.0.4.790.gaa14a
Forgot to paste the changed line numbers of the recursion:
#54 0x0000000000493c6d in parse_tree (item=0x20d0178) at tree.c:224
#55 0x0000000000424ca2 in mark_object (obj=0x20d0178, type=2, data=<value
optimized out>) at builtin-fsck.c:102
#56 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0
<mark_object>, data=0x20d0128) at fsck.c:26
#57 0x0000000000424cba in mark_object (obj=0x20d0128, type=2, data=<value
optimized out>) at builtin-fsck.c:105
#58 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0
<mark_object>, data=0x1edb448) at fsck.c:26
#59 0x0000000000424cba in mark_object (obj=0x1edb448, type=2, data=<value
optimized out>) at builtin-fsck.c:105
#60 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0
<mark_object>, data=0x1edb420) at fsck.c:26
#61 0x0000000000424cba in mark_object (obj=0x1edb420, type=2, data=<value
optimized out>) at builtin-fsck.c:105
#62 0x0000000000468bf9 in fsck_walk (obj=0x241a750, walk=0x424af0
<mark_object>, data=0x241a750) at fsck.c:50
#63 0x0000000000424b7d in mark_object (obj=0x241a750, type=1, data=<value
optimized out>) at builtin-fsck.c:105
#64 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
<mark_object>, data=0x241a708) at fsck.c:57
#65 0x0000000000424b7d in mark_object (obj=0x241a708, type=1, data=<value
optimized out>) at builtin-fsck.c:105
#66 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
<mark_object>, data=0x4dea0b0) at fsck.c:57
#67 0x0000000000424b7d in mark_object (obj=0x4dea0b0, type=1, data=<value
optimized out>) at builtin-fsck.c:105
#68 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
<mark_object>, data=0x488ff78) at fsck.c:57
#69 0x0000000000424b7d in mark_object (obj=0x488ff78, type=1, data=<value
optimized out>) at builtin-fsck.c:105
#70 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
<mark_object>, data=0x488bd18) at fsck.c:57
#71 0x0000000000424b7d in mark_object (obj=0x488bd18, type=1, data=<value
optimized out>) at builtin-fsck.c:105
#72 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0
<mark_object>, data=0x313c0b0) at fsck.c:57
#73 0x0000000000424b7d in mark_object (obj=0x313c0b0, type=1, data=<value
optimized out>) at builtin-fsck.c:105
[recursion between line 105 and 57]
Simon
^ permalink raw reply
* Re: git fsck segmentation fault
From: Simon Hausmann @ 2008-11-27 19:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811271243250.14328@xanadu.home>
On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:
> On Thu, 27 Nov 2008, Simon Hausmann wrote:
> > Hi,
> >
> > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium
> > sized
>
> That version doesn't exist in the git repo.
Ah, oops, it was a merge commit, corresponding to maint as of 5aa3bd.
> > (930M) repository I get a segfault.
> >
> > The backtrace indicates an infinite recursion. Here's the output from the
> > last few lines:
>
> [...]
>
> Could you try with latest master branch please? It is more robust
> against some kind of pack corruptions that could send the code into
> infinite loops.
Same problem with git version 1.6.0.4.790.gaa14a
:-/
Simon
^ permalink raw reply
* Re: git-svn clone behaves non-deterministic
From: Josef Wolf @ 2008-11-27 18:29 UTC (permalink / raw)
To: git
In-Reply-To: <492E6E80.7010209@drmicha.warpmail.net>
Thanks for your reply, Michael!
On Thu, Nov 27, 2008 at 10:55:12AM +0100, Michael J Gruber wrote:
> Josef Wolf venit, vidit, dixit 27.11.2008 08:53:
> > Hello,
> >
> > I am new to git and decided to get my feet wet by first cloning and
> > playing with my existing svn repositories. Thus, I've done this:
> >
> > cd /my/test/repos
> > for i in repo1 repo2 repo3; do
> > repos=https://my.repos.server/repos/$i/trunk
> > svn co $repos svn/$i
> > git-svn clone $repos git/$i
> > done
> >
> > for i in `cd svn; echo *`; do diff --exclude /.svn -Nruw */$i; done
> >
> > With this, I see that four of the repositories are cloned as expected,
> > but the fifth has only the .git directory in it. It appears that
> > the clone command stopped cloning at r2008, while the repository is
> > currently at r3761. So almost the half of the history was not
> > cloned at all. I've investigated the offending revision and the
> > revisions around it, but I can't see anything special about them.
> > The effect is perfectly reproducible and it stops always on the very
> > same revision. I get no error message at all. I've attached the
> > last lines of the clone operation at the end of this mail.
>
> First of all: What does git --version say? Is it self-compiled git or
> git as it comes with U 8.10?
This is git-1.5.6.3 as it comes with U-8.10.
> Then: I assume the above is not quite what you did, otherwise I would be
> surprised you see a 4th and 5th clone...
That's correct. :-) I have actually changed the names and number of the
repositories to avoid disclosing too much privacy ;-)
> Your repo is probably one giant svn repo.
This are 5 repositories in total. The repos with the problem above is
the biggest of them (about 80MB, 3761 revisions). But on the other
machine the other repositories also have missing files.
> In any case, the fact that the
> repo is at $rev does not imply that the last commit on trunk is at $rev.
> What is the last commit on trunk?
While I have created the recommended tags/branches/trunk layout to be
prepared, there have never been commits to tags or branches. A long
time ago (at revisions 83..90) there were commits to /vendor, but after
r90 only trunk was ever used.
So all commits from r90 on were commits to trunk and none of the
revisions since r2008 up to HEAD ever touched anything outside trunk.
> Other than that: There are so many sins you can commit (!) in an svn
> repo that it it is hard to tell which one threw git-svn off. Can you
> share the repo?
Unfortunately not. :-(
> > Then I go to another machine and enter exactly the same commands as
> > above. Both machines are fresh ubuntu-8.10 default installs.
> >
> > To my surprise, on this other machine the clone operation seems to
> > have worked for all the repositories. But the diff command shows
> > me that arbitrary files are missing in _all_ of the repositories.
>
> I don't think computers behave deterministically, at least not according
> to my experience. After all they rely on quantum mechanics, and who has
> ever understood the measurement process, the collapsing of the wave
> function?
Although everything relies on quantum mechanics, common experience shows
that our world is much more deterministic than one would expect from
quantum theory. Have you ever seen a cat being dead and alive at the
same time? ;-)
> OK: Whenever I got 2 different results after doing the same twice I
> found that indeed some hidden/forgotten variable was not the same...
> Any chance you find one?
Well, I am new to git, so I was searching for help/guidance on the list.
BTW: I just found the git-fsck command:
Checking HEAD link
notice: HEAD points to an unborn branch (master)
Checking object directory
Checking reflog 0000..0000->e23f..6f50
[ 1998 more "Checking reflog" files deleted ]
Checking reflog 273e..5c24->43bb..aee6
Checking connectivity (32 objects)
Checking 03ea6bbee94997ab9ddaecb3088b460eb4b87636
Checking edcb1771f35ff085b7dfd546bcc51938f15a05d0
Checking d7c3ec4b134ebf151cf2e78f6af729ed3d345e0d
The output of this command looks a little bit strange to me as a
newcomer:
- "HEAD points to unborn branch" confirms that the import failed
- there are exactly 2000 "Checking reflog" lines. Since the last
imported revision was 2008, I would have expected 2008 (or 2007
or 2009) such lines. My first thought was this might be related
to the --repack option defaulting to 1000. But with --repack=570
it also stops after r2008.
- the "Checking connectivity" line mentions 32 objects, but only
three "Checking" lines are listed after that.
^ permalink raw reply
* Re: git fsck segmentation fault
From: Nicolas Pitre @ 2008-11-27 17:47 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Git Mailing List
In-Reply-To: <200811271814.06941.simon@lst.de>
On Thu, 27 Nov 2008, Simon Hausmann wrote:
> Hi,
>
> when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium sized
That version doesn't exist in the git repo.
> (930M) repository I get a segfault.
>
> The backtrace indicates an infinite recursion. Here's the output from the last
> few lines:
[...]
Could you try with latest master branch please? It is more robust
against some kind of pack corruptions that could send the code into
infinite loops.
Nicolas
^ permalink raw reply
* Re: [PATCH] sha1_file: avoid bogus "file exists" error message
From: Ian Hilt @ 2008-11-27 17:41 UTC (permalink / raw)
To: Joey Hess; +Cc: Git List
In-Reply-To: <20081126181928.GA31007@kodama.kitenet.net>
On Wed, 26 Nov 2008, Joey Hess wrote:
> Joey Hess wrote:
> > Note that in both occasions that I've seen this failure, it has not been
> > due to a missing directory, or bad permissions
>
> Actually, it was due to bad permissions. :-) Once git was fixed to
> actually say that, I figured out where to look to fix them.
This is strange since write_loose_object() which calls create_tmpfile()
checks for EPERM. Perhaps this should be done in create_tmpfile()?
^ permalink raw reply
* git fsck segmentation fault
From: Simon Hausmann @ 2008-11-27 17:14 UTC (permalink / raw)
To: Git Mailing List
Hi,
when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium sized
(930M) repository I get a segfault.
The backtrace indicates an infinite recursion. Here's the output from the last
few lines:
Checking commit ffffb0556074699814751f3b34526b3d6850c6f7
Checking blob ffffb4e9edf03e7f5643abc5603ca57e745c313d
Checking tree ffffde1114cdd0937cb798069b45f4ceadccd22f
Checking tree ffffe7e34be267ca55a6ae823f8bf31d7a8ef3cd
Checking blob ffffe8bbfc4d7adcb4e5fa00f1b4c99e26591b76
Checking tree ffffea81b8790b194ac215807165e3ff7f824320
Checking blob ffffec79ba618a429dee33bb0acb0ab36cb1310d
Checking tree fffff62eaba873e3ea3cfd7535e6ac514fd18332
Checking blob fffff6519569fac30b11b7bc830d61e296b7c5e2
Segmentation fault (core dumped)
gdb on the core file produces the following backtrace:
#0 0x0000000000487684 in unpack_object_header (p=0x26ad4c0, w_curs=0x7fff72f8a060, curpos=0x7fff72f8a058, sizep=0x7fff72f8a0c8) at sha1_file.c:1400
1400 base = use_pack(p, w_curs, *curpos, &left);
#0 0x0000000000487684 in unpack_object_header (p=0x26ad4c0, w_curs=0x7fff72f8a060, curpos=0x7fff72f8a058, sizep=0x7fff72f8a0c8) at sha1_file.c:1400
#1 0x000000000048827e in unpack_entry (p=0x26ad4c0, obj_offset=490508859, type=0x7fff72f8cd14, sizep=0x7fff72f8a004) at sha1_file.c:1693
#2 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490581247, type=0x7fff72f8cd14, sizep=0x7fff72f8a148) at sha1_file.c:1647
#3 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490679881, type=0x7fff72f8cd14, sizep=0x7fff72f8a1c8) at sha1_file.c:1647
#4 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490685453, type=0x7fff72f8cd14, sizep=0x7fff72f8a248) at sha1_file.c:1647
#5 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490689484, type=0x7fff72f8cd14, sizep=0x7fff72f8a2c8) at sha1_file.c:1647
#6 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490738466, type=0x7fff72f8cd14, sizep=0x7fff72f8a348) at sha1_file.c:1647
#7 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490744208, type=0x7fff72f8cd14, sizep=0x7fff72f8a3c8) at sha1_file.c:1647
#8 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490755670, type=0x7fff72f8cd14, sizep=0x7fff72f8a448) at sha1_file.c:1647
#9 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491146004, type=0x7fff72f8cd14, sizep=0x7fff72f8a4c8) at sha1_file.c:1647
#10 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491148469, type=0x7fff72f8cd14, sizep=0x7fff72f8a548) at sha1_file.c:1647
#11 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491150324, type=0x7fff72f8cd14, sizep=0x7fff72f8a5c8) at sha1_file.c:1647
#12 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491150930, type=0x7fff72f8cd14, sizep=0x7fff72f8a648) at sha1_file.c:1647
#13 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491549282, type=0x7fff72f8cd14, sizep=0x7fff72f8a6c8) at sha1_file.c:1647
#14 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491552398, type=0x7fff72f8cd14, sizep=0x7fff72f8a748) at sha1_file.c:1647
#15 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491552652, type=0x7fff72f8cd14, sizep=0x7fff72f8a7c8) at sha1_file.c:1647
#16 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491553208, type=0x7fff72f8cd14, sizep=0x7fff72f8a848) at sha1_file.c:1647
#17 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491556704, type=0x7fff72f8cd14, sizep=0x7fff72f8a8c8) at sha1_file.c:1647
#18 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491560658, type=0x7fff72f8cd14, sizep=0x7fff72f8a948) at sha1_file.c:1647
#19 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491582507, type=0x7fff72f8cd14, sizep=0x7fff72f8a9c8) at sha1_file.c:1647
#20 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491604310, type=0x7fff72f8cd14, sizep=0x7fff72f8aa48) at sha1_file.c:1647
#21 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491614312, type=0x7fff72f8cd14, sizep=0x7fff72f8aac8) at sha1_file.c:1647
#22 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491666142, type=0x7fff72f8cd14, sizep=0x7fff72f8ab48) at sha1_file.c:1647
#23 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491901113, type=0x7fff72f8cd14, sizep=0x7fff72f8cd08) at sha1_file.c:1647
#24 0x00000000004887ca in read_packed_sha1 (sha1=0x336ba64 "�W\004�\037d\203g��;v\032vF�>�R�", type=0x7fff72f8cd14, size=0x7fff72f8cd08) at sha1_file.c:1957
#25 0x00000000004889fe in read_object (sha1=0x336ba64 "�W\004�\037d\203g��;v\032vF�>�R�", type=0x7fff72f8cd14, size=0x7fff72f8cd08) at sha1_file.c:2047
#26 0x0000000000488bcc in read_sha1_file (sha1=0x26ad4c0 "", type=0x7fff72f8a060, size=0x1d3c923b) at sha1_file.c:2063
#27 0x000000000048f3fd in parse_tree (item=0x336ba60) at tree.c:224
#28 0x0000000000423a32 in mark_object (obj=0x336ba60, type=2, data=<value optimized out>) at builtin-fsck.c:102
#29 0x00000000004673bc in fsck_walk (obj=<value optimized out>, walk=0x423880 <mark_object>, data=0x336ba38) at fsck.c:26
#30 0x0000000000423a4a in mark_object (obj=0x336ba38, type=2, data=<value optimized out>) at builtin-fsck.c:105
#31 0x00000000004673bc in fsck_walk (obj=<value optimized out>, walk=0x423880 <mark_object>, data=0x66fff78) at fsck.c:26
#32 0x0000000000423a4a in mark_object (obj=0x66fff78, type=2, data=<value optimized out>) at builtin-fsck.c:105
#33 0x00000000004673bc in fsck_walk (obj=<value optimized out>, walk=0x423880 <mark_object>, data=0x66c9a28) at fsck.c:26
#34 0x0000000000423a4a in mark_object (obj=0x66c9a28, type=2, data=<value optimized out>) at builtin-fsck.c:105
#35 0x0000000000467299 in fsck_walk (obj=0x6bea7b0, walk=0x423880 <mark_object>, data=0x6bea7b0) at fsck.c:50
#36 0x000000000042390d in mark_object (obj=0x6bea7b0, type=1, data=<value optimized out>) at builtin-fsck.c:105
#37 0x00000000004672d1 in fsck_walk (obj=<value optimized out>, walk=0x423880 <mark_object>, data=0x3283fd0) at fsck.c:57
#38 0x000000000042390d in mark_object (obj=0x3283fd0, type=1, data=<value optimized out>) at builtin-fsck.c:105
#39 0x00000000004672d1 in fsck_walk (obj=<value optimized out>, walk=0x423880 <mark_object>, data=0x3283f88) at fsck.c:57
#40 0x000000000042390d in mark_object (obj=0x3283f88, type=1, data=<value optimized out>) at builtin-fsck.c:105
[...]
The stack trace in total has about ~80000 frames.
Does anyone have any suggestions on how to debug this?
Thanks,
Simon
^ permalink raw reply
* Re: [PATCH] git-p4: fix keyword-expansion regex
From: Simon Hausmann @ 2008-11-27 16:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pete Wyckoff, git
In-Reply-To: <7vljv6fcr0.fsf@gitster.siamese.dyndns.org>
On Wednesday 26 November 2008 Junio C Hamano, wrote:
> I will queue this to 'pu' and wait for an Ack from git-p4 folks. Thanks.
Acked-by: Simon Hausmann <simon@lst.de>
Simon
^ permalink raw reply
* [StGit] Import file(s) problem
From: Shinya Kuribayashi @ 2008-11-27 16:08 UTC (permalink / raw)
To: catalin.marinas, kha; +Cc: git
Hi Catalin and Karl,
Today I encountered a problem when importing a patch. I don't know this
is a known issue or not. If there are good workarounds for this, I'd
like to know that. Any comments are appreciated.
Steps to reproduce
-------------------
1. Prepare a patch, say stg-test.patch
2. Rename it to have '..' extension
$ mv stg-test.patch stg-test..patch
3. Import it
$ stg import /path/to/stg-test..patch
You can see a lot of errors. See the log below.
4. At this point, just few stg operations are available. I had to
switch to an other branch, then force deleting the corrupted branch
to return to the original state.
Note
-----
The same goes to stg import -m [e-mail file]. So this seems to be
trigged due to the wrong '..' extension.
Log
----
skuribay@ubuntu:~/kernel/stgit.git$ (modify some file(s))
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ stg diff >> ../stg-test.patch
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ stg status --reset
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ stg branch --create foo
Checking for changes in the working directory ... done
Recording as a local branch
Branch "foo" created
skuribay@ubuntu:~/kernel/stgit.git$ cd ../
skuribay@ubuntu:~/kernel$
skuribay@ubuntu:~/kernel$ mv stg-test.patch stg-test..patch
skuribay@ubuntu:~/kernel$
skuribay@ubuntu:~/kernel$ cd -
/home/skuribay/kernel/stgit.git
skuribay@ubuntu:~/kernel/stgit.git$ stg import ../stg-test..patch
Checking for changes in the working directory ... done
fatal: Cannot lock the ref 'refs/patches/foo/stg-test..patch'.
Traceback (most recent call last):
File "/home/skuribay/bin/stg", line 43, in <module>
main()
File "home/skuribay/lib/python2.5/site-packages/stgit/main.py", line 175, in main
File "home/skuribay/lib/python2.5/site-packages/stgit/main.py", line 154, in _main
File "home/skuribay/lib/python2.5/site-packages/stgit/commands/common.py", line 482, in write_log
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 372, in compat_log_entry
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 322, in log_entry
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 179, in from_stack
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 179, in <genexpr>
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 157, in get
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/git.py", line 486, in __getitem__
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 147, in create_patch
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 26, in commit
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/git.py", line 449, in get
KeyError: 'refs/patches/foo/stg-test..patch'
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ stg diff
Error: Unhandled exception:
Traceback (most recent call last):
File "home/skuribay/lib/python2.5/site-packages/stgit/main.py", line 142, in _main
File "home/skuribay/lib/python2.5/site-packages/stgit/commands/common.py", line 491, in setup
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 524, in compat_log_external_mods
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 511, in log_external_mods
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 322, in log_entry
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 179, in from_stack
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 179, in <genexpr>
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 157, in get
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/git.py", line 486, in __getitem__
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 147, in create_patch
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 26, in commit
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/git.py", line 449, in get
KeyError: 'refs/patches/foo/stg-test..patch'
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ stg series
> stg-test..patch
skuribay@ubuntu:~/kernel/stgit.git$ stg branch master
Error: Unhandled exception:
Traceback (most recent call last):
File "home/skuribay/lib/python2.5/site-packages/stgit/main.py", line 142, in _main
File "home/skuribay/lib/python2.5/site-packages/stgit/commands/common.py", line 501, in setup
File "home/skuribay/lib/python2.5/site-packages/stgit/commands/common.py", line 495, in setup
File "home/skuribay/lib/python2.5/site-packages/stgit/commands/common.py", line 491, in setup
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 524, in compat_log_external_mods
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 511, in log_external_mods
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 322, in log_entry
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 179, in from_stack
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/log.py", line 179, in <genexpr>
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 157, in get
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/git.py", line 486, in __getitem__
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 147, in create_patch
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/stack.py", line 26, in commit
File "home/skuribay/lib/python2.5/site-packages/stgit/lib/git.py", line 449, in get
KeyError: 'refs/patches/foo/stg-test..patch'
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ git checkout master
Switched to branch "master"
skuribay@ubuntu:~/kernel/stgit.git$ stg branch -l
Available branches:
s foo |
> s master |
skuribay@ubuntu:~/kernel/stgit.git$ stg branch --delete foo
Deleting branch "foo" ...
stg branch: Cannot delete: the series still contains patches
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ stg branch --delete --force foo
Deleting branch "foo" ...
Warning: refs/patches/foo/stg-test..patch does not exist
done
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ stg branch -l
Available branches:
> s master |
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ rm -f ../stg-test..patch
skuribay@ubuntu:~/kernel/stgit.git$
skuribay@ubuntu:~/kernel/stgit.git$ stg version
Stacked GIT 0.14.3.285.g62874
git version 1.5.4.3
Python version 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
skuribay@ubuntu:~/kernel/stgit.git$
Thanks,
Shinya
^ permalink raw reply
* Re: Dangling blob after git gc
From: Miklos Vajna @ 2008-11-27 13:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqzljlnuwo.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Thu, Nov 27, 2008 at 02:46:47PM +0100, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> from man git-gc:
>
> The optional configuration variable gc.pruneExpire controls
> how old the unreferenced loose objects have to be before
> they are pruned. The default is "2 weeks ago".
>
> Git can hardly know for sure whether a dangling object is actually a
> temporary object used by another instance of git or actually an unused
> object. Older versions of Git required you to explicitely say --prune
> to mean "OK, _I_ am sure, you can prune the objects", newer do it the
> safe way by removing only objects old enough.
So it was a user error, thanks for pointing out the relevant
documentation. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Dangling blob after git gc
From: Matthieu Moy @ 2008-11-27 13:46 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20081127133027.GW4746@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> The commits are probably due to reflogs, that's OK. But why do I have a
> dangling blob after git gc? The interesting part is that as you can see
> most of them is removed, but not all.
>
> Any ideas? :)
from man git-gc:
The optional configuration variable gc.pruneExpire controls
how old the unreferenced loose objects have to be before
they are pruned. The default is "2 weeks ago".
Git can hardly know for sure whether a dangling object is actually a
temporary object used by another instance of git or actually an unused
object. Older versions of Git required you to explicitely say --prune
to mean "OK, _I_ am sure, you can prune the objects", newer do it the
safe way by removing only objects old enough.
--
Matthieu
^ permalink raw reply
* [PATCH] bash: offer refs instead of filenames for 'git revert'
From: SZEDER Gábor @ 2008-11-27 13:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
The completion script for 'git revert' currently offers options and
filenames. However, 'git revert' doesn't take any filenames from the
command line, but a single commit. Therefore, it's more sane to offer
refs instead.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 39bf18b..7e668d5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1348,7 +1348,7 @@ _git_revert ()
return
;;
esac
- COMPREPLY=()
+ __gitcomp "$(__git_refs)"
}
_git_rm ()
--
1.6.0.4.814.gfe502
^ permalink raw reply related
* [PATCH] bash: complete full refs
From: SZEDER Gábor @ 2008-11-27 13:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Sometimes it's handy to complete full refs, e.g. the user has some
refs outside of refs/{heads,remotes,tags} or the user wants to
complete some git command's special refs (like 'git show
refs/bisect/bad').
To do that, we check whether the ref to be completed starts with
'refs'. If it does, then we offer full refs for completion; otherwise
everything works as usual.
This way the impact on the common case is fairly small (hopefully not
many users have branches or tags starting with 'refs'), and in the
special case the cost of typing out 'refs' is bearable.
While at it, also remove the unused 'cmd' variable from '__git_refs'.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0ee071b..39bf18b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -188,11 +188,22 @@ __git_tags ()
__git_refs ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local i is_hash=y dir="$(__gitdir "$1")"
+ local cur="${COMP_WORDS[COMP_CWORD]}" format refs
if [ -d "$dir" ]; then
- if [ -e "$dir/HEAD" ]; then echo HEAD; fi
- git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
- refs/tags refs/heads refs/remotes
+ case "$cur" in
+ refs*)
+ format="refname"
+ refs="${cur%/*}"
+ ;;
+ *)
+ if [ -e "$dir/HEAD" ]; then echo HEAD; fi
+ format="refname:short"
+ refs="refs/tags refs/heads refs/remotes"
+ ;;
+ esac
+ git --git-dir="$dir" for-each-ref --format="%($format)" \
+ $refs
return
fi
for i in $(git ls-remote "$dir" 2>/dev/null); do
--
1.6.0.4.814.gfe502
^ permalink raw reply related
* [PATCH] bash: remove dashed command leftovers
From: SZEDER Gábor @ 2008-11-27 13:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Commit 5a625b07 (bash: remove fetch, push, pull dashed form leftovers,
2008-10-03) did that already, but there were still some git-cmd left
here and there.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 41 ++++++-------------------------
1 files changed, 8 insertions(+), 33 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 35e8ff7..0ee071b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -635,21 +635,12 @@ _git_branch ()
_git_bundle ()
{
- local mycword="$COMP_CWORD"
- case "${COMP_WORDS[0]}" in
- git)
- local cmd="${COMP_WORDS[2]}"
- mycword="$((mycword-1))"
- ;;
- git-bundle*)
- local cmd="${COMP_WORDS[1]}"
- ;;
- esac
- case "$mycword" in
- 1)
+ local cmd="${COMP_WORDS[2]}"
+ case "$COMP_CWORD" in
+ 2)
__gitcomp "create list-heads verify unbundle"
;;
- 2)
+ 3)
# looking for a file
;;
*)
@@ -797,12 +788,7 @@ _git_fetch ()
__gitcomp "$(__git_refs)" "$pfx" "${cur#*:}"
;;
*)
- local remote
- case "${COMP_WORDS[0]}" in
- git-fetch) remote="${COMP_WORDS[1]}" ;;
- git) remote="${COMP_WORDS[2]}" ;;
- esac
- __gitcomp "$(__git_refs2 "$remote")"
+ __gitcomp "$(__git_refs2 "${COMP_WORDS[2]}")"
;;
esac
fi
@@ -1049,12 +1035,7 @@ _git_pull ()
if [ "$COMP_CWORD" = 2 ]; then
__gitcomp "$(__git_remotes)"
else
- local remote
- case "${COMP_WORDS[0]}" in
- git-pull) remote="${COMP_WORDS[1]}" ;;
- git) remote="${COMP_WORDS[2]}" ;;
- esac
- __gitcomp "$(__git_refs "$remote")"
+ __gitcomp "$(__git_refs "${COMP_WORDS[2]}")"
fi
}
@@ -1067,19 +1048,13 @@ _git_push ()
else
case "$cur" in
*:*)
- local remote
- case "${COMP_WORDS[0]}" in
- git-push) remote="${COMP_WORDS[1]}" ;;
- git) remote="${COMP_WORDS[2]}" ;;
- esac
-
local pfx=""
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) pfx="${cur%%:*}:" ;;
esac
- __gitcomp "$(__git_refs "$remote")" "$pfx" "${cur#*:}"
+ __gitcomp "$(__git_refs "${COMP_WORDS[2]}")" "$pfx" "${cur#*:}"
;;
+*)
__gitcomp "$(__git_refs)" + "${cur#+}"
@@ -1584,7 +1559,7 @@ _git_tag ()
-m|-F)
COMPREPLY=()
;;
- -*|tag|git-tag)
+ -*|tag)
if [ $f = 1 ]; then
__gitcomp "$(__git_tags)"
else
--
1.6.0.4.814.gfe502
^ permalink raw reply related
* Dangling blob after git gc
From: Miklos Vajna @ 2008-11-27 13:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
Hi,
$ git version
git version 1.6.0.4
$ git fsck
dangling blob 070011dddba40fe0066cbebfe51ea6d160f95af8
dangling blob 3ec00c535bbac37f738971a5ad14bb11892c5863
dangling commit c180face4d2451f9e77f41d4f9d4f3ad7cbd51c0
(...)
So I have multiple dangling blobs/trees/commits, let's do a gc.
$ git gc
Counting objects: 96978, done.
Compressing objects: 100% (25044/25044), done.
Writing objects: 100% (96978/96978), done.
Total 96978 (delta 70392), reused 96978 (delta 70392)
$ git fsck
dangling commit 2302e3fd37e808d3240ffa887ea1c22cac9cb770
dangling commit 0a2bc7013d49e0695242ffc2d57360d0396c22ea
dangling blob c330f89bcc20b1c9ca689e66062d086562e0633d
dangling commit ac319ab8d187e818f2dd05774175a2a7feb9696e
dangling commit a5f5b7956f7d63bab13d3f2c45c7315cfbea28b8
The commits are probably due to reflogs, that's OK. But why do I have a
dangling blob after git gc? The interesting part is that as you can see
most of them is removed, but not all.
Any ideas? :)
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-svn and svn branches
From: Michael J Gruber @ 2008-11-27 10:02 UTC (permalink / raw)
To: Eric Wong; +Cc: Ryan Phillips, git
In-Reply-To: <20081125230823.GA6664@mayonaise>
Eric Wong venit, vidit, dixit 26.11.2008 00:08:
> Ryan Phillips <ryan@trolocsis.com> wrote:
>> I followed the following instructions on adding a remote svn branch to my
>> local git-svn repository. http://www.dmo.ca/blog/20070608113513
>>
>> Are these still accurate?
>>
>> I started the repository with
>> # git svn init [url/trunk]`
>> # cd project.git
>> # git svn fetch -r[HEAD revision]
>> which works fine. I added something like Snippet 1 to the .git/config and
>> issued a `git svn fetch -r[HEAD revision of the branch]` and nothing
>> happens. It takes git-svn a few seconds to run, but the git-remote svn
>> branch doesn't get initialized.
>>
>> Does this procedure only work with a full mirror of a git-svn repository?
>> or perhaps I'm doing something wrong. Any help would be appreciated.
>>
>> Thanks,
>> Ryan
>>
>> Snippet 1
>> =========
>>
>> [svn-remote "svn34"]
>> url = svn+ssh://your-server/home/svn/project-name/branches/3.4.x
>> fetch = :refs/remotes/git-svn-3.4
>
> Try this:
>
> git svn fetch -i svn34
>
> It's been a while since I've used this, but I believe a test
> case covers it so it probably still works :)
>
Uhm, I think it's rather "-R svn34" which tells git-svn to use the svn
remote config "svn34". -i sets GIT_SVN_ID.
Michael
^ 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