I installed git 2.28.0 on windows.
In fact, i can't find post-checkout.sample hook in the hooks repository under /.git repository.
Is post-checkout.sample hook supported on windows ?
When i installed the same version of git on linux i found the post-checkout.sample hook.
I even tried with the git 2.23.0 version and i had the same problem.
I tried to create post-checkout that print a simple message "hello". But it doesn't work. However when I copied this file in pre-commit it works.
Any suggestions?
It seems that it doesn't work on an empty repository.
I just committed a file in my repository and when i excute git checkout -b new_branch, the post-checkout hook worked.
I never saw a post-checkout.sample in mingw64/share/git-core/templates/hooks/ of a Git For Windows distribution.
But that hook should work, provided you make it:
a file named "post-checkout"
a bash script (see an example here)
in your repo/.git/hooks folder
There was actually a proposal (RFC) for a post-checkout.sample in 2009, but it was not picked up at the time.
The question was asked (also in 2009):
I also noticed that the
post-checkout sample does not exist when I init a new archive. Is this a
bug?
No, it's security.
Hooks are executable files and shouldn't blindly be
copied around for security reasons.
Related
I have had git LFS enabled on my repository for a while and it has always worked perfectly. Recently, I have been having issues where my local files are being replaced with links.
As an example, I have a png file that will no longer open because the file format is not supported. Upon opening the file in notepad, I am presented with this.
version https://git-lfs.github.com/spec/v1
oid sha256:733c51c9ee6f0f395f5f042869307154d6ebf6d5d5e3bc10e2af68a432903bf0
size 5104
Many of my files are being replaced with these links and my programs that are accessing these files are throwing errors as they are unable to read them.
I am working in Windows 10, I have git lfs installed, I am using git-bash on the Windows Cmd line. I believe that when I was installing git-bash, I enabled symbolic links, I am unsure if that could potentially be causing the issue.
If you need more information, please let me know. I really appreciate everyone's help!
These are the pointer files that Git LFS uses to track objects. The fact that you're seeing them means that the proper filters for your repository aren't set up. Run git lfs install within your checkout to install the filters both in your repository and in your ~/.gitconfig.
Once you've done that, you can run git lfs checkout to fix the current repository, and then Git LFS should work normally when you check out a branch. If you modify or replace your ~/.gitconfig file, be sure to keep the filter entries that git lfs install inserted there.
The proper commands to set the options are as follows:
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"
It's much easier to invoke git lfs install, though.
I have two remote repositories. One is private (Bitbucket) and the other public (Github). I had been pushing changes to Bitbucket using Github app and then pushing the same commit to Github repo using Xcode. However, recently I have been unable to PUSH the commits to Github and using SourceTree I get this error message:
This repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/pre-push.
This is how it looks from within SourceTree:
How can I get my Github repo to accept the most recent commits?
You have a pre-push hook which is telling you that you have git-lfs (large file support) enabled for this repository, but that it can't find the git-lfs program on your computer. The solution is to either remove the hook (which is located in .git/hooks/pre-push, as the error message says), or to fix your PATH so that it can find the git-lfs program.
It would have been enough to say that the .git directory is in the original local directory of your repository and you probably need a program like TextWrangler or similar, that shows the hidden files starting with a dot, to be able to see it and delete it by moving it to the trash (right click mouse). It took me one hour to figure out this. I hope no one else have to waste that time.
Here is the instructions for removing the pre-push file using Mac Terminal:
First: cd to the directory that is your local repository for your project. (The main folder that holds .xcodeproj and other files) The .git file is hidden but you can still access it by typing cd .git/hooks in terminal. If you type ls in terminal to view all files within the current directory, you'll notice the pre-push file. Type rm pre-push to remove the file. You should now be able to push to your remote repository. Just be sure to cd .. back a few times to your local directory for your project. Simple as that.
I have pathogen setup and working fine under Linux, but when I try to use the some configuration with gvim73 under windows it doesn't work at all. I don't get any errors but it does nothing.
Here is my dotfiles repository up on git. I've checked this out to ~/vimfiles and I added the following to _vimrc:
filetype off
call pathogen#helptags()
call pathogen#runtime_append_all_bundles()
I've tried just about everything including putting the autoload/pathogen.vim and bundles/ folders in the /vim73 directory under program files. Nothing.
Does anyone have some experience with this? I'm assuming there is something windows specific that needs to happen to make this work.
Edit: It is probably also worth noting I can run pathogen#runtime_append_all_bundles() even using tab completion so pathogen is being loaded, but my plugins are just not working.
I'm not sure it will help but here is my working configuration:
d:\soft\vim\vim73\ - gvim itself, i.e.
pathogen.vim is copied into the
d:\soft\vim\vim73\autoload\
d:\soft\vim\vimfiles\bundle - directory
for plugins
Corresponding lines from configuration file d:\soft\vim\_vimrc:
" Use pathogen to load plugins from bundle directory
filetype off
call pathogen#runtime_append_all_bundles()
call pathogen#helptags()
Also I changed pathogen#helptags because original didn't work for my paths:
dir[0 : strlen($VIM)-1] !=# $VIM has been changed to stridx(dir, "bundle") != -1
It's an old question, but I had the same issue and solution as the OP, and it has a mildly annoying origin. I was using the following script to install everything on Windows (Vista+ and run as admin if you want the mklink part to work):
cd "%UserProfile%"
rmdir vimfiles /S /Q
git clone http://github.com/brymck/dotvim.git vimfiles
del _vimrc
mklink _vimrc vimfiles\vimrc
cd vimfiles
git submodule init
git submodule update
The above is just a Windows-y version of a Vimcast on syncing your Vim preferences with GitHub and is fairly straightforward, so I figure others may be doing something similar.
Anyway, your experience may differ (and this doesn't apply to Cygwin), but when I just copied and pasted this into the terminal, git submodule update got "eaten" while git submodule init was running. I didn't figure it out initially because this had never happened to me on Linux. In short, wait until everything else has completed before running git submodule update and you should be golden. (Also, FWIW, I'm using the current version of pathogen, which was last updated September 25, 2011.)
For me renaming the .vim folder into vimfiles solved the problem for Vim 7.4.
I had some kind of issue on Windows when I used the pathogen version provided by Vim.org
However, using github pathogen head, the issue was fixed.
I think the latest release from Vim.org is from January last year, and the latest commit on github is from November.
Specifically, I had this issue with after directory:
https://github.com/tpope/vim-pathogen/issues/closed#issue/12
I know this is a long time ago, but maybe it will help someone ... I had the same issue. It wouldn't give me any errors, but no plugins would be loaded. I then RTFM and noticed that he explicitly states at the top of this page that it should go in your vimrc not gvimrc. After I changed that I had no problems.
I am a complete Noob when it comes to GIT. I have been just taking my first steps over the last few days. I setup a repo on my laptop, pulled down the Trunk from an SVN project (had some issues with branches, not got them working), but all seems ok there.
I now want to be able to pull or push from the laptop to my main desktop. The reason being the laptop is handy on the train as I spend 2 hours a day travelling and can get some good work done. But my main machine at home is great for development. So I want to be able to push / pull from the laptop to the main computer when I get home. I thought the most simple way of doing this would be to just have the code folder shared out across the LAN and do:
git clone file://192.168.10.51/code
unfortunately this doesn't seem to be working for me:
so I open a git bash cmd and type the above command, I am in C:\code (the shared folder for both machines) this is what I get back:
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
How can I share the repository between the two machines in the most simple of ways.
There will be other locations that will be official storage points and places where the other devs and CI server etc will pull from, this is just so that I can work on the same repo across two machines.
As per Sebastian's suggestion I get the following:
C:\code>git clone --no-hardlinks file://192.168.10.51/code
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
**EDIT - ANSWER **
Thanks to all that helped. I tried the mapping a drive and that worked so thought I would go back and retry without mapping. The final result was:
git clone file://\\\\192.168.0.51\code
This worked great.
Thanks
You can specify the remote’s URL by applying the UNC path to the file protocol. This requires you to use four slashes:
git clone file:////<host>/<share>/<path>
For example, if your main machine has the IP 192.168.10.51 and the computer name main, and it has a share named code which itself is a git repository, then both of the following commands should work equally:
git clone file:////main/code
git clone file:////192.168.10.51/code
If the Git repository is in a subdirectory, simply append the path:
git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository
$ git clone --no-hardlinks /path/to/repo
The above command uses POSIX path notation for the directory with your git repository. For Windows it is (directory C:/path/to/repo contains .git directory):
C:\some\dir\> git clone --local file:///C:/path/to/repo my_project
The repository will be clone to C:\some\dir\my_project. If you omit file:/// part then --local option is implied.
the answer with the host name didn't work for me
but this did :
git clone file:////home/git/repositories/MyProject.git/
I was successful in doing this using file://, but with one additional slash to denote an absolute path.
git clone file:///cygdrive/c/path/to/repository/
In my case I'm using Git on Cygwin for Windows, which you can see because of the /cygdrive/c part in my paths. With some tweaking to the path it should work with any git installation.
Adding a remote works the same way
git remote add remotename file:///cygdrive/c/path/to/repository/
Maybe map the share as a network drive and then do
git clone Z:\
Mostly just a guess; I always do this stuff using ssh. Following that suggstion of course will mean that you'll need to have that drive mapped every time you push/pull to/from the laptop. I'm not sure how you rig up ssh to work under windows but if you're going to be doing this a lot it might be worth investigating.
Not sure if it was because of my git version (1.7.2) or what, but the approaches listed above using machine name and IP options were not working for me. An additional detail that may/may not be important is that the repo was a bare repo that I had initialized and pushed to from a different machine.
I was trying to clone project1 as advised above with commands like:
$ git clone file:////<IP_ADDRESS>/home/user/git/project1
Cloning into project1...
fatal: '//<IP_ADDRESS>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
and
$ git clone file:////<MACHINE_NAME>/home/user/git/project1
Cloning into project1...
fatal: '//<MACHINE_NAME>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
What did work for me was something simpler:
$ git clone ../git/project1
Cloning into project1...
done.
Note - even though the repo being cloned from was bare, this did produce a 'normal' clone with all the actual code/image/resource files that I was hoping for (as opposed to the internals of the git repo).
Either enter absolute paths or relative paths.
For example the first one below uses absolute paths :
(this is from inside the folder which contains the repository and the backup as subfolders. also remember that the backup folder is not modified if it already contains anything. and if it is not present, a new folder will be created )
~/git$ git clone --no-hardlinks ~/git/git_test1/ ~/git/bkp_repos/
The following uses relative paths :
~/git$ git clone --no-hardlinks git_test1/ bkp_repos2/
While UNC path is supported since Git 2.21 (Feb. 2019, see below), Git 2.24 (Q4 2019) will allow
git clone file://192.168.10.51/code
No more file:////xxx, 'file://' is enough to refer to an UNC path share.
See "Git Fetch Error with UNC".
Note, since 2016 and the MingW-64 git.exe packaged with Git for Windows, an UNC path is supported.
(See "How are msys, msys2, and MinGW-64 related to each other?")
And with Git 2.21 (Feb. 2019), this support extends even in in an msys2 shell (with quotes around the UNC path).
See commit 9e9da23, commit 5440df4 (17 Jan 2019) by Johannes Schindelin (dscho).
Helped-by: Kim Gybels (Jeff-G).
(Merged by Junio C Hamano -- gitster -- in commit f5dd919, 05 Feb 2019)
Before Git 2.21, due to a quirk in Git's method to spawn git-upload-pack, there is a
problem when passing paths with backslashes in them: Git will force the
command-line through the shell, which has different quoting semantics in
Git for Windows (being an MSYS2 program) than regular Win32 executables
such as git.exe itself.
The symptom is that the first of the two backslashes in UNC paths of the
form \\myserver\folder\repository.git is stripped off.
This is mitigated now:
mingw: special-case arguments to sh
The MSYS2 runtime does its best to emulate the command-line wildcard expansion and de-quoting which would be performed by the calling Unix shell on Unix systems.
Those Unix shell quoting rules differ from the quoting rules applying to Windows' cmd and Powershell, making it a little awkward to quote command-line parameters properly when spawning other processes.
In particular, git.exe passes arguments to subprocesses that are not intended to be interpreted as wildcards, and if they contain backslashes, those are not to be interpreted as escape characters, e.g. when passing Windows paths.
Note: this is only a problem when calling MSYS2 executables, not when calling MINGW executables such as git.exe. However, we do call MSYS2 executables frequently, most notably when setting the use_shell flag in the child_process structure.
There is no elegant way to determine whether the .exe file to be executed is an MSYS2 program or a MINGW one.
But since the use case of passing a command line through the shell is so prevalent, we need to work around this issue at least when executing sh.exe.
Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and
whether it refers to the MSYS2 Bash, to determine whether we need to
quote the arguments differently than usual.
That still does not fix the issue completely, but at least it is something.
Incidentally, this also fixes the problem where git clone \\server\repo failed due to incorrect handling of the backslashes when handing the path to the git-upload-pack process.
Further, we need to take care to quote not only whitespace and backslashes, but also curly brackets.
As aliases frequently go through the MSYS2 Bash, and as aliases frequently get parameters such as HEAD#{yesterday}, this is really important.
See t/t5580-clone-push-unc.sh
After clone, for me push wasn't working.
Solution:
Where repo is cloned open .git folder and config file.
For remote origin url set value:
[remote "origin"]
url = file:///C:/Documentation/git_server/kurmisoftware
Given a (source) patch file, what's the easiest way to apply this patch on the source files under Windows?
A GUI tool where I can visually compare the unchanged-changed source lines would be great.
A good way to apply a patch file under Windows OS is using Git.
As I understood, Git is a version control solution like SVN.
Here is a guideline to apply a patch :
First of all, download the latest release of the Windows Git Edition here :
GIT
With the cmd prompt, change directory to the patch file and files to patch
Now you can use the following command line :
git apply --ignore-space-change --ignore-whitespace --whitespace=nowarn file.patch
Not that since Git 2.3.3 (March 2015), you can use git apply --unsafe-paths to use git apply outside a git repo.
See commit 5244a31 by Junio C Hamano (gitster)
"git apply" was not very careful about reading from, removing, updating and creating paths outside the working tree (under --index/--cached) or the current directory (when used as a replacement for GNU patch).
The documentation now includes:
--unsafe-paths:
By default, a patch that affects outside the working area (either a Git controlled working tree, or the current working directory when "git apply" is used as a replacement of GNU patch) is rejected as a mistake (or a mischief).
When git apply is used as a "better GNU patch", the user can pass the --unsafe-paths option to override this safety check.
This option has no effect when --index or --cached is in use.
So if you have git installed, git apply could help, even outside of any git repo.
Patch for Windows is what you're looking for.
WinMerge is awesome.
http://winmerge.org/