determine if local installation of a git repo needs updating, without relying on tag / release# / version#

[caver456]

Most of the NCSSAR home-brew python repo's don't use version numbering. While the clean way to do things would be to add version numbering / tag numbering to each repo, that's not completely reliable - what if a hotfix is made but no new tag is or the version number is not incremented? Then a simple version# / tag# comparison would not show a need for an update.

So, to be safer, compare the contents of the installation to the contents of the repo head. A recursive diff of the unzipped downloaded repo head would be one way.

To avoid doing this download-and-compare more often than necessary, maybe keep track of when the latest comparison was run, and what the file modification times were when the comparison was run, and run a comparison again if there are any file modification times more recent than the last comparison? Would need to account for config files / 'local' directories inside the unzipped dir tree, which would intentionally differ from the repo head.

Is there a better way?

[robsheldon]

Why "without relying on tag / etc..."? Mostly curious. Tags are the usual way to do this, afaik.

[caver456]

I haven't used tags at all on any repo's - to rely on tags would mean adding the manual step of creating a tag to the workflow every time a new commit is done, right? Regardless of whether it seems easy and seems like a good habit to get into anyway, the chances of forgetting to do that seem high.

…

On Mon, Jun 13, 2022 at 6:29 AM Rob Sheldon ***@***.***> wrote: Why "without relying on tag / etc..."? Mostly curious. Tags are the usual way to do this, afaik. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEPCEZQHK5DO4MGQBTW5QKLVO4ZSJANCNFSM5YUG2ENA> . You are receiving this because you authored the thread.Message ID: ***@***.***>