Many thanks for your assistance here! Like you, I prefer to keep things
simple and not use branches for single-file scenarios like these scripts. I
usually use the extended comments section of the commit comment to include
a brief synopsis of the changes in the commit. I wonder if using your
filename-version number suggestion in the title section might work?
On Tuesday, March 3, 2015 at 11:52:04 AM UTC-5, Konstantin Khomoutov wrote:
> On Tue, 3 Mar 2015 07:17:31 -0800 (PST)
> > I am using MySQL on my local Windows laptop to compile data and
> > produce reports for my enterprise related to PIV issuance.
> > The challenge that I have is that although all of these scripts
> > loosely relate to the PIV project, but pretty much stand on their own
> > for each function. I would like to be able to use tags to monitor
> > version numbers for each of the scripts ( 1.0, 1.1, 1.2, 2.0, and so
> > on). In order to do this, do I need to create a separate repository
> > for each script? If so, that would seem to be a lot of extra work.
> > Can anyone suggest a workflow that will help me to monitor and track
> > version numbers for each script separately?
> I would keep things as simple as possible and just do this:
> 1) Turn your folder into a Git repo (`git init .`).
> 2) Add all your scripts into it and record the first commit;
> mention current version of each script in the extended part of the
> commit message.
> When a new version of a particular script appears, update the
> appropriate file in your folder to match it, `git add` that script file
> solely and record a new commit.
> You will then be able to see the history of changes of a particular
> script file by using
> git log -- scriptFileName.sql
> There is no tags in my simplistic picture, but I'd just record version
> of the script file recorded in a commit using its version number in the
> commit message -- you will see them in the `git log` output and will be
> able to use git-log's search facilities to search for a particular
> version (present in the commit message).
> You can still use tags with this approach -- just devise proper
> "namespacing" for your tag -- for instance, put the base name of a
> script file (without the extension) into tags related to that script
> file, and then tag each commit recording a new version of that file
> with such a tag -- say, if you've just recorded version 3.2 of
> mumboJumbo.sql, tag it using "mumboJumbo-v3.5".
> If you feel extravagant, you can even not use branches at all, just
> shovel new versions of your script files into the repo using the
> standard if lesser known
> git hash-object -w myScript.sql
> and then tag whatever SHA-1 hash it printed out using the naming scheme
> outlined above. You will then only have tagged blobs and no history at
> all (it will be implicitly encoded in the tag names).
> I'd still prefer a single branch and may be tags on its commits.
> > I have posted this same question on
> > StackOverflow:
> Thanks for mentioning -- this level of netiquette is rare these days ;-)
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
For more options, visit https://groups.google.com/d/optout.