All of lore.kernel.org
 help / color / mirror / Atom feed
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.

             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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.