Git merge conflicts with morph-files

Hi,

We track our projects with git. Sometimes we run into merge conflicts when we do for instance bugfixing on development branch and we want to pull this into feature branches or vice versa.
This occurs most often with branches with a long life span.

It is not always easy to decide when we look at the XML which part we want to keep (the part from the branch we merge into or the branch that is merged).

In most cases it is the meta tags that change and the question is: does it matter which version we accept ?

How can we decide easily on merge conflicts in morph files ?

For example the type of merge conflicts we run into.

Thanks
Nikolaas

The order of MetaColumn tags doesn’t matter. You can always accept a change that only changes the order.

ok thanks. Does it matter when metadata columns differ between versions ? Is suppose that makes a difference ?

Yes, it matters.

Hi Dmitry,

Again a merge conflict.

When I look at the 2 files from the 2 branches and I open them in EasyMorph and I compare the action where the merge conflict occurs, I cannot see any difference.

How can I decide what to accept as change ?

How are these differences generated in EasyMorph so as to better understand where this difference comes from ?

Thanks !

Nikolaas

It looks like the order of MetaColumns has changed but they themselves didn’t.

You can update EasyMorph to the most recent version. Now it should preserve the order of metacolumns.

Yes we need to update. We are still on an old version…

I’m curious, what stops you from updating to a more recent version?

Two reasons:

  • We want to finalize some flows and move them to production first.
  • Availability of a technical person to update the software and deploy it on al our workspaces.

@dgudkov:

Additional question. When we upgrade EasyMorph and we have multiple branches in git.
If we for instance modify a morph file after the upgrade of EM and we merge the branch back into e.g. development branch (which in fact contains morph files created in older versions), would this lead to merge conflicts ?
Or can we always upgrade to a more recent version without getting into trouble ?

We are now on version 4.7.1.9

Thanks
Nikolaas

It may, or may not lead to merge conflicts. If you want to avoid merge conflicts, make changes in one branch only. Don’t make changes in other branches.

If you’re going to change two branches at the same time, it can lead to merge conflicts, no matter if you work with EasyMorph projects or any other text-based files. This behavior is not specific to EasyMorph.

Hi Dmitry,

Yes that I understand. But what’s not clear is what happens when we upgrade EasyMorph when we are working on a feature branch.

E.g. We have a feature branch based on development. Then we upgrade EasyMorph to the latest version. We continue work on the feature branch. Development is not touched. When we then merge the feature branch, could it generate merge conflicts because maybe the XML-structure of the morph file is quite different when compared with the old version of EasyMorph ?

Thanks !
Nikolaas

A new version doesn’t change projects until you save them in the new version. Saving a project in a new version is like changing it.

Hi Dmitry,
Could you just elaborate more on the MetacolumnTag ? What’s the purpose of that tag?
How can I see what it does ?
What happens when I choos a “wrong” version (same action in both branches but different set of Metacolumn tags) ?

Thanks !
Nikolaas

Hi Nikolaas,

It describes the formatting of a new column that will be created by this action - its number/date format and column width.

If it changes, it will change how the column appears in the datagrid.