[petsc-dev] Style Guide: How to format single-line if/for/while-blocks?

[Sean Farley]

On Mon, Jan 21, 2013 at 10:32 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> On Mon, Jan 21, 2013 at 10:08 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>> > If anyone wants to do this with git, I can show you how. I think you'll
>> > find it's not as nice to work with as you may have hoped, not through a
>> > failing of the tool, but because we also communicate through side channels.
>>
>> Well I think it is insane in 2012 that we all need to stare at the exact
>> same ASCII strings with the exact same placement (each of you thinks is
>> wrong) when we develop shared code, so please teach me how.
>
>
> This has a nice picture of the way clean clean and smudge filters work.
>
> http://git-scm.com/book/ch7-2.html#Keyword-Expansion
>
> The idea is that you tell git to use your filter in a place that is not
> checked into the repository:
>
> echo '*.c filter=petscfmt' >> .git/info/attributes
>
> (If you wanted it to be checked in, you'd put it in .gitattributes, but we
> don't want that now.) Then set what the petscfmt filter does
>
> git config filter.petscfmt.clean 'uncrustify read from stdin and write clean
> version to stdout'
> git config filter.petscfmt.smudge 'uncrustify read from stdin and write
> smudged version to stdout'
>
> The smudged version is whatever the user wants to interact with, the cleaned
> version is whatever should go in the PETSc repository. (You can also just
> edit these filters in .git/config.)

Does this just basically run or regex / uncrustify filter before a
commit and after a checkout? Or is there something more fancy going
on? What does the user see when there's a merge conflict?