New to Git / Questions about single user / multiple projects

I'm new to git and have some (I think) basic questions that I have not been able to find answers to in the documentation. It's very possible that these are the result of my lack in understanding git / version control, so feel free to point me to documentation that might contain the answers.

I'm doing ERP development for my job and various 'hobby' development in my spare time. I'd like to track/store/ version control the code that I write for both work and play. I am (currently) working by myself, no need to have multiple developers working of the same code.

Q1: Can I create a single repository (project?) for all my code, knowing that there are multiple small, unrelated projects. Or should I create a new repository for each project ?

Q2: After initalizing my repository, and comitting the 1st batch of code: When further working on the code, will the command "git add ." add all changed and new files ? Or do I specifically need to list the new files ?

Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
if from the root of the project ?

Thanks,

Rob.

-- When in trouble or in doubt, run in circles, scream and shout

I am not that familiar with git too, but see the answers below questions, respectively, and fix me if i am wrong.

On Wed, Aug 19, 2009 at 09:52, Rob (gmail) <robvanb@gmail.com> wrote:

git-submodule

=git status= or =git ls-files= will list the files in different statuses.

If there are no other files, such as backup file produced by editor, you can run =git add .=. If there are, try to configure in file =.git/info/exclude= or =.gitignore=.

Changed files can be committed automatically by =git commit -a=

You can.

                                                     Changsheng Jiang

My $0.02

On Wed, Aug 19, 2009 at 1:52 PM, Rob (gmail)<robvanb@gmail.com> wrote:

Thats entirely up to you. I prefer keeping lots of little repositories for unrelated projects. That way I can use cool things like git archive to generate tarballs if/when I need to. Although I do use the single repository method sometimes when I'm feeling lazy. One thing git has over some other VCSes is the ability to track changes past renames. That way you can start off lazy and just have a fairly flat code structure and then as you start to group code into logical sets you can move them into directories without any danger of losing history (one tip though, do the moving as a commit on its own this makes the re-name detection work a lot better).

As Changsheng pointed out. You can also have the best of both worlds and use git submodules to tie together multiple repositories. Although I've always though of submodules as more of a build tool when you want to track components of a larger system i.e. a linux distro might track the kernel, kde, gnome ... and use a submodule setup to track known stable points where those components work together.

You can use 'git add -u' which adds any locally modified (but not completely new) files to the index (its basically the first half of 'git commit -a'). For the new files either 'git add .' or list the files.

Yes all the git commands work from subdirectories (well except init/clone) . This is actually really useful if you want to get the history of a component in a large code base without getting a lot of irrelevant changes in other components.

On Tue, 18 Aug 2009, Rob (gmail) wrote:

It's much easier to have a new repository for each project. There are two possible ways to put multiple projects in a single repository: (1) you could have each one in a subdirectory, which is bad because each commit records the entire tree, so each project would have commits in its history that are about other projects; (2) you could have separate branches for each project; this is fine, but you only get one working directory per repository, so it's awkward because you can only have one of your projects checked out at a time.

On the other hand, it's pretty trivial to have lots of repositories, and there isn't really any disadvantage to it. In fact, you may want to have more repositories than projects at times, if you use the same project for multiple purposes and want to extend it in different ways at the same time.

You can use "git add .", but be aware that this tends to pick up random cruft you've left in the directory.

You can run almost every git command from subdirectories, and it does what you'd expect with filenames when you're in a subdirectory. E.g., "git add x" while in "a/b/" is like being in the project root and running "git add a/b/x"

	-Daniel
*This .sig left intentionally blank*

"Rob (gmail)" <robvanb@gmail.com> writes:

Documentation you might want to read: 

* "Git User's Manual", distributed with Git (installed at least on
  Linux at $sharedir/doc/git-$version/user-manual.html), also at
  http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

* "The Git Community Book", available at
  http://book.git-scm.com/

* "Pro Git.  Professional version control", available at
  http://progit.org/book/

You should create a new repository for each project. In git each commit is about state of whole repository.

If you have single unrelated files, you might want to consider using Zit tool (see http://git.or.cz/gitwiki/InterfacesFrontendsAndTools for details), but beware that it is in early stages of development.

(Although if you choose one big repository, you can split it later
with some effort using git-filter-branch (or git-split somewhere in
mailing list archives) if you didn't publish your repositories).
 

"git add ." would add _all_ new not ignored files, and would stage all changed files. But you would have to be sure that all files you don't want to be comitted, like generated files (*.o, *.log,...) and backup files of your editor (*~ or *.bak), are ignored using .gitignore (usually for generated files) and .git/info/excludes or core.excludesFile (usually for specific patterns like backup files).

Most git commands take subdirectory they are in into consideration when acting. "git add <filename>" in subdirectory works as expected.

Note that some commands need to have '.' as filename / pattern to be limited to current subdirectory / act on current directory.

:-)

Thanks all for all the answers :)

One last question based on the multiple projects issue: Is there a command that lists all your projects ?

My initial thought is that there probably isn't, as there is no relation between the project except the userID ?

Thanks again, Rob.

On Wed, Aug 19, 2009 at 3:59 AM, Jakub Narebski<jnareb@gmail.com> wrote:

Please do not toppost, and when responding cull the quoted part, so only those parts that are relevant to your reply are remaining.

On Wed, 19 Aug 2009, Rob wrote:

No, there no git commands for listing all your projects. BTW. you can use different identities for different projects by setting it in .git/config, i.e. in per-repository configuration file.

Simple solution, which finds only non-bare repositories, and which can find false positives:

 $ find ~ -name ".git" -type d -print

More complicated solution, used by gitweb, requires Perl, not checked that it works correctly, doesn't work with ancient repositories with symlink HEAD.

 $ perl -e '
 use File::Find qw(find);
 my @list = ();
 find({follow_fast => 1, follow_skip => 2, dangling_symlinks => 0,
       wanted => sub {
         return if (m!^[/.]$!);
         return unless (-d $_);
         push @list, $_ if -e "$_/HEAD" 
       }});
 print join("\n", @list)."\n";
 '

On Wed, Aug 19, 2009 at 8:18 AM, Jakub Narebski<jnareb@gmail.com> wrote:

Sorry, n00b mistake.

That seems like the best solution. How do I delete my initial repository that I created and obviously messed up ?

On Wed, Aug 19, 2009 at 08:28:04AM -0400, Rob (gmail) wrote:

If you have nothing of value in the whole directory, just "rm -rf repo". If you want to keep the working tree but delete all of the git bits, just "rm -rf .git".

-Peff

On Wed, Aug 19, 2009 at 02:18:07PM +0200, Jakub Narebski wrote:

That doesn't seem very accurate. It will find 'HEAD' in "logs/" of repositories with reflogs enabled, and "refs/remotes/*/" of cloned repositories, giving you a lot of false positives.

If you want accuracy, you can ask git rev-parse to verify whether a directory is a git repo; it actually uses a few different heuristics to check. For example:

  find . -type d |
    while read dir; do
      if GIT_DIR=$dir git rev-parse --git-dir >/dev/null 2>&1; then
        echo $dir
      fi
    done

but it is a bit slower, as you invoke rev-parse for every directory, and it actually does some verification of the contents of HEAD (so it is probably a bad idea for something like gitweb, which cares about performance).

If you want to do a cheap and fast check, searching for 'HEAD', 'refs', and 'objects' in the same directory is a reasonable heuristic.

-Peff

On Wed, 19 August 2009, Jeff King <peff@peff.net> wrote:

To be more exact it is simplified solution used by git; in this case _oversimplified_, as gitweb doesn't have problems with 'HEAD' in remote-tracking branches.

On the other hand gitweb currently does not detect submodules or submodule-like repositories, i.e. repositories inside working directory of other repository. So this could be improved...

Or "git --git-dir=$dir rev-parse 2> /dev/null"

If one follow preferred git conventions for naming non-bare repositories, and one doesn't have anything funny,

  $ find . -name "*.git" -type d

should be sufficient.