Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[thistleknot]

So... If I can get an answer to this... maybe... just maybe... I can do a CL equivalent.

http://stackoverflow.com/questions/25388806/github-3-way-merge-patch

If the only solution is a github solution and manual editing of raws... then nm.  But hopefully, if this works by merging non conflicting merge conflicts, then maybe we can merge say plantfixes and direforge.

non conflicting meaning, things like different tokens being written to the same line should equal write both to their own lines.

[King Mir]

EDIT: Didn't understand the problem.

The short answer is no, because we want to be conservative about allowing conflicting mods. If you don't care about failing on true conflicts, then you may have some luck making a smarter merge tool that sometimes does the wrong thing.

I'm working on a 3 way merge script atm, (testing it at this point) but I don't plan to make it too fancy, because I don't want to merge mods that really do conflict.

[Button]

So as an update on this here's what I found:
2)the two larger mods modify c_variation_default.txt with the same changes, which should be ok.

Rreally? They should have compatible but different changes, in different locations.

[King Mir]

So as an update on this here's what I found:
2)the two larger mods modify c_variation_default.txt with the same changes, which should be ok.

Rreally? They should have compatible but different changes, in different locations.

Woops. Good catch. You're right. Changes are in different locations, so there is no problem.

[thistleknot]

EDIT: Didn't understand the problem.

The short answer is no, because we want to be conservative about allowing conflicting mods. If you don't care about failing on true conflicts, then you may have some luck making a smarter merge tool that sometimes does the wrong thing.

I'm working on a 3 way merge script atm, (testing it at this point) but I don't plan to make it too fancy, because I don't want to merge mods that really do conflict.

I'm sorry, i've been keeping up like 80% of the posts since about page 5 or 6, I parsed through page 5 and didn't see where you reference n way merges.  The thought is familiar, I'd love to see your solution.

[King Mir]

EDIT: Didn't understand the problem.

The short answer is no, because we want to be conservative about allowing conflicting mods. If you don't care about failing on true conflicts, then you may have some luck making a smarter merge tool that sometimes does the wrong thing.

I'm working on a 3 way merge script atm, (testing it at this point) but I don't plan to make it too fancy, because I don't want to merge mods that really do conflict.

I'm sorry, i've been keeping up like 80% of the posts since about page 5 or 6, I parsed through page 5 and didn't see where you reference n way merges.  The thought is familiar, I'd love to see your solution.

N-way merge algorithm here:
http://www.bay12forums.com/smf/index.php?topic=142295.msg5579007#msg5579007

Basically just keep doing a 3 way merge between the mod being added, vanilla, and the merge of all previous mods.

[thistleknot]

I looked at the psuedo.

My hope and goal was not to spend too much effort on testing merge conflicts.

But rather, to do a simple if check, if the point of conflict is due to the patch file assuming the source was unchanged

If the patch file can somehow just find the correct INSERTION point.  It could insert the data as long as the data it was inserting was not specifically REMOVED.  I think that can be adopted somehow, somewhere, not sure exactly though.

The case with direforge and the fixplants is the case I brought up.  Button said those two could have been merged automatically.  Github has a feature like that, so does tortoisegitmerge.  To lay one set of changes on top of the other.

This is what I was thinking.  If there was a simple if check at that point of insertion to verify if the reason for conflict was due to both patch files assuming the point of insertion was this, but it something else (due to the way of sequential patches, so I would think checking the original vanilla raws, and if the vanilla raws match the patch file, the insert at correct insertion point), but the prior point of insertion matches then maybe just insert anyways?

[King Mir]

If two mods add content to the same spot, like to the same creature, there is a high chance that the merges conflict, especially if they also remove a tag in that spot.

[thistleknot]

so you want to avoid those merges?

if the contents of the patch don't match and/or conflict with the contents of the other patch that affect the same place, I think it could safely be applied.  The data would be in within the two patch files.

[Button]

If two mods add content to the same spot, like to the same creature, there is a high chance that the merges conflict, especially if they also remove a tag in that spot.

The question is, though, what about two mods that add content to the same spot because that's the natural place to add things? Like, at the end of a creature variation definition for instance. It's usual to add new tags at the end of the variation, not in the middle somewhere.

[thistleknot]

If two mods add content to the same spot, like to the same creature, there is a high chance that the merges conflict, especially if they also remove a tag in that spot.

The question is, though, what about two mods that add content to the same spot because that's the natural place to add things? Like, at the end of a creature variation definition for instance. It's usual to add new tags at the end of the variation, not in the middle somewhere.

that's my point.  If the two patch files based on vanilla are MERELY ADDITIVE (for this Use Case), then I think both can be additive.

If one is SUBTRACTIVE, and the other doesn't subtract it.  Then... that could be cause for alarm, but I would think to subtract it if one mod did and the other didn't.

But...

if one added a line, and the other removed a line FROM VANILLA.  that would be a huge red flag, this mod can't be applied without manual intervention.

I think if one could keep track of the changes between two different modded versions, and figure if they added or deleted current vanilla tokens... (when the patch is being loaded).

Then that logic could be carried forward into insertion/deletions.

It would/could cause duplicates though.

[King Mir]

Think about this simple case: 1 mod adds a creature specific token at the end of a creature definition. another adds a creature. If you add them in the wrong order, you could get the creature specific token to the wrong creature if you don't order the merge right.

[King Mir]

If two mods add content to the same spot, like to the same creature, there is a high chance that the merges conflict, especially if they also remove a tag in that spot.

The question is, though, what about two mods that add content to the same spot because that's the natural place to add things? Like, at the end of a creature variation definition for instance. It's usual to add new tags at the end of the variation, not in the middle somewhere.

Then they might add conflicting content. I'd err on the side of safety and not allow the modification. Unless they are adding the same content, in which case you don't want to add it twice.

[Meph]

How automated do you want to have it? I have merged dozens of mods by hand, its not that much work...

[King Mir]

How automated do you want to have it? I have merged dozens of mods by hand, its not that much work...

The idea is to have it completely automated and able to merge and remove mods.