On Monday, December 1, 2014 9:30:53 PM UTC+1, derell...@gmail.com wrote:
> Okay, I've got a basic *working* directory that I want to use for all of 
> my git projects: c:\SourceCode\git_work
> Under c:\SourceCode\git_work, I have the following directories:
> + library_code          # general-reference library code that is used by 
> other projects
> + winagrams            # project which will access library_code via 
> subtree, when I learn how
> + wfontlist                # project which will access library_code via 
> subtree, when I learn how
> + ndir                      # project which will *not* access library_code
> + files                      # other single-file functions which will 
> *not* access library_code
> What is the correct way to build all of this structure??
> I initially ran "git init" only in the c:\SourceCode\git_work, then used 
> "git add ." and "git commit" in each of the subdirectories, to create the 
> repository.

Git init will initialize one Git repository in the current directory. So 
what you did there was to make git_work into a Git repository, followed by 
5 commits that added stuff to the repository.

> However, many of the online "newbie" references that I have looked at, 
> appear to run "git init" in each subdirectory...  That seems a little odd 
> to me; using the terminology that I've seen, it seems like each project 
> would be a separate "repository", but I actually want one repository that 
> contains *all* of my projects... am I mis-understanding exactly what 
> "repository" means??

There are cases where it's not clear what is the right structure of your 
repository or repositories. I suggest the following rules of thumb:

* Things that belong together go in the same repo (tightly coupled modules 
for example)
* Things that have nothing to do with each other go in separate repos (two 
unrelated projects)
* Things that follow the same release cycle and versioning go in the same 
repository (two related projects that are shipped together)
* Things that are built separately, or in isolation, go in separate repos

Now, again, there might be cases where the above guidelines are in 
conflict, and to that I'll say generally: When in doubt, leave stuff in the 
same repo. If need be, you can always split them again in the future (but 
try keeping them in distinct subdirectories to make this work easier).

> I've been using Subverson for years, but I'm new to git... that is 
> probably causing some confusion for me.
> I would be grateful for *any* clarification that I could get here!!!

I'd add to the above: Any "project" in SVN that has the trunk/branches/tags 
structure typically becomes one Git repo.

By the way, if you want to start over with Git-ifying your directories, all 
you have to do is to delete the .git folders created by the git init 
command. Warning: This will remove all the history/commits you made, but 
will leave all other files in place so you can start over cleanly.

And to be clear: I cannot say whether your git_work should be one repo or 
not. You'll have to say more about their relationships and purposes.

Finally, I suggest to put your subtree plans on hold until you've fully 
grokked what they are and when to use them.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to