Correct. It is not a tag-expander really. Although placeholders might be a solution to some issues I have, the initial research I did discouraged all of that so I did not explore it really and tried to deal with package.json, bower.json, etc.
GIT describe is also a candidate for integration. But so are other versioning schemes and I initially stuck to semver. It gets rather complex, ie. PEP 404... But yeah, no placeholders. Or templates yet. Its a good idea though. On Tue, Apr 4, 2017 at 11:06 AM, Magnus Therning <mag...@therning.org> wrote: > > Berend van Berkum <berend.van.ber...@gmail.com> writes: > > > Hi all, > > > > > > this is more an announcement than a question. Although maybe I can spark > > some response. I've just made some commits to a sh tool I've used for two > > years to replace version strings in source code, and was going over some > > todo's. I wonder if there is any tool out there that "does it better". > > > > There are issues with keyword expansion. The principle one is that the > > exact GIT commit ID is not known for the file before making a commit. So > > there goes the popular SVN use-case. > > > > But there is still other use-cases for keeping a version in-line. Iow. > iso. > > expanding it on distribution. And even for post-checkout expansion a > little > > tooling would be nice. I personally also like to give files that end up > > distributed somewhere on a host system an Id line containing the project, > > version and path ID. Sometimes I copy these between repo's that have > > similar files. As a reminder to compare or synchronize changes. > > > > Its not a perfect GIT world, I know. Also it is not a very shiny project. > > But it works and I use it in every single project. The main motivation > was > > semver.org. After reading that I wanted a consistent versioning applied > to > > my code. So it always communicates an exact version. Well, that sort of > > works, but it has a few issues I've describe elsewhere. So until know I > > have two use-case to rely on this tool: > > > > - update comments containing file 'versions' > > - update code literals containing versions > > > > I'm always looking for better workflows. E.g. I intend to look at > git-flow > > again. But I don't know of any tooling to handle the above scenarios, so > I > > guess they all end up as some ad-hoc script in a git hook, somewhere, in > a > > project. In that case, you can find some (mostly?) Bourne-Shell > compatible > > scripts here: > > > > https://github.com/dotmpe/git-versioning > > AFAICS you are committing the source with expanded tags, is that > correct? > > I've looked around for something similar to CVS/SVN tag expansion, but > found nothing. If I ever get around to doing it myself I would > > 1. make use of smudge and clean filters > 2. do the expansion based on output from `git describe` (or something > similar) > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: mag...@therning.org jabber: mag...@therning.org > twitter: magthe http://therning.org/magnus > > Hofstadter's Law: It always takes longer than you expect, even when you > take into account Hofstadter's Law. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Git for human beings" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/git-users/z-5dlgSHKDE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
