Using Git to check update changes

Management and Administration
1

I currently manage an Openemr 5.0.2 instance and am beginning the process of upgrading to V7. We do have some customizations and therefore cannot upgrade directly following the update processes.

Instead I’m using git to compare the current Openemr directory with the new version by copying all the files from the new version into my git repo.

I am curious if any more experienced users can see any potential issues with this method? In particular im concerned with the steps such as:

Copy following directory from old 5.0.2 version to /openemr directory:

    openemr_bk/sites/default/documents (COPY TO) => openemr/sites/default/documents

Copy the openemr/sites/default/sqlconf.php file from your old 5.0.2 version into the new openemr version

In the openemr/sites/default/sqlconf.php file, set the $config variable (found near bottom of file within bunch of slashes) to 1 ($config = 1;)

My assumption is that since I’m not copying the V6 directory completely I should be able to skip these steps, but I may be wrong.

Would I also be able to clone this v6 version into a separate directory in /var/www/html/ to test?

2

hi @amrit_padda, compare a backup of the current codebase with where the code diverged from 5.0.2 (aka find the most recent common commit)

Here’s some advice from Brady:

Steps:

  1. Make a copy of the repo with customizations and in that copy delete the .git directory

  2. In a standard repo, git checkout to where the code diverged

  3. Then use rsync to copy all the stuff from the code with customizations (the one without the .git folder) into the standard repo

  4. At this point, then do git add . (to ensure new files added), and then git commit -am "new code", and then voila

if you don’t have a repo, but just have the modified codebase, then can skip the remove .git directory part

:sunglasses:

btw, i use rsync instead of cp since rync also copies hidden files (ones with . at beginning)

rsync --recursive --exclude .git modified/openemr standardrepos/

3

Thanks for the reply Stephen, the changes we made were actually quite small so there isn’t much diversion occurring. But since I have the new changed files in a separate backup dir, I will try merging them into v6 and see what happens.

I think your suggestion applies more to a large change in the codebase with multiple commits.

As for testing, would creating a new directory in /var/www/html/ with my v6 code work? I would expect some sql related issues since the SQL update wouldn’t be done yet, but the UI should load right?

4

hi @amrit_padda, okay, I’d test on a separate server. Also would make a branch off of rel-703 and add your customizations there.

5

@amrit_padda out of curiosity, do you have your changes in a fork of the original openemr repository that branched off a 5.0.2 version such as GitHub - openemr/openemr at rel-502?

The git merge-base command is really useful for finding the common base after branching. From there, you can also see if there are commits in the rel-502 branch that aren’t in master (and not strictly in any of the rel-* branches after 502). You can also use a tool like gitk to visualize the flow of commits from the current commit to a more modern version.

For me:

$ git merge-base upstream/rel-502 upstream/master
43827b53658796af2996b48e63a97f6bcc64dc87
$ git log -1 $(git merge-base upstream/rel-502 upstream/master)
commit 43827b53658796af2996b48e63a97f6bcc64dc87
Author: Brady Miller <brady.g.miller@gmail.com>
Date:   Sun Jul 14 13:06:08 2019 -0700

    remove unused Filtreatment class (#2559)
$ git log --oneline $(git merge-base upstream/rel-502 upstream/master)...upstream/rel-502 | wc -l
     171

showing there are 171 commits from when 502 diverged from master. These are for patching, of course. Specifically:

$ git log --oneline --decorate=full $(git merge-base upstream/rel-502 upstream/master)...upstream/rel-502  | grep -F '(tag: ' 
babec93f6 (tag: refs/tags/v5_0_2_4) Final 502 batch payments. Yeah right! (#3828)
672120934 (tag: refs/tags/v5_0_2_3) prepping for patch 3 release
94409d012 (tag: refs/tags/v5_0_2_2) patch sql fix
728f4bdd4 (tag: refs/tags/v5_0_2_1) typo reported and fixed in forum (#2716)
35a67d115 (tag: refs/tags/v5_0_2) 5.0.2 sql upgrade fixes

The patch commits should actually reflect changes that did make it into master, but because the base is different, they show up differently and may make it a bit confusing to follow the trail of changes. That’s why it’s useful to know where the merge base is.

Another useful tool is the git cherry command, which can tell you if commits in a branch have also been applied to another branch. The command outputs a list of commits prefixed with - when an equivalent commit is in upstream, and + when the commit has not been applied to upstream.

$ git cherry upstream/master upstream/rel-502 | grep -c '^-'
84

So you can use this to identify which of the 170 commits in rel-502 that are not shared with master are effectively in master after branching.

Ultimately, if your fork is not very different from core, then it’s probably easiest to encapsulate your changes and then re-apply them after updating, especially if your fork doesn’t include database changes. But since this post is about using git to check the changes, I thought it’d be useful for me to talk about git merge-base and cherry.

1 Like
6

In my case the changes are small enough that I can just reapply, but out of curiosity, is there any additional build steps required when using git for version control with openemr changes?

For example if I were to setup my server to pull the latest release from my git repo, would I have to add any additional build steps?

1 Like
7

It really depends on the nature of the changes.

If there are database migrations, then you’d need to apply those.

If there are changes to composer.lock or package-lock.json, you’d need to do the appropriate install.

If you want it to be fully automatic, then you’d need to detect if there are database migrations and only apply them if necessary.

1 Like
8

Hi @amrit_padda. You have to run thru these bulid steps when deploying from source.