Lite Repo Merge Strategy Flawed

[jaswrks]

The problem is explained here. It has to do with us currently depending only on --strategy-option=theirs, which doesn't deal with deleted files as one would expect it to.

A possible solution is to use git reset 000000-dev and work from there.

$ git checkout master
$ git reset 000000-dev

Or maybe to detect a non-zero exit status when attempting the merge with --strategy-option=theirs. If that fails and git status --porcelain shows 'deleted by them' as the only problem (should be the only problem), we can iterate deletion conflicts and remove them automatically. Inspired by: http://stackoverflow.com/a/20846795/1219741

[raamdev]

Also noting these steps that I followed to get around this issue while releasing Comment Mail v160618:

$ git checkout master
$ git reset 000000-dev
$ git add --all
$ git commit -m 'Manually pushing 000000-dev into master'
$ git merge -m 'Merge remote-tracking branch 'refs/remotes/origin/master'
$ git push

UPDATE 2016-06-18 20:52:52 EDT:

The above ↑ commands may not have worked. It could've been an error on my part (e.g., I forgot t reproduce a Phing step prior to running those commands), but what I ended up with on the remote GitHub repo was just an old copy of master, i.e., not updated. However, I suspect that this was because I did not first update 000000-dev with the updated files generated by Phing before doing the git reset 000000-dev.

In any case, care should be taken before assuming the above steps "just work".

[raamdev]

Noting that one common reason for master to get behind dev, at least on the Lite repo, is that publishing an RC release via the Phing build system does not update the master branch, but does update the dev branch.

[jaswrks]

@raamdev Just checking in here. Any additional thoughts on this issue? Has this been an ongoing problem for you? Anything come to mind that we could do to avoid this?

[jaswrks]

Sorry, I'm not asking you to solve this. I'm just looking for some inspiration here. I'm not exactly sure what needs to change on this yet, because I haven't personally run into this just yet.

[raamdev]

@jaswsinc Yes, this is still an issue I deal with during every release (as you can see from all of the GitHub issues linked to this issue above). Or at least I should say that it's an issue I still account for during every release.

I have the following step in my release plan template to ensure that I don't run into this problem during a release:

Following those steps above before doing a final phing release, I never run into any issues.

[jaswrks]

I see. So if I understand correctly, this is not an issue you've run into again yet because you've been running through those steps to ensure it doesn't happen to you again.

I'm just looking back over my original comments following our original conversation about this, where I noted that:

The problem is explained here. It has to do with us currently depending only on --strategy-option=theirs, which doesn't deal with deleted files as one would expect it to.

I'm beginning to remember how this occurred now. It only happens when the master branch has deletions, and those deletions are still present in the dev branch (e.g., files added back in). In such a case, even using --strategy-option=theirs doesn't allow Git to automatically resolve conflicts.

[raamdev]

It only happens when the master branch has deletions, and those deletions are still present in the dev branch (e.g., files added back in).

That sounds right, yes. Its been awhile since this issue occurred to me and I can't recall details about what caused it.