On Tuesday, December 2, 2014 12:51:39 AM UTC-8, Thomas Ferris Nicolaisen 
> 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.
> 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.

Okay, I can agree with your suggestion to put subtree issues on hold until 
I fully understand everything else, but please understand that the *only* 
reason that I'm even looking at Git, is because of the crippled way in 
which Subversion handles "externals", or shared code.  Virtually everything 
that I write anymore uses my shared-code modules.

In the meantime, I presented the directory listings specifically to 
demonstrate the project structure that I am trying to build - a directory 
of shared code, 1+ projects which link to that directory of shared code, 
and a very small number of projects that do not.  Typically the only 
projects that do *not* link to the shared code are reference projects that 
I've gotten from other sources, plus a 'files' directory containing 
single-source-file programs that don't link to anything, and don't have 

However, acting on your advice (which I think is excellent in this case), 
I'll go back to basics and forget about the sharing issue for now.
>From my ongoing reading, I *think* the way Git intends to work is that each 
project is a separate "repository"; am I seeing this right??  Given my 
experience with CVS and Svn, I view the "repository" as the container that 
contains the entire history of all projects that I have ever worked on.  I 
am suspecting that this world-view will not work with Git... 

But if this Git world-view is correct, where do I keep a central collection 
of all of my projects (what I call "the repository"), so I can (for 
example) back it up and have everything secured somewhere???  It seems like 
Git wants to make all of my projects completely unrelated to each other - 
but they're not!!  They are all projects that I'm responsible for, and need 
to be able to collect and control in various ways... 

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