Manage conflict markers

Hi André,

for some reasons, I sometimes use aStyle with files containing git conflict markers. Here's an example with this command line:

-r -A1 -S -w -p -H -k1 -U -Q -X -n -z1 -xn --squeeze-lines=3 

Original code:

void system_state_machine__init(void)
{
     m_states[ssmsCooling] = system_state_cooling__get_new();
<<<<<<< HEAD
    m_states[ssmsRpmThrustLinearization] = system_state_calibrate_acceleration_curve__get_new();
    m_states[ssmsCalibrateAccelerationCurve] = system_state_calibrate_acceleration_curve__get_new();

=======
    m_states[ssmsRpmThrustLinearization] = system_state_starter_linearization__get_new();
    m_states[ssmsCalibrateAccelerationCurve] = system_state_starter_linearization__get_new();
>>>>>>> main

    // test if no instanciation was forgotten. Only for development purpose
    for (uint8_t i = 0 ; i < lastSystemStateMachineState ; i++)
    {
        assert(m_states[i]);
    }
 }

Styled code with last version:

void system_state_machine__init(void)
{
    m_states[ssmsCooling] = system_state_cooling__get_new();
            <<< <<< < HEAD
            m_states[ssmsRpmThrustLinearization] = system_state_calibrate_acceleration_curve__get_new();
    m_states[ssmsCalibrateAccelerationCurve] = system_state_calibrate_acceleration_curve__get_new();

    == == == =
        m_states[ssmsRpmThrustLinearization] = system_state_starter_linearization__get_new();
    m_states[ssmsCalibrateAccelerationCurve] = system_state_starter_linearization__get_new();
            >>> >>> > main

            // test if no instanciation was forgotten. Only for development purpose
            for (uint8_t i = 0 ; i < lastSystemStateMachineState ; i++)
    {
        assert(m_states[i]);
    }
}

It seems that astyle considers conflict markers as operators and this causes erratic indentation of the first line following each marker.

I imagine two ways to manage this which could be, why not, managed as options. Both solve the erratic indent of the following line.

• Interpret conflict markers as simple comments.
  • Pro: I imagine it would be easy to implement.
  • Con: formatting the text beetween the markers might not be relevant depending on the conflicting code.
• Don't format anything beetween (including)conflict markers.
  • Pro:
    • conflicting code will not interfere with non conflicting code formatting (in case of conflicting code containing a different number of opening and closing brackets)
    • Preserve conflicting code which might ease the resolution of conlicts.
  • Con:
    • One might want to have the conflicting code formatted....

I know that it's a border line use the it will be usefull (at least for me! 😆 )

Have a nice day.

Julien