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?
