Using git filters to ignore a specific line in json file - json

I have following json file:
{
"UseSqlite": false,
"UsersAvatarsFolder": "uploads",
"UserDefaultPhoto": "no_image.jpg"
}
Now I want to tell git to ignore the "UseSqlite": false, line So I followed this solution to ignore this specific line using .gitattributesfile:
*.json filter=ignoreSqlite
Then defined this filter in the gitconfig:
git config --global filter.ignoreSqlite.clean 'sed "s/"UseSqlite": .*/"UseSqlite": true/"'
git config --global filter.ignoreSqlite.smudge cat
But it seems that, it doesn't work:
'sed: -c: line 0: unexpected EOF while looking for matching `''
'sed: -c: line 1: syntax error: unexpected end of file
error: external filter 'sed failed 1
error: external filter 'sed failed
On branch master
I am not sure about sed syntax. Could you please take a look at it and let me know what's the correct syntax for it?
Update:
I finally fixed the syntax:
git config --global filter.ignoreSqlite.smudge "sed 's/"UseSqlite": .*/"UseSqlite": true,/'"
git config --global filter.ignoreSqlite.clean "sed 's/"UseSqlite": .*/"UseSqlite": false,/'"
But it also doesn't work, I want when I push the modification, the "UseSqlite" be true and when I pull the "UseSqlite" be false. But these filters don't work like that, Any idea?

I'm gonna guess what you've got is a config file where you want to make sure local modifications in the checkout don't get accidentally checked in. In this case, I'm going to bet you're using SQLite for testing. There are easier ways to do that which also make the system more flexible.
Simplest thing to do is have two config files: one for production and one for testing. The system defaults to the production one, but your test harness chooses the testing one.
But that introduces duplication, so what you really want is to merge together several config files. You have a config file full of defaults that generally isn't touched, then you have a local config file. The system merges the two together. For example...
config/default.json
{
"UseSqlite": false,
"UsersAvatarsFolder": "uploads",
"UserDefaultPhoto": "no_image.jpg"
}
config/local.json
{
"UseSqlite": true
}
The system loads both and the resulting config is:
{
"UseSqlite": true,
"UsersAvatarsFolder": "uploads",
"UserDefaultPhoto": "no_image.jpg"
}
Then config/local.json can be ignored by git.
This is both useful for testing and for your users. Now when they update they won't lose their changes to the configuration. config/default.json gets updated and they'll get any new or changed defaults, while keeping their own customizations in config/local.json.

Related

Keep comments in webpack?

So consider the following script command to run via npm run: webpack -p --optimize-minimize
Is there any way to say: Keep comments?
webpack version 2 is used.
In most applications you would not want to keep comments, but in this particular case I want to keep them, while still minifying the "script" Is this possible?
Webpack's webpack.optimize.UglifyJsPlugin has a couple of options which might fit your needs.
comments options accepts a regex or function to tell UglifyJs which comment to preserve.
extractComments let you even extract the comments to separate txt files.
Set it up like this:
plugins: [
new webpack.optimize.UglifyJsPlugin({
comments: true, // or function/regex
// Further UglifyJs config
})
],

Bitbake append file to reconfigure kernel

I'm trying to reconfigure some .config variables to generate a modified kernel with wifi support enabled. The native layer/recipe for the kernel is located in this directory:
meta-layer/recipes-kernel/linux/linux-yocto_3.19.bb
First I reconfigure the native kernel to add wifi support (for example, adding CONFIG_WLAN=y):
$ bitbake linux-yocto -c menuconfig
After that, I generate a "fragment.cfg" file:
$ bitbake linux-yocto -c diffconfig
I have created this directory into my custom-layer:
custom-layer/recipes-kernel/linux/linux-yocto/
I have copied the "fragment.cfg file into this directory:
$ cp fragment.cfg custom-layer/recipes-kernel/linux/linux-yocto/
I have created an append file to customize the native kernel recipe:
custom-layer/recipes-kernel/linux/linux-yocto_3.19.bbappend
This is the content of this append file:
FILESEXTRAPATHS_prepend:="${THISDIR}/${PN}:"
SRC_URI += "file://fragment.cfg"
After that I execute the kernel compilation:
$ bitbake linux-yocto -c compile -f
After this command, "fragment.cfg" file can be found into this working directory:
tmp/work/platform/linux-yocto/3.19-r0
However none of the expected variables is active on the .config file (for example, CONFIG_WLAN is not set).
How can I debug this issue? What is supposed I'm doing wrong?
When adding this configuration you want to use append in your statement such as:
SRC_URI_append = "file://fragment.cfg"
After analyzing different links and solutions proposed on different resources, I finally found the link https://community.freescale.com/thread/376369 pointing to a nasty but working patch, consisting in adding this function at the end of append file:
do_configure_append() {
cat ${WORKDIR}/*.cfg >> ${B}/.config
}
It works, but I expected Yocto managing all this stuff. It would be nice to know what is wrong with the proposed solution. Thank you in advance!
If your recipe is based on kernel.bbclass then fragments will not work. You need to inherit kernel-yocto.bbclass
You can also use merge_config.sh scripts which is present in kernel sources. I did something like this:
do_configure_append () {
${S}/scripts/kconfig/merge_config.sh -m -O ${WORKDIR}/build ${WORKDIR}/build/.config ${WORKDIR}/*.cfg
}
Well, unfortunately, not a real answer... As I haven't been digging deep enough.
This was working alright for me on a Daisy-based build, however, when updating the build system to Jethro or Krogoth, I get the same issue as you.
Issue:
When adding a fragment like
custom-layer/recipes-kernel/linux/linux-yocto/cdc-ether.cfg
The configure step of the linux-yocto build won't find it. However, if you move it to:
custom-layer/recipes-kernel/linux/linux-yocto/${MACHINE}/cdc-ether.cfg
it'll work as expected. And it's a sligthly less hackish way of getting it to work.
If anyone comes by, this is working on jethro and sumo:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = " \
file://fragment.cfg \
"
FILESEXTRAPATHS documentation says:
Extends the search path the OpenEmbedded build system uses when looking for files and patches as it processes recipes and append files. The directories BitBake uses when it processes recipes are defined by the FILESPATH variable, and can be extended using FILESEXTRAPATHS.

Mercurial - Add tag to committed files on commit

We are looking for a way to add / update a custom tag at the beginning of each file being committed during a commit. Its some kind of local timestamp we need.
I was thinking of hooks.
Unfortunately I cannot find a useful hook for that:
precommit: unsuitable as it fires before hg knows any metadata of the commit
pretxncommit: unsuitable, as the documentation clearly states that we should not change the working dir at this point
commit: unsuitable, as it fires when the commit has already happened.
EDIT:
I can not use hg's inline changeset-hash and / or datetime. For the following reason:
Our files get later imported into an external system (we do not have control over) which does not support any kind of versioning.
To simplify stuff: let's say tag is an ever-incrementing no. (everytime we commit). This tag is then used to help getting an idea of the version / status of the file on the system in respect to the file in the repo - like "no. of changes we're missing" and such.
Any ideas?
I would suggest a two-stage solution. First, create an alias along the following lines:
[alias]
tcommit = !tag-changed-files && $HG commit "$#"
Here, tag-changed-files would retrieve a list of modified and added/moved files via $HG status -ma -n or $HG status -ma -n -0 and tag them. I am assuming that re-tagging files that have been modified but aren't being committed yet is a harmless operation; more on that below. Note that you can even redefine commit if you absolutely want to via:
[alias]
commit = !tag-changed-files && $HG --config alias.commit=commit commit "$#"
However, this is potentially problematic, because it may confuse scripts.
You could also integrate the commit step in the program if you wanted to, and even try and parse the command line arguments to only tag those files that you are committing. For this approach, using hglib might be appropriate to avoid the overhead of invoking Mercurial multiple times. (Note that hglib and other tools that use the command server ignore aliases and command defaults, so this works even if you alias commit).
Second, you'd install a pretxncommit hook that verifies that files that are being committed have indeed been tagged appropriately (to ensure that the tag-changed-files program hasn't been bypassed by accident).
This should work without a problem on full commits; for partial commits, any files that were changed but have not been committed would also have been retagged, but since they will be either committed later (and get tagged properly at that point) or reverted, that should be harmless.
an idea of the version / status of the file on the system in respect to the file in the repo
Just one idea
Stop reinvent the wheel
Incremental counter is just shit, if you task is "to know, which version is on LIVE and which - in Mercurial's tip" (and this is your real business-task, yes?!)
Keyword Extension give you last changes per file.
If you want to inject changeset of repository into files (it's reasonable good way), re-read this part of wiki-page
If you just want to version your entire repo, do not use this
extension but let your build system take care of it. Something along
the lines of
hg -q id > version
before distribution might be well enough if file-wise keyword
expansion in the source is not absolutely required
You can insert hg id output into files at export stage (in planetmaker's sed-style), bu you can also have this additional metadata in files permanently in VCS with special encode|decode filters
There is - to my knowledge - no intrinsic system in mercurial which supports what you describe. However I can recommend an approach which somewhat is adopted from building a software release package from the repository: Make a small export script which replaces a certain KEYWORD in your files with the version information you need. A Makefile target could look like which creates a zip export for revision XXX with version information in all files which support it (thus contain the verbatim KEYWORD - use something truely unique here):
VERSION=$(hg log -rXXX --template="Version: {node|short} from {date|isodate}")
export:
hg archive -rXXX -t files export
for i in $(hg ma -rXXX); do sed -i "s/KEYWORD/$VERSION/g" $i; done
zip -9rq export.zip export
I use a similar approach in my Makefiles where I create versioned export for the source of a particular revision of my software.
EDIT: if your purpose (as stated by the comment) is only to implant the number of commits made to that file: then you can use indeed a pre-commit hook and modify the file. You can count the number of modifications made to a file with hg log FILENAME --template="{node}\n" | wc -l. Do that for every file and do the sed replacement in the header of each file in the pre-commit hook.

Make: Redo some targets if configuration changes

I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.

Disable verbose output on build

When I use ST build system, "built-in output pane" prints various things like expected build output, but also cmd executed, active dir and path variable. Now cmd and dir are just fine, but printing path variable is totally unnecessary for me and it distracts actual output content, as it's just very long string of paths, shadowing all other output.
How can I instruct ST not to print path variable on build?
By adding "quiet": true to the Build System configuration file (JSON), you can prevent all "debug text" from appearing on build failure. This will include:
shell_cmd
cmd
dir
path
To exclude only path, you would need to modify the Packages/Default/exec.py file. Under the ExecCommand class, run method, look for self.debug_text += "[path: " and comment the line out.
To get to this file in ST3, you can use Package​Resource​Viewer, and type PRV: in the Command Palette to find Package​Resource​Viewer: Open Resource.
However, note that doing this, will create a file that will override the one that ships with ST3. So it is recommended to delete your override (Preferences -> Browse Packages from the menu, Default folder, exec.py) when a new build of ST comes out, as the official version may change to fix bugs etc. You can then re-apply your changes following the same steps as above, if it is still necessary. (Maybe an option will be added to exclude the path from the output, sometime in the future.)