From: Stefan Beller <sbeller@google.com>
To: Patrick Lehmann <Patrick.Lehmann@plc2.de>
Cc: Lars Schneider <larsxschneider@gmail.com>,
Git Mailinglist <git@vger.kernel.org>
Subject: Re: Restoring detached HEADs after Git operations
Date: Mon, 19 Jun 2017 12:21:36 -0700 [thread overview]
Message-ID: <CAGZ79kYB__LOK5MhK_OrXYL1xYgYW0Hk5XfjYfRWAcH_AJ78uQ@mail.gmail.com> (raw)
In-Reply-To: <0092CDD27C5F9D418B0F3E9B5D05BE0801028B70@SBS2011.opfingen.plc2.de>
On Mon, Jun 19, 2017 at 11:09 AM, Patrick Lehmann
<Patrick.Lehmann@plc2.de> wrote:
> Hello Stefan,
>
> the use case is as follows:
>
> The projects consists of circa 18 IP cores. Each IP core is represented by a Git repository. Think of an IP core as of a lonestanding DLL or SO file project. Each IP core references 2 submodules, which bring the verification environments for testing the IP core standalone.
So phrased differently: You are using submodules to avoid "DLL hell"
(sharing a lib, with ease of versioning as the submodules in the different IP
cores may be pointing at different versions).
>
> These 18 IP cores are grouped to bigger IP cores, referencing the low-level IP cores and each again the 2 verification submodules. Finally, the main project references the bigger IP cores and again the 2 verification cores.
>
> TOPLEVEL
> o- IP1
> o- UVVM
> o- VUnit
> o- IP2
> o- UVVM
> o- VUnit
> o- IP3
> o- UVVM
> o- VUnit
> o- IP4
> o- UVVM
> o- VUnit
> o- IP5
> o- UVVM
> o- VUnit
> o- IP6
> o- UVVM
> o- VUnit
> o- IP7
> o- UVVM
> o- VUnit
> o- IP8
> o- UVVM
> o- VUnit
> o- IP9
> o- UVVM
> o- VUnit
> o- IP10
> o- UVVM
> o- VUnit
> o- IP11
> o- UVVM
> o- VUnit
> o- IP9
> o- UVVM
> o- VUnit
> o- IP12
> o- UVVM
> o- VUnit
> o- UVVM
> o- VUnit
>
> That's the simplified structure. I can't write more, because it's a closed source project. You can find other usecases e.g. in my other open source projects. E.g. The PoC-Library or The PicoBlaze-Library and the corresponding PoC-Examples repository.
>
> Example: PoC
> Pile of Cores includes 4 Git submodules and is itself an IP core library.
> So PoC-Examples again references PoC. This looks like this tree:
>
> PoC-Examples
> |- lib/
> o- PoC
> |- lib
> o- Cocotb
> o- OSVVM
> o- VUnit
> o- .... OSVVM
> o- UVVM
>
> The library VUnit itself already includes OSVVM as a library.
>
> ----------------------
> Forcast:
> I'll write a new question / idea about multiple equal submodules and the memory footprint soon...
> Here is my original question posted on StackOverflow: https://stackoverflow.com/questions/44585425/how-to-reduce-the-memory-footprint-for-multiple-submodules-of-the-same-source
> ----------------------
>
> Do you need more use cases?
>
Well this use case points out a different issue than I hoped for. ;)
From the stackoverflow post and from looking at the layout here,
one of the major questions is how to deduplicate the submodule
object store for example.
By use case I rather meant a sales pitch for your initial email:
I use this bash script because it fits in my workflow because
I need branches instead of detached HEADS, because $REASONS
and I'd be interested in these $REASONS, which I assumed to be
* easier to work with branches than detached HEADS (it aids the workflow)
* we're not challenging the underlying mental model of tracking sha1s in
the superproject rather than branches.
At least I gave these reasons in the "reattach HEAD" stuff that I wrote,
but maybe there are others? (I know the code base of submodules very
well, but I do not work with submodules on a day-to-day basis myself...)
next prev parent reply other threads:[~2017-06-19 19:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-19 8:46 Restoring detached HEADs after Git operations Patrick Lehmann
2017-06-19 9:30 ` Lars Schneider
2017-06-19 9:52 ` AW: " Patrick Lehmann
2017-06-19 16:37 ` Stefan Beller
2017-06-19 17:34 ` AW: " Patrick Lehmann
2017-06-19 17:47 ` Stefan Beller
2017-06-19 18:09 ` AW: " Patrick Lehmann
2017-06-19 19:21 ` Stefan Beller [this message]
2017-06-19 20:13 ` Patrick Lehmann
2017-06-19 17:55 ` Junio C Hamano
2017-06-19 19:11 ` Stefan Beller
2017-06-19 16:31 ` Stefan Beller
2017-06-19 17:01 ` Jeff King
2017-06-19 17:56 ` Ævar Arnfjörð Bjarmason
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGZ79kYB__LOK5MhK_OrXYL1xYgYW0Hk5XfjYfRWAcH_AJ78uQ@mail.gmail.com \
--to=sbeller@google.com \
--cc=Patrick.Lehmann@plc2.de \
--cc=git@vger.kernel.org \
--cc=larsxschneider@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).