Problem committing tests

Problem committing tests

[Stephen Berman]

I wanted to include some tests with the fix for bug#27121 that I just
committed to master (d76c007); however, git complained about trailing
whitespace in two data files for the tests.  This whitespace is part of
the file format used by todo-mode.el, so I cannot delete it.  I see that
the .gitattributes file in the repository lists several test files for
which whitespace warnings should be ignored; should I add the todo-mode
test data files to the list?  Or is there another or better way to tell
git to ignore this whitespace and commit the files?

Steve Berman

Re: Problem committing tests

[martin rudalics]

 > I wanted to include some tests with the fix for bug#27121 that I just
 > committed to master (d76c007); however, git complained about trailing
 > whitespace in two data files for the tests.  This whitespace is part of
 > the file format used by todo-mode.el, so I cannot delete it.  I see that
 > the .gitattributes file in the repository lists several test files for
 > which whitespace warnings should be ignored; should I add the todo-mode
 > test data files to the list?  Or is there another or better way to tell
 > git to ignore this whitespace and commit the files?

Please do add the name of your file there.  Unfortunately, this is not
always done and so git doesn't commit here when resolving a conflict
after a pull by telling me (as of last week) something like

admin/unidata/Makefile.in:122: new blank line at EOF.

and I have to locally commit -n.  Someone proposed a fix for this but it
apparently never made it to the repository.  It's a pain because I tend
to forget about this issue until I get bitten by it the next time ...

martin

Re: Problem committing tests

[Noam Postavsky]

On Mon, May 29, 2017 at 2:41 AM, martin rudalics <rudalics@gmx.at> wrote:
> Please do add the name of your file there.  Unfortunately, this is not
> always done and so git doesn't commit here when resolving a conflict
> after a pull by telling me (as of last week) something like
>
> admin/unidata/Makefile.in:122: new blank line at EOF.
>
> and I have to locally commit -n.  Someone proposed a fix for this but it
> apparently never made it to the repository.  It's a pain because I tend
> to forget about this issue until I get bitten by it the next time ...

I believe the hooks were modified in [1: e20ad449de], *but* you have
to rerun './autogen git' to update them in your local checkout.

[1: e20ad449de]: 2017-04-29 11:42:13 -0700
  Allow bypassing of some checks when merging
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e20ad449deefa7470386bf99e05fd8c67227f678

Re: Problem committing tests

[martin rudalics]

 > I believe the hooks were modified in [1: e20ad449de], *but* you have
 > to rerun './autogen git' to update them in your local checkout.
 >
 > [1: e20ad449de]: 2017-04-29 11:42:13 -0700
 >    Allow bypassing of some checks when merging
 >    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e20ad449deefa7470386bf99e05fd8c67227f678

Thanks.  I apparently missed that.

martin

Re: Problem committing tests

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]


() Stephen Berman <stephen.berman@gmx.net>
() Mon, 29 May 2017 00:40:48 +0200

   I wanted to include some tests with the fix for bug#27121
   that I just committed to master (d76c007); however, git
   complained about trailing whitespace in two data files for
   the tests.  This whitespace is part of the file format used
   by todo-mode.el, so I cannot delete it.  I see that the
   .gitattributes file in the repository lists several test
   files for which whitespace warnings should be ignored; should
   I add the todo-mode test data files to the list?  Or is there
   another or better way to tell git to ignore this whitespace
   and commit the files?

I think it would be cool to restructure the process so that the
eol ws-requiring data is generated at run-(test-)time from data
that has no eol ws.  This is more work, but:

- It is explicit.
- It avoids possible future lossage if the DVCS changes.
- It avoids possible future lossage via PEBKAC or ignorance.
  (Just think, what if that fool ttn fubars this somehow!?)
- If the work should happen to be algorithmic (it is, what a
  surprise! :-D), it could be generalized and re-used.
- If it is written well, it could be documented and exported.

So, i urge you to put in the effort here, slap your name on it,
and bask in the glory of future Q/A chains terminating w/ a
time-saving link to righteous code (and relax{ed,ing} docs).

IOW, it is good to cope, better to create, best to invest.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Problem committing tests

[Stephen Berman]

On Mon, 29 May 2017 09:10:35 +0200 Thien-Thi Nguyen <ttn@gnu.org> wrote:

> () Stephen Berman <stephen.berman@gmx.net>
> () Mon, 29 May 2017 00:40:48 +0200
>
>    I wanted to include some tests with the fix for bug#27121
>    that I just committed to master (d76c007); however, git
>    complained about trailing whitespace in two data files for
>    the tests.  This whitespace is part of the file format used
>    by todo-mode.el, so I cannot delete it.  I see that the
>    .gitattributes file in the repository lists several test
>    files for which whitespace warnings should be ignored; should
>    I add the todo-mode test data files to the list?  Or is there
>    another or better way to tell git to ignore this whitespace
>    and commit the files?
>
> I think it would be cool to restructure the process so that the
> eol ws-requiring data is generated at run-(test-)time from data
> that has no eol ws.  This is more work, but:

Unfortunately, it is more than I currently have time for with my
knowledge of and experience with git and the Emacs test environment.

> - It is explicit.
> - It avoids possible future lossage if the DVCS changes.
> - It avoids possible future lossage via PEBKAC or ignorance.
>   (Just think, what if that fool ttn fubars this somehow!?)
> - If the work should happen to be algorithmic (it is, what a
>   surprise! :-D), it could be generalized and re-used.
> - If it is written well, it could be documented and exported.
>
> So, i urge you to put in the effort here, slap your name on it,
> and bask in the glory of future Q/A chains terminating w/ a
> time-saving link to righteous code (and relax{ed,ing} docs).
>
> IOW, it is good to cope, better to create, best to invest.

I agree, but I'm afraid being good is the best I can hope for for now.
So I'll wait a bit to see if any other manageable suggestions come up,
otherwise I'll do the .gitattributes workaround.

Steve Berman