On 2018-02-17 11:30, Norman Dunbar wrote:
Morning All,
it's currently 10:25 UK time. My emails to the list seem to be taking
a few days to get to the docs list at the moment, so I've no idea if
or when you will see this!
At the beginning of the week, SourceForge moved datacenters, and
something went wrong pretty badly, it should have been fixed Friday (or
maybe yesterday), as some of my messages I sent during the week were
delivered, but some of the messages I sent yesterday have only now shown
up. Chances are there are still some lingering problems, or maybe
DNS-related issues.
I've updated the gfix manual to resolve issue DOC-129 whereby the
sweep interval was incorrectly defined.
I've raised a pull request from my specially created branch DOC-129
for the resolution.
While I am able to merge this fix into master, I cannot merge it into
B_release though. I get the impression that B_Release either didn't
come across correctly, or is too far out of date from Master as
attempting to merge my DOC-129 branch into B_release gives lots of
conflict errors.
$git merge DOC-129
[..]
Git status gives screens and screens of new files to be added, and 9
modified files, from the 10 files listed above, to have their
conflicts fixed.
Listed above is fbutils_gfix.xml but it isn't listed in the git status
output as a conflicting file. Oh joy! It also doesn't have any
conflict markers.
$git merge --abort cleaned up the mess from the merge.
The same happens if I experiment with merging master into B_Release
(in my local copy of my fork - so no damage done!) Another --abort
cleaned up there too.
Has anyone else been able to merge new documents or changes into
B_Release?
It looks like up to now, changes were cherry picked by manually copying
them unto the branch, or at least, most commits on B_Release seem to
copy a specific state onto release, without retaining history from
master. This probably explains why merging a branch from master onto
B_Release doesn't work.
I'm not sure if there is an easy way to fix this with git in a way that
matches with how B_Release is used. Maybe Paul or Helen could describe
the logical steps how B_Release is supposed to be used, and we can then
see how we can best do that with git.
Depending on the exact needs, it might take some advanced git-fu, and
the simplest solution may turn out to be to just copy the latest state
and commit that to B_Release, without merging the specific file-history
on the branch.
Mark
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs
