On Fri, Mar 20, 2015 at 1:10 AM, Jeff King p...@peff.net wrote:
On Thu, Mar 19, 2015 at 10:25:32PM -0400, Jeff King wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c096778..02a03d5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -524,6 +524,21 @@ test_eval_ () {
test_run_
On Thu, Mar 19, 2015 at 9:32 PM, Jeff King p...@peff.net wrote:
On Thu, Mar 19, 2015 at 09:16:52PM -0400, Eric Sunshine wrote:
--- /dev/null
+++ b/t/t5312-prune-corruption.sh
@@ -0,0 +1,104 @@
+# we do not want to count on running pack-refs to
+# actually pack it, as it is perfectly
On Thu, Mar 19, 2015 at 09:16:52PM -0400, Eric Sunshine wrote:
--- /dev/null
+++ b/t/t5312-prune-corruption.sh
@@ -0,0 +1,104 @@
+# we do not want to count on running pack-refs to
+# actually pack it, as it is perfectly reasonable to
+# skip processing a broken ref
On Thu, Mar 19, 2015 at 10:25:32PM -0400, Jeff King wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c096778..02a03d5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -524,6 +524,21 @@ test_eval_ () {
test_run_ () {
test_cleanup=:
expecting_failure=$2
+
+ if
On Tue, Mar 17, 2015 at 3:28 AM, Jeff King p...@peff.net wrote:
When we are doing a destructive operation like git prune,
we want to be extra careful that the set of reachable tips
we compute is valid. If there is any corruption or oddity,
we are better off aborting the operation and letting
On Thu, Mar 19, 2015 at 09:37:12PM -0400, Eric Sunshine wrote:
Thanks. I notice that a large number of broken -chains are on
here-docs. I really wish you could put the on the EOF line at the
end of the here-doc. I understand _why_ that this not the case, but
mentally it is where I want
[+cc Jonathan, whose patch I apparently subconsciously copied]
On Thu, Mar 19, 2015 at 10:08:51PM -0400, Jeff King wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c096778..02a03d5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -524,6 +524,21 @@ test_eval_ () {
test_run_ () {
Jeff King p...@peff.net writes:
+test_expect_success 'create history with missing tip commit' '
+ test_tick git commit --allow-empty -m one
+ recoverable=$(git rev-parse HEAD)
+ git cat-file commit $recoverable saved
+ test_tick git commit --allow-empty -m two
+
Jeff King p...@peff.net writes:
A safer check may be to pack and then make it missing, I guess, but
I do not know if the difference matters.
Yeah, I considered that. The trouble is that we are relying on the
earlier setup that made the object go missing. We cannot pack the refs
in the setup
On Thu, Mar 19, 2015 at 01:04:16PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+test_expect_success 'create history with missing tip commit' '
+ test_tick git commit --allow-empty -m one
+ recoverable=$(git rev-parse HEAD)
+ git cat-file commit $recoverable
On Thu, Mar 19, 2015 at 02:23:25PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
A safer check may be to pack and then make it missing, I guess, but
I do not know if the difference matters.
Yeah, I considered that. The trouble is that we are relying on the
earlier
Jeff King p...@peff.net writes:
So I'm inclined to leave it (we do confirm with the rev-parse call at
the end of the setup that our packed-refs file is working) unless you
feel strongly. If you do, I'd rather go the route of sticking each
corruption in its own separate sub-repo.
No, I don't
On Thu, Mar 19, 2015 at 02:49:37PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So I'm inclined to leave it (we do confirm with the rev-parse call at
the end of the setup that our packed-refs file is working) unless you
feel strongly. If you do, I'd rather go the route of
Am 17.03.2015 um 19:55 schrieb Jeff King:
+ echo $bogus .git/refs/heads/bogus..name
...
I assumed the final . in your example wasn't significant (it is not to
git), but let me know if I've run afoul of another weird restriction. :)
It was actually deliberate (with intents too
When we are doing a destructive operation like git prune,
we want to be extra careful that the set of reachable tips
we compute is valid. If there is any corruption or oddity,
we are better off aborting the operation and letting the
user figure things out rather than plowing ahead and
possibly
On Tue, Mar 17, 2015 at 07:34:02PM +0100, Johannes Sixt wrote:
Am 17.03.2015 um 08:28 schrieb Jeff King:
+test_expect_success 'create history reachable only from a bogus-named ref' '
+test_tick git commit --allow-empty -m master
+base=$(git rev-parse HEAD)
+test_tick git
Am 17.03.2015 um 08:28 schrieb Jeff King:
+test_expect_success 'create history reachable only from a bogus-named ref' '
+ test_tick git commit --allow-empty -m master
+ base=$(git rev-parse HEAD)
+ test_tick git commit --allow-empty -m bogus
+ bogus=$(git rev-parse
17 matches
Mail list logo
