In git when i commit bash files i want those files to be executable like this command do
git update-index --chmod=+x <file>
But i want it to be set globally by default.
Is there anyway of doing that by default ?
No, there isn't any way of doing that. On Unix systems, Git honors the executable bit of the files that are in the repository. So on such a system, by the fact that you've set them executable in the working tree, they'll automatically be tracked as executable in Git.
If you're on Windows, there is no executable bit, so you have to update them by hand. You can try using Windows Subsystem for Linux, which has an executable bit, so you can check out the repository there and work with it.
This feature doesn't exist as a default because (a) it would be hard to implement since it would require intuiting which files are shell scripts (which is nontrivial) and (b) there are many shell scripts which wouldn't be safe to run by themselves. If you know that this is appropriate for your project, you can write a shell script to set all of your shell scripts executable by default.
Related
I recently updated Git to version 2.7.2.windows.1 (I am running Windows 7 64-bit). Since the update, I have been unable to run git add with the -p option on files within a certain directory (or its subdirectories) whose name is _ (an underscore).
git status correctly reports that my file has changes:
PS C:\Users\Carl\www\dl> git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: _/php/class.Menu.php
And I can add the entire file with a simple git add, or by specifying the file by name. But if I try to include the -p or --patch option (both variations produce the same results), Git reports that there are no changes:
PS C:\Users\Carl\www\dl> git add -p .\_\php\class.Menu.php
No changes.
This only happens for files within the _ directory, but it doesn't matter whether I cd into that directory to run the git add command without having to explicitly specify a path with an underscore in it; it still doesn't work:
PS C:\Users\Carl\www\dl\_\php> git add -p .\class.Menu.php
No changes.
I had initially thought this problem was related to a similar one I encountered recently on files within the _ directory, which I asked about here. However, that problem appears to have been related to Posix path conversion in MinGW, whereas this problem occurs whether I use Git Bash, Windows PowerShell, or cmd.exe.
As I said in that previous question, I believe underscores to be valid in file/directory names. Additionally, I am not the owner of the project so I cannot rename the directory or move the file.
Is this a bug in Git? Are there any additional steps I can take to determine what the underlying issue is?
Well, I was able to reproduce this, and seems that it is the same POSIX-to-Windows path conversion. ProcessMonitor shows that git (actually, perl run by git) looks for a file C:\Program Files\Git\php\class.Menu.php.
To work this around (at least, that worked for me), according to documentation, you can set the environment variable MSYS_NO_PATHCONV temporarily, like so (in git bash):
MSYS_NO_PATHCONV=1 git add -p _/php/class.Menu.php
(I don't know how to set env variables in windows' cmd/powershell, but that should be possible, too.)
You shouldn't enable MSYS_NO_PATHCONV globally/permanently (e.g. using export in git bash or modifying windows' user/system environment variables in system settings), because that can lead to unwanted effects, and it'll probably break much more things than it'll fix (see this SO comment). Actually, git-windows folks warn against even temporary enabling MSYS_NO_PATHCONV.
Having said that, I'm starting to think that OP's problem is a git-for-windows bug and should be reported as such (might have something to do with the fact that git-add is a binary, but git-add--interactive is a perl script).
Another listed workaround is to double the first slash, like git add -p _//php/class.Menu.php (or does that mean the parameter must start with a double slash?), but that doesn't seem to work due to complex intermediate path conversions, that happen between the invocation of git add and the real file access.
I'd try without that .. Also I've never passed a filename to git add -p. I just make my change and run that as is. I would also check to make sure any changes you're making are in fact being applied to that specific file, and the file is being touched.
I am writing a posix compliment shell script that will, amongst other things, clone a git repository and then execute a script (that was cloned along with the repository) inside the repository.
For example:
git clone git#github.com:torvalds/linux.git
cd linux
./Kconfig
The idea would be that people would use it for good, not evil, but you know.... So really I would like stop people from doing putting a line like:
rm -rf /
Inside the script.
Or perhaps something slightly less evil like:
rm -rf ../../
Is it possible for me to somehow change the permissions of the script (after the clone) so that it is only able to modify things inside the cloned repository?
Basically the answer for your question is the chroot command, which allows you to lock in processes in a directory as if it was the root directory. chroot requires root privileges to setup, but there are alternative implementations such has schroot, fakechroot, or proot that don't. Because all file system access (also read) is restricted, you will need to hand in anything that the scripts need to function into the chrooted environment. How to do that conveniently depends on your distribution.
That doesn't necessarily mean it is perfectly secure, because it provides only file system isolation.
In order for me to run a .exe or a .sh in Cyqwin, I have to put a ./ at the beginning of my line. Is there a way for me to change this so that isn't necessary? This is causing problems when I try and run a test script and it can't find files that are right in the directory I'm working in.
The reason you must use a './' is to specifically tell the shell what file you are trying to execute. Without the leading './', your $PATH environment variable is searched. You can try adding the directories with scripts and executables you commonly use to your $PATH if you'd like. Alternatively, you can add the current directory (.) to your $PATH, but this is a Very Bad Idea as it can lead to unintentional executions.
From the cygwin environment variables doc:
The PATH environment variable is used by Cygwin applications as a list
of directories to search for executable files to run. This environment
variable is converted from Windows format (e.g.
C:\Windows\system32;C:\Windows) to UNIX format (e.g.,
/cygdrive/c/Windows/system32:/cygdrive/c/Windows) when a Cygwin
process first starts. Set it so that it contains at least the
x:\cygwin\bin directory where "x:\cygwin is the "root" of your cygwin
installation if you wish to use cygwin tools outside of bash.
Operating system: Windows XP SP3 (Unfortunately)
I have downloaded and installed the latest version of Cygwin and Git. I also have configured my environment to include the "bin" folders for each in my system path and also set a user variable TERM=msys. I can now go into cmd and use the following command, for example:
git status
and get colored output, i.e. for status, changes to be committed are green, while untracked files and such are red. This was not the case without having set TERM=msys.
However, since I also added the Cygwin bin to my path, I can use
ls
to get a directory listing, but not with colored output. Am I correct in assuming that, since I'm only using the binaries through cmd, and not Cygwin itself, that getting colored output would have to be done differently from just configuring a BASH profile? Assuming this is possible; however it would seem to follow that if it can be done with Git, then it can also be done with the Cygwin binaries.
I'd be happy to elaborate or clarify any details. Thanks.
The basic colors should still work when you do ls --color. Since you can't use alias in cmd.exe, you can use the doskey windows utility.
doskey ls=ls --color
There are various ways you can make it so the command gets run automatically every time you start a cmd.exe shell. Here's one: http://www.tildemark.com/loading-doskey-automatically-with-cmd/
Heading says it all really. Using Windows 7 and latest stable gvim, whenever I save (:w) a file it's marked executable. I'm doing cross-platform development and it'd be nice if this didn't happen.
#sceptics: The flag of the files are indeed set as executable. Do a ls -al before and after re-saving the file to observe the issue. (install cygwin, or may be other *nix emulations)
#OP: the question have been raised several times in the past. I don't remember the conclusion on the subject. You should search vim mailing-lists archives (vim_use and vim_dev).
May be you can try to add an hook to your RCS (if it supports that) to proceed to a chmod -x on file extensions that does not correspond to an executable (*.h, *.cpp, *.vim, ...), or on files that do not contain a shebang (unlike perl, I don't know if python source files may contain a shebang)