jason0 wrote on Monday, December 19, 2011:
I would like to be able to point into the openemr repository and know what point patches are made. Would this be a good use of a tag in git?
-jason
bradymiller wrote on Tuesday, December 20, 2011:
Hi Jason,
Here’s a quick rundown of how a patch is created:
1. All commits from ‘master’ branch that are deemed to be in the 4.1.0 patch are taken over to the ‘rel-410’ branch. If there are any database mods, then these are migrated to the sql/patch.sql file (key point is that they are not added to the database.sql file). Then when a patch is made, basically all changed files are copied to the patch (along with sql_patch.php and sql/patch.sql to support the database updates of the patch), and the patch number in version.php is incremented 1.
Also covered in following wiki pages:
http://www.open-emr.org/wiki/index.php/Patch_Mechanism
http://www.open-emr.org/wiki/index.php/Steps_for_a_patch_release
Regarding the git tag for each patch; several issues to consider:
1) Another step that takes yet more time to release a patch
2) Since database changes are not in database.sql, note even if grab that code that is tagged, still need to run sql_patch.php script after install.
3) Over time, would accumulate a very large number of tags (possibly distract from the official version release tags)
Open to advice here, but would like to avoid anything that will add more resources (ie. my time) to the process of releasing and tracking the patches 
-brady
yehster wrote on Tuesday, December 20, 2011:
Brady leaves commit comments in the rel-410 branch that make it pretty clear where the patch happened.
I think it really depends on what Jason is hoping to achieve.
Right now the way I would figure out what is in the patch it to just look at the history of the rel-410 branch and look for the comments.
If you are trying to pull the code for a “specific patch” I think you can refer to a particular commit by its GUID.
jason0 wrote on Tuesday, December 20, 2011:
All of that makes sense. In fact, as usual I have some more reading to do.
I generally deploy out of a git repository set to the rel-410 branch. I have noticed that stuff gets committed from time to time into that branch as it gets approved/blessed by one of the integration developers.
When I upgrade someone, I typically do it to the head of the rel-410 branch after doing a “git pull”, as opposed to a particular patch level. I can read the version.php and/or the version table in the database to know the patchlevel. There’s a caveat though: Instead of knowing someone is at “patchlevel 4” as shown in version.php, they really are “somewhere version 4 and 5”.
I have considered adding my own details such as copying the commit id into a file. When I read up on tags though, I realized it might be a better answer. A tag’s point in the repository doesn’t change, and the output of gitk, and/or git log shows its place. I also know that I can put tags into my own repository with impunity especially since the one I use for deployment is never pushed to a remote.
It seemed like a good idea. in terms of work, I think it’s a simple “git tag” command. In addition to allowing any of us to reproduce an exact version at any time in the future, I would find it useful when troubleshooting a new customer’s problems, and finding what changes they made. All I would need to do is clone the repository, checkout the taglevel the customer is at, then run diff -r.
-jason