[petsc-dev] I hate this one

Sean Farley sean.michael.farley at gmail.com
Mon Jan 21 19:04:55 CST 2013


On Mon, Jan 21, 2013 at 6:18 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> On Mon, Jan 21, 2013 at 6:02 PM, Matthew Knepley <knepley at gmail.com> wrote:
>>>
>>>     Eventually I hope to get to a stage where the format in the
>>> repository is fixed but we have a tool (uncrustify is pretty good, but not
>>> perfect) that puts it in that form when committing/pushing? into the
>>> repository. This way you can have your uncrustify style that you use in your
>>> copy and only when it is committed/pushed? does it go into the standard
>>> format. This will make the tab-lovers, the else \n { lovers, the random
>>> weird spaces in some place lovers, etc all happy.  We could even consider
>>> just living with the limitations of uncrustify today, which would mean me
>>> dropping a few of my objections, …
>
> Hg may have something similar, but git has "clean" and "smudge" filters that
> can be used to keep the working tree somehow different from what is in the
> repository. If someone wants to operate with a working tree that has
> different formatting, they set filter-clean and filter-smudge commands. The
> diffs they see will always be "clean", but the working tree can be smudged
> to their desire.

Yeah, but I'm sure you will agree that this is a tad bit dangerous
(merge conflicts?). I would put this in the category of "feature of
last resort." The equivalent way would be to use an extension, such as
this one:

http://www.fast-downward.org/ForDevelopers/Uncrustify

(don't know if it's still current) or to define your own filters for
doing the "smudge"-ing. It would probably be the same rule and maybe
even a one-liner in python but I haven't tried it yet.



More information about the petsc-dev mailing list