Hi Thomas;
Thank you for your in-depth response!
So generally, it sounds like under git I would expect to have *many*
different repositories, unlike Svn where I had one single repository
which contained all the projects that we'd ever worked on. Do I
understand correctly? It seems a little un-intuitive, but learning a
new system always takes some studying...
Derell
On 12/02/14 00:51, Thomas Ferris Nicolaisen wrote:
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
<mailto:git-users+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
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.
