I installed a git precommit hook and sometimes I want to commit with --no-verify flag. I know how to do that in command line but I'd like to do that in TortoiseGit (since command line is very poor in Windows). How can I do that? I read through https://tortoisegit.org/docs/tortoisegit/tgit-dug-commit.html but can't find anything helpful.
No, it's not possible right now (as of 2.13.0.0) - it's not documented explicitly, just deducible using the source code.
If you use TortoiseGit, you should consider to use TortoiseGit hooks instead of vanilla git hooks.
Related
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.
With new versions of git new commands have been added which I will probably never use.
Is there a way I can disable these commands so that I my tab completion is faster?
For ex: before, git check<tab> would autocomplete to git checkout
But now git check<tab> doesn't tab complete due to there being git check-mailmap in the newer git version.
This is just one of the example.
Alternatively it would be great if I could "force" git to tab-complete "check" to checkout .
Edit: I use vanilla bash with no extra modifications
The official way is to use the configuration completion.commands and remove the ones you don't want:
git config --global completion.commands -check-mailmap
However, you can do even more. There is a hack in __git_main() used for testing that you can abuse to do what you want:
GIT_TESTING_PORCELAIN_COMMAND_LIST="$(git --list-cmds=list-mainporcelain,alias)"
This will force Git's completion to show only the main commands (and aliases).
You need Git v2.18 or newer for these to work.
To see how to remove items from the autocomplete, see FelipeC's answer.
An alternative is to use git aliases to create shorter alternatives to the commands you commonly use. For example:
git config --global alias.co checkout
Now you can type git co to check out files.
I have a remote SVN repository and a local git repository. Using git-svn I have linked git to SVN and am successfully using git svn rebase, git svn dcommit to pull and push to the remote SVN repository.
However, when other people check out my previously-git-edited files with SVN and try to open them in VS2010, they receive a dialog telling them the line endings are inconsistent.
I've read a few things about the core.safecrlf option in git config, but would that fix my issue? I have a number of other people checking in, but we're all running windows - I figured the line endings would be the same?
Would setting core.safecrlf preserve the same type of line ends on checkout and on commit?
I have been dealing with this same issue lately. By default, Git on Windows sets core.autocrlf = true. What happens is that your files are checked out from the SVN repo with CRLF line endings, but are committed with unix-style (LF) line endings. When you dcommit those changes, I believe the files are pushed to the SVN server with the unix-style line endings as well. Now when someone checks out those files using SVN, no line ending conversion is performed.
You can set core.autocrlf = false so that no conversion is done. If you are all working in Windows, you shouldn't have any problems. If you are sharing the SVN repo with *nix users, then it is likely that you'll start having inconsistencies. This is the reason for the autocrlf option. The repos should remain consistent, and since Linux doesn't like to play nicely with CRLF, this autocrlf should be set to true.
Line endings problem is a well-known headache of git-svn. I would recommend to use SmartGit to work with your repository. I respects svn:eol-style value to use correct EOL in Git (translating to it to a corresponding .gitattirbutes value). You may also control svn:eol-style value on pushing to SVN by appropriate changes .gitattirbutes.
If you have an access to the server another approach is possible: just install SubGit into your SVN server. Then a linked Git repository will be created on the server such that every push to it will be automatically translated to SVN and vice versa. It also translates svn:eol-style to .gitattirbutes.
So I would recommend one of these solutions, but not git-svn that is (as I know) painfully slow on Windows.
Here is a GitHub article that describes your choices for handling end of line characters in Git:
https://help.github.com/articles/dealing-with-line-endings
Essentially Git helps convert EOL on different OS's. SVN has similar functionality. You will need to ensure that they are set in a consistent manner.
I have recently decided to take the git plunge, and am really enjoying using git, even on Windows.
My current open source project lives on subversion, all devs are familiar with subversion so I would like to keep subversion as the "source of truth" for now.
Nonetheless, I want to use git, so I went ahead and created a copy of the source on github using git svn. All my work is done against the source in github and I push my changes to github. Once every few days I also push my changes to svn and rebase.
The initial import seemed to go ok, but now every time I do a "git svn rebase" I keep on getting conflicts, even on files I have not changed in my get repository. This is causing me much pain.
Eg.
$ git svn rebase
First, rewinding head to replay your work on top of it...
Applying: Added git ignore file
c:/Users/sam/Desktop/MediaBrowserGit/trunk/.git/rebase-apply/patch:12: trailing
whitespace.
*/obj/*
error: .gitignore: already exists in index
Using index info to reconstruct a base tree...
:12: trailing whitespace.
*/obj/*
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 Added git ignore file
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
rebase refs/remotes/git-svn: command returned error: 1
My questions:
Is there any way I can tell git to sync itself up with svn using svn as the source, so I can start with a clean slate. (export latest, check in changes and reset the svn refs somewhere)
Are there any tips and tricks to getting this scenario to work consistently?
Should I have the core.safecrlf and core.autocrlf options set to true? It seems I will need a bit of hoop jumping.
Related:
http://kerneltrap.org/index.php?q=mailarchive/git/2008/4/16/1450834/thread
http://markmail.org/message/vaois4kkr5ggugqs#query:git%20crlf+page:1+mid:i4flex6vmt5tdala+state:results
http://code.google.com/p/msysgit/issues/detail?id=271
It seems getting line endings right is a bit of a black art.
(I realize that this question probably needs to be expanded, please comment on the places that need expanding)
Are you getting line-ending conflicts? Git has a few configuration properties you can set that change how it handles the end of line characters. I have the following set:
# this makes git NOT attempt to convert line endings on commit and checkout
core.autocrlf=false
# this makes git check if the conversion done by autocrlf would be reversible
# this is probably not required because I do not have autocrlf turned on
core.safecrlf=true
Note that I am on windows, all my coworkers are on windows and I am interfacing with SVN through git-svn. These settings seem to do the trick for me.
(source: codinghorror.com)
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/