From: THILLOSEN Andreas <thillosen@free.fr>
To: git@vger.kernel.org
Subject: Git: Question about specific subtree usage
Date: Sun, 12 Jan 2014 01:23:24 +0100 [thread overview]
Message-ID: <52D1E07C.1010403@free.fr> (raw)
Hi,
I have a question about a specific use case for subtrees, but I'm not
sure if is really possible (hence my e-mail, because all my tests failed
so far...)
>From what I have read, subtrees are used mainly to:
- Import inside a working git repository, other git repositories... it's
a little like a symbolic link pointing to another git repository, but
without the burden (it will be the main working git repository that will
handle the unified history);
- Merge many repositories into a single one (after that, they will be
seen as directories linked to the same history);
- Conversely, dispatch branches in a single repository, to make them
distinct repositories;
And now, here is my use case...
I have a big project, which contains many components (each one having,
for the moment, its own directory and repository):
MainLibrary/
MainLibrary-Tests/
Frontend1/
Frontend1-Tests/
Frontend2/
Frontend2-Tests/
MainLibrary contains the heart of the application; all other components
are linked to it when compiling.
For testing purpose, it must be possible to synchronize each component
independently (checking out MainLibrary at a specific tag level, and
checking out MainLibrary-Tests at another commit level for instance).
This is the important point... Each component must have its own history
line, and I must be able to check it out freely and independently from
the other components.
Here would be my dream... Each component would be managed by a subtree,
but ensure that:
- Components are not be tied to a same common branch... but I'm not sure
if it is possible to manage distinct history lines within a same git
history; after creating orphan branches, it becomes impossible to run
most operations like "check out");
- Any new developer would need only one basic operation to get the full
working material: clone one repo, and it's done (it would be awesome,
because in reality, my project is even bigger than my example). It would
spare us many scripting operations...
- Each component can be checked out at any desired level, and so we get
the sources of multiple components simultaneously (so far, using
subtrees or submodules, I had always the same trouble: I could only get
the sources of one component, which was the last I checked out or
activated).
Having a big shared history for all components may slow down some
operations, but it won't be a big problem for the scope of our project.
So... is my use case possible using git-magic? (I hinted subtrees, but
maybe there are better ways?)
Or must I keep my current methodology (one independant repository per
components... so each new developer must clones zillions of things at
the right place...)
Greetings,
Andreas THILLOSEN.
next reply other threads:[~2014-01-11 23:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-12 0:23 THILLOSEN Andreas [this message]
2014-01-12 10:29 ` Git: Question about specific subtree usage Torsten Bögershausen
2014-01-12 12:18 ` THILLOSEN Andreas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D1E07C.1010403@free.fr \
--to=thillosen@free.fr \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).