git-add

I'm having trouble adding a folder and all of it's subdirectories to my git repository. I realized this is a very popular question after doing some googling and I've tried each suggestion with no luck, specifically the suggestion from the man page on git-add . I even tried git add -A with no success. For simplicity sake, say I initialized my git repository as Dir1 . Then I have the following directory structure of files. Dir1/file1-1.txt Dir1/file1-2.txt Dir1/Dir2/file2-1.txt Dir1/Dir2/Dir3/file3-1.txt My real files have subdirectories that span 5-6 levels deep, so is there a git command to

Many times I mistakenly add unwanted files to the staging area using the git add . command. I wonder if there is a way I could completely disable this command, so that I only use git add file ? SVN re-education I guess it is a bad habit from svn, which has a default to add only tracked files [...] You must unlearn what you have learned :) You should run git status often. If files you want to ignore get listed as untracked files, you should then edit your .gitignore file, so that those files actually become ignored. Because git add doesn't affect ignored (and untracked) files, you will then be

Trying to split a hunk into smaller ones by git add -p and split option, but entire file appears as one hunk and I can't split it. I can edit, but removing lines causes the patch to fail. git help add says I should have split, and I recall using it, but in my current example the option doesn't appear in the prompt. When I choose the option help is printed, which says I can choose s to split :-[ Git version: 1.9.1. Xubuntu 14, oh-my-zsh. The hunk is not one line, it's multiple lines. Any ideas why would that be? Edited with more data, here's console log: +last line of long text Stage this hunk

I am currently trying to setup Git for a project I have been working on for a while. I do remember quite a while ago setting up Git but never used it for various reasons. Now I want to use it i am getting a strange issue that I believe is related to an old install. To start a fresh I installed a fresh Ubuntu OS so that there would be no Git install present and I copied the project (Grails) over. I then navigated to the directory and run the following commands: git init git remote add origin https://USERNAME@bitbucket.org/USERNAME/APPNAME.git Then I ran: git add . This is where i get the error

Is it possible to skip the staging area and (also) commit untracked, new files to git in a single built-in, command-line command ? If not, what are the alternatives ? http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Providing the -a option to the git commit command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the git add part: $ git commit -a -m 'added new benchmarks' Thanks. Using a single, built-in, command-line command? No. Using two commands: git add -A git commit Using a custom alias: Add this to

What's the difference between: git add . git commit -a Should I be doing both, or is that redundant? git commit -a means almost[*] the same thing as git add -u && git commit . It's not the same as git add . as this would add untracked files that aren't being ignored, git add -u only stages changes (including deletions) to already tracked files. [*] There's a subtle difference if you're not at the root directory of your repository. git add -u stages updates to files in the current directory and below, it's equivalent to git add -u . whereas git commit -a stages and commits changes to all

I would like to have some hooks always present in a clone of a given repository. Is there a way to add a file in .git/hooks in the repository? Thanks VonC It is possible to define your own hooks in a git template , but even there, those hooks would be non-executable ones. I.e. the user would still have to activate them (rename or activate the executable bit) once the repo is cloned. That way, said user won't have any unwanted script executed without his/her full knowledge and explicit approval. Doing otherwise would be too much of a security risk for anyone "blindly" cloning a repo . Sounds