* Re: summaries in git add --patch
From: Jakub Narebski @ 2008-11-27 21:27 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <492F0CAD.3010101@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> I just implemented a command to give a brief summary
> of the patches in the current file.
Good idea.
Side note: you should signoff your patches, following
Documentation/SubmittingPatches. And it would be better
if the patches itself were either threaded, or all be
replies to this cover letter ([PATCH 0/5]) email.
> 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
I hope that contrary to this 'screenshot' actual output is aligned
properly...
> 3 : @@ -128,7 +128,7 @@ abdest
> 4-: @@ -81192,9 +81192,9 @@ gyrous
> 5 : @@ -234925,7 +234925,7 @@ zymotic
That of course assumes that summary catches right thing; still
it is better than nothing.
> @@ -88,7 +88,7 @@ abaton
> abator
> abattoir
> Abatua
> -abature
> +agature
> abave
> abaxial
> abaxile
Same here.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] bash: remove dashed command leftovers
From: Shawn O. Pearce @ 2008-11-27 21:24 UTC (permalink / raw)
To: SZEDER GGGbor; +Cc: git
In-Reply-To: <1227792938-4006-1-git-send-email-szeder@ira.uka.de>
SZEDER GGGbor <szeder@ira.uka.de> wrote:
> 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>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
I really appreciate you taking the time to clean up existing code.
Its never fun, but it really helps to keep it from rotting.
> ---
> contrib/completion/git-completion.bash | 41 ++++++-------------------------
> 1 files changed, 8 insertions(+), 33 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Fix typos in the documentation.
From: Ralf Wildenhues @ 2008-11-27 21:16 UTC (permalink / raw)
To: Andreas Ericsson, Junio C Hamano; +Cc: git
In-Reply-To: <492E6415.6080101@op5.se>
Hello Andreas, Junio,
* Andreas Ericsson wrote on Thu, Nov 27, 2008 at 10:10:45AM CET:
> Ralf Wildenhues wrote:
>>
>> This patch is against pu.
> 'pu' is a moving target in git. For future reference, it's
> better to send patches against 'master'.
* Junio C Hamano wrote on Thu, Nov 27, 2008 at 10:48:56AM CET:
>
> While I appreciate your fix, it would have been nicer to have at least
> three patches in this case, organized like this:
Both obvious improvements. Thanks for teaching me again how to properly
behave on this list, I've not been following it for a while and forgot.
Cheers, and keep up the good work,
Ralf
^ permalink raw reply
* [JGIT PATCH 4/4] Automatically clean up any repositories created by the test cases
From: Robin Rosenberg @ 2008-11-27 21:15 UTC (permalink / raw)
To: spearce; +Cc: git, fonseca, Robin Rosenberg
In-Reply-To: <1227820535-9785-4-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../org/spearce/jgit/lib/RepositoryTestCase.java | 21 +++++++++++++++++++-
1 files changed, 20 insertions(+), 1 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 ef4fd1b..cab65a0 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
@@ -45,6 +45,7 @@
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Reader;
+import java.util.ArrayList;
import junit.framework.TestCase;
import org.spearce.jgit.util.JGitTestUtil;
@@ -145,6 +146,8 @@ protected static void checkFile(File f, final String checkData)
private static int testcount;
private static Thread shutdownhook;
+ private ArrayList<Repository> repositoriesToClose = new ArrayList<Repository>();
+
public void setUp() throws Exception {
super.setUp();
System.gc();
@@ -192,6 +195,20 @@ copyFile(JGitTestUtil.getTestResourceFile(packs[k] + ".idx"), new File(packDir,
protected void tearDown() throws Exception {
db.close();
+ for (Repository r : repositoriesToClose) {
+ r.close();
+ }
+ // Since memory mapping is controlled by the GC we need to
+ // tell it this is a good time to clean up and unlock
+ // mmemory mapped files.
+ System.gc();
+
+ recursiveDelete(trash, false, getName());
+ for (Repository r : repositoriesToClose) {
+ recursiveDelete(r.getWorkDir(), false, getName());
+ }
+ repositoriesToClose.clear();
+
super.tearDown();
}
@@ -209,12 +226,14 @@ protected Repository createNewEmptyRepo() throws IOException {
assertTrue(unusedDir.mkdirs());
final Repository newRepo = new Repository(newTestRepo);
newRepo.create();
+ final String name = getClass().getName() + "." + getName();
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
- recursiveDelete(newTestRepo);
+ recursiveDelete(newTestRepo, false, name);
}
});
+ repositoriesToClose.add(newRepo);
return newRepo;
}
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* [JGIT PATCH 2/4] Add shutdown hooks to try to clean up after unit tests anyway
From: Robin Rosenberg @ 2008-11-27 21:15 UTC (permalink / raw)
To: spearce; +Cc: git, fonseca, Robin Rosenberg
In-Reply-To: <1227820535-9785-2-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../org/spearce/jgit/lib/RepositoryTestCase.java | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 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 9c272f6..ef4fd1b 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,8 +66,8 @@
jcommitter = new PersonIdent("J. Committer", "jcommitter@example.com");
}
- protected static boolean recursiveDelete(final File dir) {
- return recursiveDelete(dir, false, null);
+ protected boolean recursiveDelete(final File dir) {
+ return recursiveDelete(dir, false, getClass().getName() + "." + getName());
}
protected static boolean recursiveDelete(final File dir, boolean silent,
@@ -161,6 +161,12 @@ public void run() {
};
Runtime.getRuntime().addShutdownHook(shutdownhook);
}
+ Runtime.getRuntime().addShutdownHook(new Thread() {
+ @Override
+ public void run() {
+ recursiveDelete(trash);
+ }
+ });
db = new Repository(trash_git);
db.create();
@@ -197,12 +203,18 @@ protected void tearDown() throws Exception {
* @throws IOException
*/
protected Repository createNewEmptyRepo() throws IOException {
- File newTestRepo = new File(trashParent, "new"+System.currentTimeMillis()+"/.git");
+ final File newTestRepo = new File(trashParent, "new"+System.currentTimeMillis()+"/.git");
assertFalse(newTestRepo.exists());
File unusedDir = new File(trashParent, "tmp"+System.currentTimeMillis());
assertTrue(unusedDir.mkdirs());
final Repository newRepo = new Repository(newTestRepo);
newRepo.create();
+ Runtime.getRuntime().addShutdownHook(new Thread() {
+ @Override
+ public void run() {
+ recursiveDelete(newTestRepo);
+ }
+ });
return newRepo;
}
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* [JGIT PATCH 3/4] Cleanup malformed test cases
From: Robin Rosenberg @ 2008-11-27 21:15 UTC (permalink / raw)
To: spearce; +Cc: git, fonseca, Robin Rosenberg
In-Reply-To: <1227820535-9785-3-git-send-email-robin.rosenberg@dewire.com>
---
.../tst/org/spearce/jgit/lib/PackWriterTest.java | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
index e5bce4d..3c02955 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
@@ -309,6 +309,7 @@ public void testWritePack4ThinPack() throws IOException {
public void testWritePack2SizeDeltasVsNoDeltas() throws Exception {
testWritePack2();
final int sizePack2NoDeltas = cos.getCount();
+ tearDown();
setUp();
testWritePack2DeltasReuseRefs();
final int sizePack2DeltasRefs = cos.getCount();
@@ -327,6 +328,7 @@ public void testWritePack2SizeDeltasVsNoDeltas() throws Exception {
public void testWritePack2SizeOffsetsVsRefs() throws Exception {
testWritePack2DeltasReuseRefs();
final int sizePack2DeltasRefs = cos.getCount();
+ tearDown();
setUp();
testWritePack2DeltasReuseOffsets();
final int sizePack2DeltasOffsets = cos.getCount();
@@ -344,6 +346,7 @@ public void testWritePack2SizeOffsetsVsRefs() throws Exception {
public void testWritePack4SizeThinVsNoThin() throws Exception {
testWritePack4();
final int sizePack4 = cos.getCount();
+ tearDown();
setUp();
testWritePack4ThinPack();
final int sizePack4Thin = cos.getCount();
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* [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
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