This is to avoid having some <<< or some >>> in that file if there are conflicts.
If there is a conflict, I just want a message telling me there is a conflict and bazaar should not mess with the file.
With subversion, you can modify the svn:mime-type property. But I don't know if Bazaar have this feature.
The reference says that there is no explicit way of telling so far:
Bazaar currently relies of [sic] content analysis to detect binary files for commands like diff. In the future, a binary = true rule may be added but it is not supported yet.
It is annoying, but you still have the .BASE, .OTHER and .THIS files which are unchanged, you just replace the altered file with the one you need.
Can be scripted, I suppose.
Related
I have a golang project, but am using a bit of c++. I downloaded a header file dependency, nlohmann/json, and is 22875 lines long, so naturally my github languages is not showing the proper language (Go) and is instead showing c++. How can I remove the json.hpp from the github linguist? I know that the .gitattributes file exists and I can change the language of some files, but how can I remove a file entirely from the linguist?
You can't tell Linguist to skip a file entirely. But I don't think that's actually what you want, as you don't care if it remains highlighted, right? You can tell Linguist to ignore some files when computing language statistics. In your case, the best way to do that would be to declare these C++ files vendored, with e.g.:
*.hpp linguist-vendored
See Linguist's README for more information.
As an example, when using the "extract variable" feature, the variable is declared "var" rather than "final", although the latter is what I usually end up assigning.
The "analysis_options.yaml" file seems to know a linter flag "prefer_final_locals" (and prefer_final_fields).
Is there a way to make the IDE make use of these?
The analysis_options.yaml located in the flutter installation directory is NOT used by IDEA as default. In order for these configurations to be applied, the file has to be copied to the root of a dart/flutter project (so, next to the pubspec.yaml). The mentioned flags regarding finals and much more then get applied without any further action required.
I'm using add_custom_command() to generate some files. ninja clean removes them, as it should. One of the files is intended as a default/example implementation, to be modified by the user. It is only generated if it does not already exist. I would like for ninja clean not to remove this file.
I have tried a number of things but without success:
add_custom_target(): CMake complains about the missing file unless I name it in BYPRODUCTS, but doing this also leads to removal on clean
set_file_properties(... GENERATED FALSE) doesn't work because CMake complains about the file missing.
set_directory_properties() failed in a similar way: "folder doesn't exist or not yet processed" (it does exist)
I previously generated the example implementation and just let the user copy it or model their code on it. This works, but isn't entirely satisfactory. Is my use-case so unlikely that CMake doesn't support it?
I am afraid you requirment (conceptually, have make create something which make clean does not remove) is rather unusual. I can think of two potential solutions/workarounds.
One, move the file's generation to CMake time. That is, create it using execute_process() instead of add_custom_command(). This may or may not be possible, based on whether the file-generation process (the current custom command) depends on the rest of the build or not.
Two, totally hide the example file's existence from CMake. That is, have the custom command also generate some other file (maybe just a timestamp file) and have its driving custom target depend on that one instead. Do not list the example file as ither the custom command's dependency, output, or byproduct. That way, nothing will depend on it and neither CMake nor Ninja should not care whether it exists or not, so they will not complain or try to clean it up.
If it is an example for the user, it should not be in your build folder, but in the install folder. I don't see why you would need add_custom_command or the other commands you listed.
Therefore, you have to provide install() instructions.
You can then call make install. Cleaning will not remove those and only installing again will overwrite them if necessary.
For those, who come here a long time after the original question was asked (like me), I'll write my solution:
The tool called in add_custom_command generates two files with identical content:
one that is saved in sources, never mentioned anywhere
and one that's marked as byproduct, and then is depended on
So the first one is the file we wanted in the first place.
And the second one is actually used in build process, and gets deleted on clean.
For me the issue is that I actually want to save generated files in VCS so I can track changes. And this approach gives ne what I need.
I am working with multiple processes that write to the same directory.
I have a directory dir1/
My process creates a file a.txt under dir1/. However the other process creates a-temp1.txt and renames it to a.txt. I don't have control over the other process since that code comes from a library. Can I prevent a-temp.txt from being renamed?
There's nothing you can do that the other process can't undo. Your best hope (other than changing your program to work sanely) is that the other process doesn't try too hard to do the rename. That is, it tries the simple approach and gives up if that fails.
In particular, you can set the UF_IMMUTABLE flag on either file and that will prevent one from being renamed to replace the other. You can set the flag using chflags(). Using Cocoa, you could also use [someURL setResourceValue:#YES forKey:NSURLIsUserImmutableKey error:NULL].
Keep in mind that you won't be able to change the file in any other way, either, until that flag is removed. If the other process is determined to rename the file, it has permission to remove the flag just like your process does.
Also keep in mind that a system such as this is inherently race-prone.
You really ought to use separate names for the files, or separate directories, or ditch that library that doesn't give you the control you need.
Set the user immutable flag chflags(...,uchg). This will keep the other process from changing your file unless it takes action to clear the bit. Of course I don't know how the other process will react to you putting things in it's way, but that wasn't the question.
You can use chflags() on an HFS+ (Mac OS X) file system to set the UF_APPEND attribute. (Do a man 2 chflags.) That will permit appending to the file, but not deleting or renaming, even by the same user.
You can, but it unlikely will solve your problem. I strongly suspect this is an X-Y problem, and almost certainly the correct solution is to redesign some part of this system entirely, probably by changing your file names, using unique temporary files, moving to another directory, or reworking the usage of the library (libraries only do what callers tell them to do; and libraries are just code anyway). You shouldn't try to defeat another process; you're all working for the same user.
All that said, sure, you can prevent your own userid from renaming over file. Just deny yourself permission. You can modify the file:
chmod 400 a.txt
That says that you can read the file but may not write it. However, if you already have an open file handle, you may continue to use it (so you can keep writing to the file, even though another process running as the same user may not).
Similarly, you may change permissions on the directory:
chmod 500 .
This would prevent the rename because file names are kept in the directory.
I've always wondered why vim lacks some indentation files that would be handy for everyday life. Example: I sometimes have to deal with really messed up apache config files (/etc/apache2/sites-available/*). It's impossible to have them indented correctly by vim. With apache config files I usually try to improve indentation by typing
:set ft=xml
gg=G
:set ft=apache
I know that apache configuration files are not XML and that XML indentation doesn't work remarkably good here, but at least it's better than having every config line in the first column. There's a vim script which seems to work correctly but I have to install it on all Linux systems. If we take this plugin as an example: It's from 2007 - why did it never make it into a vim release?
The maintainer of the [indent] script has to submit the file to Bram (Vim's BDFL) for inclusion (and commit to maintaining it); that's how the process works. So, if you want to have this in the runtime, please ask the maintainer, or, (as the last update of that script on vim.org is from 2007 and he may be gone), ask on the vim_dev mailing list for someone to volunteer as such.
But... you shouldn't have to rely on those files being in the official runtime. Unless you're an atypical user without any customization, you must already have a mechanism in place to distribute your personal ~/.vimrc and plugins; if you put the script into ~/.vim/indent/, you should be all set.