discuss commit d969624 - how to merge with 2.0 about serendipity HOT 9 CLOSED

Does this not get even more worse then? I would prefere a quick cherry pick, but I simply do not know if that merges or drops and what happens on conflict lines by those plugins being already changed in 2.0 only?

from serendipity.

Why would you cherry pick stuff which would have to be merged anyway?

We can not be sure that everything in master has been upported to 2.0. So we're going to have to merge. Yes, that's not going to be an easy merge, merge conflicts are likely. Still it's the only way to ensure we end up with a consistent 2.0 which includes all of master.

Merge conflicts are not necessarily “bad”. They just need to be resolved.

from serendipity.

Because this commit was quite huge!
To have resolved that already would definitely be good to have, when there are other possible future merge conflicts. If you have ever seens files with merge conflict marks, you don't want to have much of them. 😉

Also then we would try to merge 2.0 into master, I presume, and since I do not really understand how a merge works in depth, I would be a little worried to have a mess or lose stuff afterwards. (Example: a commit at master removed in file n line 5 starting whitespacing and commit branch did change something in the following text, but still having these whitespaces. What does a merge or cherry port really do? Take everything of both, or merge by commit timeline only, or by what? There may be even more complicated examples thinkable. How does that merge really know what to keep, to merge and to purge (in every case)?

from serendipity.

I have seen files with merge conflicts markers, that's why I don't get why this is such a big deal.

Not to be disrespectful, but could it be that the real issue here is “since I do not really understand how a merge works in depth, I would be a little worried to have a mess or lose stuff”? Because I don't see it that way.

from serendipity.

Sure! If you are so well known with that and ensure that it isn't a big problem, I'll be glad.
I still carry my inner scepsis on automated things, to imagine what really happens in detail, even if I have read some docs... but I never merged before and so is my unsureness until having some (more) experiences.

from serendipity.

Guys, we already merged 2.0 and master. If you consequently upport everything you add to master to 2.0, in case it is needed there, our merge of 2.0 and master could be

1. delete all files in master
2. copy files from 2.0
3. git add, git commit, git push.

just don't let master diverge anymore.

from serendipity.

I'm not the “merge master”, but I also don't see the reason for your scepsis. This is why we use a version control system. We can even “try” this merge by creating more (local) branches.

But if your inner scepsis wants to go ahead an cherry-pick/upport this, go ahead. I just don't see the point in it.

from serendipity.

@onli That's just why I would still want to merge master in 2.0 at some point – that's a rather huge “if”. :-)

from serendipity.

Seems like there's no need for futher discussion here. If so, please use the forum.

from serendipity.