From: Patrick Lehmann <Patrick.Lehmann@plc2.de>
To: Stefan Beller <sbeller@google.com>
Cc: Lars Schneider <larsxschneider@gmail.com>,
Git Mailinglist <git@vger.kernel.org>
Subject: AW: Restoring detached HEADs after Git operations
Date: Mon, 19 Jun 2017 18:09:21 +0000 [thread overview]
Message-ID: <0092CDD27C5F9D418B0F3E9B5D05BE0801028B70@SBS2011.opfingen.plc2.de> (raw)
In-Reply-To: <CAGZ79kbMOdkKiVsvxk4UeKKPicyi958LpomeY=ypXT0_=5d8BQ@mail.gmail.com>
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.
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?
Kind regards
Patrick
________________________________________
Von: git-owner@vger.kernel.org [git-owner@vger.kernel.org]" im Auftrag von "Stefan Beller [sbeller@google.com]
Gesendet: Montag, 19. Juni 2017 19:47
Bis: Patrick Lehmann
Cc: Lars Schneider; Git Mailinglist
Betreff: Re: Restoring detached HEADs after Git operations
On Mon, Jun 19, 2017 at 10:34 AM, Patrick Lehmann
<Patrick.Lehmann@plc2.de> wrote:
> Hello,
>
> I'm just an advanced Git user, not a Git developer. So I might find some time to improve the suggested script, which I provided with the hints given on the mailing list, but I have no time to do a complete feature release in your patch based Git flow.
ok, thanks for letting us know. I may re-prioritize the "reattach
HEAD" patches that I referenced earlier.
I would have hoped that additionally to the shell lines you'd have
given a good use case/summary.
> I have no experience with other shells then Bash. So if you rely on a Bash with less features, please port the syntax to such a shell system. (I personally do not support legacy programs or out-date programs).
>
> ------
> We are talking about circa 50 submodules in total with a maximum depth of 4. The platforms are:
> - Mint OS with Git in Bash
> - Windows 7 with Git-Bash
> - Windows 10 with Git-Bash
> - Windows 10 with Posh-Git
Thanks,
Stefan
next prev parent reply other threads:[~2017-06-19 18:09 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 ` Patrick Lehmann [this message]
2017-06-19 19:21 ` Stefan Beller
2017-06-19 20:13 ` AW: " 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=0092CDD27C5F9D418B0F3E9B5D05BE0801028B70@SBS2011.opfingen.plc2.de \
--to=patrick.lehmann@plc2.de \
--cc=git@vger.kernel.org \
--cc=larsxschneider@gmail.com \
--cc=sbeller@google.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).