On Mon, Nov 24, 2014 at 09:41:00AM -0800, Junio C Hamano wrote:
> We actually do not have a reference to it anywhere. For now, this
> should suffice.
>
> Documentation/SubmittingPatches | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/SubmittingPatches b
On 2014-11-24 18.41, Junio C Hamano wrote:
...
>>> Do we refer to t/README from CodingGuidelines where we tell the
>>> developers to always write tests to prevent other people from
>>> breaking tomorrow what you did today? If not, perhaps that is what
>>> needs to be added.
>>
>> That might make s
Jeff King writes:
> On Sun, Nov 23, 2014 at 10:10:47AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > ... Possibly because I do not know that those instructions
>> > are written down anywhere. We usually catch such things in review these
>> > days, but there are many inconsistent s
Torsten Bögershausen schrieb am 22.11.2014 um 15:59:
>>> +test_expect_success 'error out when attempting to add ignored ones but add
>>> others' '
>>> + touch a.if &&
>>> + test_must_fail git add a.?? &&
>>> + ! (git ls-files | grep "\\.ig") &&
>>> + (git ls-files | grep a.if)
>>> +'
>>
>>
Jeff King schrieb am 21.11.2014 um 19:01:
> On Fri, Nov 21, 2014 at 05:08:19PM +0100, Michael J Gruber wrote:
>
>> "git add foo bar" adds neither foo nor bar when bar is ignored, but dies
>> to let the user recheck their command invocation. This becomes less
>> helpful when "git add foo.*" is subj
On Sat, Nov 22, 2014 at 10:20:10PM +0100, Torsten Bögershausen wrote:
> > I do not think there is a real _downside_ to using test_must_fail for
> > grep, except that it is a bit more verbose.
> We may burn CPU cycles
It adds a single if/else chain. If your shell does not implement that as
a fast
On Sun, Nov 23, 2014 at 10:10:47AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... Possibly because I do not know that those instructions
> > are written down anywhere. We usually catch such things in review these
> > days, but there are many inconsistent spots in the existing suite.
Jeff King writes:
> ... Possibly because I do not know that those instructions
> are written down anywhere. We usually catch such things in review these
> days, but there are many inconsistent spots in the existing suite.
t/README has this
Don't:
- use '! git cmd' when you want to mak
On 2014-11-22 20.19, Jeff King wrote:
> On Sat, Nov 22, 2014 at 03:59:12PM +0100, Torsten Bögershausen wrote:
>
+test_expect_success 'error out when attempting to add ignored ones but
add others' '
+ touch a.if &&
+ test_must_fail git add a.?? &&
+ ! (git ls-files | gr
On Sat, Nov 22, 2014 at 03:59:12PM +0100, Torsten Bögershausen wrote:
> >> +test_expect_success 'error out when attempting to add ignored ones but
> >> add others' '
> >> + touch a.if &&
> >> + test_must_fail git add a.?? &&
> >> + ! (git ls-files | grep "\\.ig") &&
> >> + (git ls-files | gre
>> +test_expect_success 'error out when attempting to add ignored ones but add
>> others' '
>> +touch a.if &&
>> +test_must_fail git add a.?? &&
>> +! (git ls-files | grep "\\.ig") &&
>> +(git ls-files | grep a.if)
>> +'
>
> I am somewhat allergic to pipes in our test suite, becau
On Fri, Nov 21, 2014 at 05:08:19PM +0100, Michael J Gruber wrote:
> "git add foo bar" adds neither foo nor bar when bar is ignored, but dies
> to let the user recheck their command invocation. This becomes less
> helpful when "git add foo.*" is subject to shell expansion and some of
> the expanded
"git add foo bar" adds neither foo nor bar when bar is ignored, but dies
to let the user recheck their command invocation. This becomes less
helpful when "git add foo.*" is subject to shell expansion and some of
the expanded files are ignored.
"git add --ignore-errors" is supposed to ignore errors
13 matches
Mail list logo
