is there a way to automatically update version number of a package.json (https://npmjs.org/doc/json.html) with the HEAD hash of git? I would like to have something like version: 1.0.0+rev82e4b91cfe42cd86e9453b4987b9cc446566de6 inside the project's package.json file. Eveything before the plus is set manually and the hash is updated everytime I commit something.
Is this possible? I couldn't find anything on this topic :-/
It appears that this can be done directly without a plugin. npm version $(git describe) will take the value from git describe and update the value of the version in package.json.
(I'm currently using npm version 3.10.)
Part of that can be solved with git-describe and there's actually a grunt plug-in that wraps that for you (https://github.com/mikaelkaron/grunt-git-describe/).
The second part you'd have to do manually (right now), but I actually have a similar problem at the moment, so I can try to hack up a grunt plug-in for you (and myself).
Full disclosure, I'm the author of grunt-git-describe above.
git rev-parse HEAD will write out the last commit to the current head branch which you could then append to a version number in your package whenever you run your build.
There are a number of git rev-xxx commands that might be useful for any additional stuff you might want to record.
Automatically at what point? Possibilities are:
Update the version field every time you run a build from a machine environment
Update the version field every time you run any build.
Update the version field in a git hook to keep in sync. Personally, I'd be nervous about a hook that performs a change when something changes. This strategy is highest risk, highest reward.
If you go with the first or second approach, it depends of course on what build tool you use. If you use grunt, see about a grunt plugin. I can't find any grunt plugins that do what you're asking for, but you can create one fairly easily.
http://gruntjs.com/plugins
If you do end up creating one, let me know as I am also in need of a similar process :)
In my case, I am using SVN, but want the same pattern. I want to put the SVN revision number as my build number.
My recommendation is to leave the build number blank in the file that is checked in and have your build environment do a git clone for a new build and update the build number. Then built packages always have something about them indicating the git commit they came from.
I think that for development, you don't really need it because you can always ask git which version you have checked out. There is a grunt-git plugin which you could maybe use to figure out the version in dev. (maybe git show?)
Related
As part of my class, we have a project folder, and within it are individual files with a matching test file. When we download, that, we have to install npm, and as we finish each problem, we run mocha to test that our answers are correct.
Throughout, I would commit after each problem was solved, and then at the end, push it to a private github repo.
Now, I'm going back through the project, and I delete my answers so I can resolve them for practice, but running mocha doesn't work. Instead of seeing the 'passing' 'failing' in the terminal, I see the the console logs up to the problem I haven't done yet, which prints a reference error indicating I haven't declared the function (because I haven't reached that problem yet.
Other than deleting the code that I wrote, I've done nothing different, yet mocha won't work. Is there something else I need to do?
You're not giving us enough information to debug precisely what Mocha's complaining about, or enough information about your project so anybody could make any informed suggestions to help you.
No matter. SUGGESTION:
You're apparently using GitHub. Cool. Consider it your own little "time machine".
Save your current work. Either "git stash" (if you're comfortable with that), or simply back up your project folder to a temp directory).
Now revert back to a previous commit.
EXAMPLE:
git log # identify previous commits. Ideally, the last commit that "worked"
git checkout xxxxxxxxx # Check out out
Rinse and repeat until you find a commit that "works".
When you're done, you might wish to do something like this:
https://stackoverflow.com/a/21718540/421195
git revert --no-commit 0766c053..HEAD
git commit
This will revert everything from the HEAD back to the commit hash,
meaning it will recreate that commit state in the working tree as if
every commit after 0766c053 had been walked back. You can then commit
the current tree, and it will create a brand new commit essentially
equivalent to the commit you "reverted" to.
Git is your friend. It's useful as much more than simply a "source repository" to check in "completed code". You can also use it as a workaday tool for scenarios exactly like this.
I've successfully copied the most current version of a project from GitLab into my Jupyter notebook using the git clone command in the Linux terminal. Let's say the project contains a Python program called python_code.ipynb.
I've already made edits to an earlier version of python_code.ipynb and named it python_code_myversion.ipynb.
Newbie question: How do I overwrite python_code.ipyn with python_code_myversion.ipynb so I can then git push my changes back to Gitlab project? I'd prefer to do this rather than manually rewrite my code edits in python_code.ipyn.
Generally the point of source version control is that you edit the actual files you want to work on, rather than manually creating a copy of them.
In any case, to go back to this workflow to achieve what you are trying to do with your question: it will vary depending on which Operating System you are on. As the python_code.ipynb is already under version control, you can essentially delete it and rename the python_code_myversion.ipynb to replace it. On Linux, you could do this in one go with this command:
mv python_code_myversion.ipynb python_code.ipynb
I have been using git for some time now and I feel I have a good handle on it.
I did however, build my first small program as a distribution (something with ./configure make and make install) and I want to put it up on github but I am not sure how to exactly go about tracking it.
Should I, for instance, initialize git but only track the source code file, manpage, and readme (since the other files generated by autoconf and automake seem a bit superfluous)
Or should I make an entirely different directory and put the source files in there and then manually rebuild everything for version 0.2 when it is time?
Or do something else entirely?
I have tried searching but I cannot come up with any search terms that give me the kind of results I am looking for.
for instance initialize git but only track the source code file, manpage, and readme (since the other files generated by autoconf and automake seem a bit superfluous)
Yes: anything used to build needs to be tracked.
Anything being the result of the build does not need to be tracked.
should I make an entirely different directory
No: in version control, you could make a new tag to mark each version, and release branches from those tags to isolate patches which could be specific to the implementation details of a fixed release.
But you don't create folders (that was the subversion way)
should I make an entirely different directory for sources
Yes, you can (if you have a large set of files for sources)
But see also "Makefiles with source files in different directories"; you don't have just one Makefile.
The traditional way is to have a Makefile in each of the subdirectories (part1, part2, etc.) allowing you to build them independently.
Further, have a Makefile in the root directory of the project which builds everything.
And don't forget to put your object files in a separate folder (not tracked) as well.
See also this question as a concrete example.
Is there something similar to svnversion command in perforce ?
The project I'm working on has a release shell script. It would be nice if that script could check that the local copy of the repo has no modifications and no mixed versions. It would also be nice if the last commit number could be stored in the script output too. I used to do this using svnversion but now I must use perforce.
I thought I was used to CLI and would have no problem looking for what I wanted with p4 help but instead I was made humble again. ;-)
Maybe I've misunderstood what you need, but can't you just use the latest changelist number? First sync your workspace, then to get the latest changelist number, see this answer: Get the changelist number of current workspace directory
After few weeks of struggle i am able to create a medium native package debian package which works well in installation and removing of the package.
As http://www.quietsche-entchen.de/cgi-bin/wiki.cgi/-wiki/CreatingDebianPackages
Debian wiki
http://wiki.debian.org/HowToPackageForDebian http://www.debian.org/doc/manuals/maint-guide/ these are the quite good material for beginners,
I have basic problem, in updating the package all the files data.tar.gz are updated by default.
I want only few files to get updated in the data.tar.gz based on a key variable stored in all the files.
After the unpacking that is executing preinst script, all the files in data.tar.gz are already updated..
my idea was to take back up of the files intially before upgrading the package, and check key variable in files.. if the key variable is greater than the current variable replace it..
which means i am writing a simple backup script.. and executing in the postinst file..
i donot think this is good idea.. and more over limitations in dash script make it a very tough job..
What are you trying to accomplish here? During the reinstallation (or upgrading) of a Debian package, replacement of all of the non-conffiles with the latest version is exactly what's supposed to happen. If the file hasn't changed since the last installed version of the package then there's no harm in updating it anyway, and if is has changed, it's supposed to be updated.
If you have specific files which might be modified by the user and should be preserved across upgrades, make then conf files. The package system will prompt the user and ask them if they want to keep the package maintainer's version or the locally modified version.
(But if you're going to make every file a conf file, then you're probably doing something wrong.)
To make a file a conffile, list it in debian/conffiles. But if the file is going to be installed under /etc then you don't need to do this because dh_installdeb will do it for you.
EDIT following additional information in comment:
Suppose you have files test1.sh and test2.sh (among others) in your package. In the Debian world, they are either conffiles are intended to be modified by the end user, or they're not.
conffiles should be relatively few in number and as short as possible, to minimize the burden of having to reconcile changes made by the package maintainer with conflicting changes made by the end user.
If there are things mixed into the code that the end user is likely to want to tune, try to factor them out into a configuration file. If you put that file in /etc, you don't even have to manually designate it as a conffile.
If the end user needs to make a change to a non-conffile, they should use the dpkg-divert protocol to (1) move the original file aside, and (2) edit a copy. Diverted files are respected by package upgrades. The end user who uses dpkg-divert should be aware that things might break after upgrades as a result, because the package maintainer hasn't foreseen that these files would be modified by end users and the locally modified version might be incompatible with a newly upgraded version of a different file. dpkg-divert should be used carefully and sparingly.