Very good explanation. It clarifies something. I read some comments about
using subtree vs submodules. In most places people give a bad score to
submodules.
Четвер, 25 вересня 2014 р. 17:05:21 UTC+3 користувач Konstantin Khomoutov
написав:
On Thu, 25 Sep 2014 04:28:16 -0700 (PDT)
Віктор Невідомий mniv...@gmail.com javascript: wrote:
you have to turn each of these directories into separate
repositories and either use the so-called subtree merging or
submodules.
I was going to do so. Maybe it was not clear from my scheme in
original question. I edited it to clarify.
Proj1_2_common/
.git/
...
Proj1_2_3_common/
.git/
...
Proj1/
.git/
And after this again: what is advantages of subtree or submodules
over just add Proj1_2_common/ to project in IDE and use it repo
separately?
Ah, I see now, thanks.
The problem with simply adding them all into an IDE project is that
tracking that project's history with Git (I mean, tracking the files
comprising what constitutes a project in your IDE, such as .sln and a
set of *.csproj files for an C#/.NET application, and may be also some
code files etc) will produce a series of commits which, themselves,
contain no record of which exact states all of the referenced
subprojects were in when that commit has been recorded.
Let me try to explain that in more words.
Suppose you did what you intended, and just slapped a bunch of
git-clone'd projects under a single directory, and added references
to the files in them to your IDE's project. So far so good.
Now some time passes and some of those referenced projects get updated.
You'll typically `cd` into each of the referenced projects and do
`git pull` (or may be something more appropriate) there -- to bring the
latest changes in. You will then possibly make some adjustments to your
superproject and commit these changes.
Now you see that should you have the need to check out some *past*
revision of your superproject (maybe during `git bisect` or to just
fork a branch off some prior state etc), you'll discover that the
commit you're about to check out has no idea about which precise states
of the subprojects it references have been checked out when that commit
has been recorded. That happens because the synthetic state of all the
checked out projects was ad hoc, and was never recorded anywhere,
anyhow.
Enter subtree merging or submodules.
With subtree merging, you have histories of subprojects recorded in
your repository. You merge (and later re-merge) their new state
into your superproject from time to time, and hence any commit you
record on the top level -- for the files comprising the superproject
itself -- automatically references the correct states of all the
subprojects -- because they're in the same repository.
With submodules, your superproject maintains a list of submodules,
and each commit recorded in the superproject records SHA-1 names
of the commits currently checked out in each submodule at the time
the commit is created.
Hence, with either approach, when you later check any of your past
revisions of the superproject, the exact state of the whole thing is
reconstructed.
Pros and cons of these approaches are:
Subtree merging has everything in the single repository:
easier to carry around and view the history.
But this comes at the cost of having the histories
of the subproject in the superproject's repository.
Submodules require accessing other repos when you clone
the superproject and hence the superproject's repo is not
free-standing. On the other hand, there is no history duplication.
And what about history of old and new repos?
Either approach will make histories of subprojects available
when working on the superproject, though via different means.
Of course, you will have a single point in the history of your
superproject where you will have started using either of the
approaches explained above. If you want to somehow retrofit past
states of the subproject's histories intertwined with certain past
states of the superproject this is another task completely and,
while supposedly doable, this will be hard and tedious and manual
to get done.
it still would be better if you have copied the original answer inline
Only answer without question?
My bad: I meant question.
--
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.
