I'm against a workflow that involves bots for a nothing-burger like
trailing whitespace. Either auto-cleanup on commit and have the server
check on push that it was cleaned up. Or nothing at all. But waiting a day
and then have a bot come back with trailing whitespace nonsense is just an
unnece
On 2018-02-20 21:47, Jeroen Demeyer wrote:
> Interesting fact: the number of lines with trailing whitespace is
> generally *increasing* with every Sage release. So it seems to me that
> the biggest problem (if you find whitespace a problem) is preventing new
> whitespace.
So, there should be a tra
How are merge conflicts handled, and is there any use for priority-flag on
trac? It would make sense that lower priority tickets would be merged
after more important ones.
--
Jori Mäntysalo
If I recall, when I originally setup the git-trac server, I included a hook
that would reject/warn any introduction of new trailing whitespace. I
believe this was a compromise made after a long discussion at a Sage days
-- there were a lot of concerns at the time about the effort required to
rebase
Interesting fact: the number of lines with trailing whitespace is
generally *increasing* with every Sage release. So it seems to me that
the biggest problem (if you find whitespace a problem) is preventing new
whitespace.
--
You received this message because you are subscribed to the Google Gr
First of all, we should ensure that no new trailing whitespace is added.
Otherwise, your effort is futile. The recently added file
src/sage/rings/valuation/valuation_space.py is a bad example.
I recall that we had a discussion about autogenerated patchbombs not so
long ago. I think it's a bad
How do we feel about large patches full of whitespace cleanup? Lots
of Sage modules have stray whitespace, and my editor usually
automatically removes it when I open files (this is a personal
preference that I have to live with though).
Usually when preparing patches this means manually removing
