On Fri, Mar 20, 2015 at 1:10 AM, Jeff King 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_r
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=
[+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_ ()
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 w
On Thu, Mar 19, 2015 at 9:32 PM, Jeff King 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
> > +tes
On Tue, Mar 17, 2015 at 3:28 AM, Jeff King 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 the
> use
On Thu, Mar 19, 2015 at 02:49:37PM -0700, Junio C Hamano wrote:
> Jeff King 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 stick
Jeff King 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 feel stron
On Thu, Mar 19, 2015 at 02:23:25PM -0700, Junio C Hamano wrote:
> Jeff King 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 setu
Jeff King 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 step,
On Thu, Mar 19, 2015 at 01:04:16PM -0700, Junio C Hamano wrote:
> Jeff King 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
Jeff King 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 &&
> +
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 compli
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_
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 re
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 de
17 matches
Mail list logo
