Doug Kelly writes:
> On Mon, Dec 29, 2014 at 9:42 AM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
+ (git am --abort || true) &&
>>
>> Why (x || y)? Is 'x' so unreliable that we do not know how should exit?
>> Should this be "test_must_fail git am --abort"?
>>
> Updated to test
On Mon, Dec 29, 2014 at 9:42 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>>> + (git am --abort || true) &&
>
> Why (x || y)? Is 'x' so unreliable that we do not know how should exit?
> Should this be "test_must_fail git am --abort"?
>
Updated to test_might_fail -- we don't know if
Eric Sunshine writes:
>> + (git am --abort || true) &&
Why (x || y)? Is 'x' so unreliable that we do not know how should exit?
Should this be "test_must_fail git am --abort"?
>> + (cd submodule && git rev-parse HEAD >../actual) &&
"git -C submodule rev-parse HEAD >actual" perhaps?
On Sat, Dec 27, 2014 at 6:37 PM, Eric Sunshine wrote:
>
> On Fri, Dec 26, 2014 at 6:11 PM, Doug Kelly wrote:
> > git am will break when using diff.submodule=log; add some test cases
> > to illustrate this breakage as simply as possible. There are
> > currently two ways this can fail:
> >
> > * W
On Fri, Dec 26, 2014 at 6:11 PM, Doug Kelly wrote:
> git am will break when using diff.submodule=log; add some test cases
> to illustrate this breakage as simply as possible. There are
> currently two ways this can fail:
>
> * With errors ("unrecognized input"), if only change
> * Silently (no su
git am will break when using diff.submodule=log; add some test cases
to illustrate this breakage as simply as possible. There are
currently two ways this can fail:
* With errors ("unrecognized input"), if only change
* Silently (no submodule change), if other files change
Test for both condition
6 matches
Mail list logo
