I'm importing an SVN repository into Git, and I have a lot of files with svn:eol-style set. SubGit reads those properties and generates a .gitattributes line for every file.
Is there a way to tell it to use a single-liner for every type of file (i.e. *.java text or *.java text eol=lf since we have a style guide rule which mandates that)?
I tried to add the info/attributes to the repository just before the import, but there's no change in the generated .gitattributes.
Is there a way to do it?
At the moment there's no way to define default rules like *.java test eol=lf for initial translation, but if you later in a Git branch change .gitattributes to replace all per-file lines with one *.java test eol=lf rule, all subsequent Java files with svn:eol-style=LF won't result into new lines, but Java files with other svn:eol-style values will result into additional lines as exceptions to the *.java test eol=lf rule.
Moreover it is even recommended to have the *.java test eol=lf rule, because when you create a Java file in Git, .gitattributes rules are applied to it implicitly, so your newly created Java file will have "eol=lf" automatically and when you push it to Git, SubGit will translate it to svn:eol-style=LF. So this rule would act in the same way as SVN auto-properties.
SubGit doesn't consider info/attributes file at all, because it is not versioned and exists on local machine only while SubGit works on the server-side level. But you can use info/attributes on the local machine to override .gitattributes if you need that on one machine only.
I would also note that you should be careful when you change the .gitattributes file. When you push such a change to SVN, it will update svn:eol-style for all files for which the effective "eol" attribute value was changed.
One more note: be careful when you set the "eol" attribute for a file with mixed EOLs: change its EOLs to LF first at the Git blob level, or (what would be easier) set the svn:eol-style property on the SVN side instead, because when you set this property, Subversion automatically fixes file content, but Git doesn't do that.
You've mentioned two patterns, *.java text or *.java text eol=lf, but they are actually different. The first one is a particular case of a default * text=auto !eol rule, unless the Java file contains binary characters (as it doesn't contain the "eol" attribute, the main *-rule will set it to !eol, what corresponds to svn:eol-style=native); so it would be ignored when added. The second one will set svn:eol-style=LF for every Java file added to Git.
Finally, in the future versions, we (the SubGit team) plan to add a possibility to specify default *.java test eol=lf rules for initial translation or deduce it basing on per-extension statistics, but for now you should add this line manually to every Git branch you work with.
Related
I need to find a way to modify/edit a given file after Buildroot compilation and right before the creation of the rootfs depending on a menuconfig flag selection. I could find in the Buildroot documentation that it is possible to do that by using post-build scripts.
My problem is that I would do the script action only if I selected something in menuconfig, for example:
(x) Enable my_login_system;
If I select my_login_system, then I need to change the nsswitch.conf file according:
passwd: my_login files
If I don't select in menuconfig the "my_login_system", then the nsswitch.conf should be:
passwd: files my_login
So, my main question is how to know if the "my_login_system" was selected or not in the post-build script.
When a post-build scripts is executed, it can access the BR2_CONFIG environment variable, which holds the path to the Buildroot .config file. Your script can parse that file and act accordingly.
Thus you could have a condition like:
if grep -q ^BR2_MY_LOGIN_SYSTEM=y ${BR2_CONFIG}
then
# do some tweaks
else
# do other tweaks
fi
Alternatively, you could use the BR2_ROOTFS_POST_SCRIPT_ARGS configuration variable to pass arbitrary command line parameters (as opposed to environment variables) to the post-build scripts.
Both possibilities are documented in the Buildroot manual, at section Customizing the generated target filesystem.
I want to set up my HelloWorld intellij-erlang project with all files in the same directory so I can easily switch between IDEA and emacs/vim.
<my-project>/hello.erl
<my-project>/hello.beam
Now, if I configure the output directory to be the same as the source, hello.erl gets emptied as part of the build and the compilation fails.
I assumed it's something to do with copying resources to the output directory, so I've configured intellij-erlang to exclude *.erl from the resources with a !?*.erl pattern, but this does not have any effect, hello.erl still gets emptied before the compilation takes place.
As an experiment, I've also tried using separate src and out directories, and intellij-erlang always copies the *.erl to out irrespective of the resource patterns.
Based on all this, I would conclude that intellij-erlang cannot work with all files in the same directory. Have I missed anything?
Erlang programs should be build on standard OTP directory structure. Build tools like rebar (used by intellij) or erlang.mk build on this conventions. And so should all IDE's.
Intellij does it, just like you notice. And so does Emacs's plugin (that I use and can confirm). I would guess so does Vim's one.
So if you would like to be able to switch easily between your IDE's you should try to keep to this convetion of keeping you source files in src and compiled files in bin (and headers in include).
I want to remove untracked files from the working tree. Like here
https://www.kernel.org/pub/software/scm/git/docs/git-clean.html
libgit2 doesn't implement this itself. It's a porcelain command, which deals with interaction with the user. It also deals primarily with files which are of no interest to the Git repository.
You can run status to see which files are untracked and then remove whichever ones the version of git-clean would have removed through the usual means available in your programming language.
I started using sass scss stylesheets. These generate *.css files from *.scss files. My question is, which files do you check into version control? Right now I check in both main.scss and the generated main.css. I wonder though if there is a way to just check in the *.scss file and to ensure that the *.css files get generated on deployment.
I prefer to check them in. We deploy to our staging and production environments from git and I prefer not to rely on yet another tool/compilation when deploying to production. This way, its absolutely clear what is being pushed out.
In general, you usually don't need to check generated files into source control. As long as your code generation works consistently, and you use it consistently to update your target .css files, I don't think you would need to put them in source control.
That said, the suggestion to not put generated files into source control is usually intended more for binary files (i.e. libs or executables generated from a build). The main reason for this is that binary files cannot be easily diffed/merged, so if multiple people try to checkin changes to the same binary, you may end up with merging issues that cannot be easily resolved. Since you're dealing with plain text css files, I don't think it's that big of a deal to just put them in source control too, just so you have a backup of the actual target file.
I like to borrow from the conventions used by server side developers when handling compiled front-end code like sass. I keep all of my source separate from compiled code. Here's how I set it up:
Put your source in a src directory, under main/language-name, in this case:
/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss
Then put tests in an identical test directory (you shouldn't need any tests for sass, though:
/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever
Then put your compiled code in a publish-ready directory, like so:
/path-to-my-app/publish/css/my-syntactically-awesome-file.css
Then commit the whole shebang (!)
You can make sure you are always putting your css in the right place like so:
$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/
Now you're a mother effing programmer, baby!
I have a project where I create a JAR which contains a bunch of classes with main() plus a set of scripts which set the environment to invoke them. Most of those are long running processes which log a lot (~10-20GB).
This means I have a pretty complex log4j.xml file which, being in src/main/resources/, goes into the JAR. When something breaks in the production system, I'd like to modify the logging on the fly for a single run.
So I came up with the idea to have a conf/ directory on the production and put that into the classpath, first. Then, I thought that it would be great if M2 would put the config files in there (instead of the JAR). But that would overwrite any manual changes during an automated deployment which I strongly dislike. I'm also not fond of timestamps and things like that.
So my next ideas was this: M2 should leave the config files in the JAR but create copies of the files with the name *.tpl in the conf/ directory. The admin could then copy a template to the basename to override the files in the JARs. .tpl-Files would be overwritten but that wouldn't hurt. Admins would have full control over which version of the log was active and they could run a diff to see whether any important changes were made.
Now the question: Has someone seen a plugin which automates this process? That is which creates a conf/ directory with all or a selected subset of everything in src/main/resources/ and which renames the files?
Best practice in Maven handling config files is to place them in a separate conf directory, and pack them in a binary assembly using the assembly plugin. Placing configuration files, like log4j.xml in the src/main/resources doesn't make sense, since it is not a true application resource, but more of a configuration file.
We cope with the overwriting, by packing the configuration files with the posfix .def. For example: myapp.properties is packed into the assembly as myapp.properties.def. When the person who uses the assembly unpacks it, it will not overwrite his original files. After unpacking he simply merges them by an external tool (we use meld in Fedora Core).
I may be missing something and this doesn't answer directly the question but did you consider producing a zip assembly of the exploded content of required artifacts (to be unzipped on the target environment)?
Sounds like you're attacking the problem the wrong way. Why not just run the application with -Dlog4j.configuration=/some/where/my-log4j.properties? If you want, you can add a command line flag to main() which invokes the PropertyConfigurator directly.