openembedded-core | The official Git repository is at https : //git

It looks like the latest bitbake is Python 3 (header in source code) and has been for nearly 6 years! (change commit)

As noted in comments, the repository uses a Python script called combo-layer to import changes from the other repositories, retaining all their history information.

Although often used with a central server, or even a hosting service like GitHub, git is explicitly designed as a de-centralised versioning system, so this kind of thing is actually pretty easy to do:

• git remote can add a pointer to any other git repository; there is no identifier that has to match to say they're related
• git merge has an --allow-unrelated-histories flag that lets you combine two sets of commits that don't have any history in common
• git cherry-pick and git rebase can recreate the changes in a commit on top of some other history, including timestamp and committer information; there are options for editing the commit message
• git format-patch and git am allow for exporting and importing a series of patch files in a manner very similar to git cherry-pick or git rebase (originally used to distribute changes by e-mail)

So in your example, something like this has happened:

1. The latest history from openembedded-core was fetched
2. The commit 812eb3121e0aabe4e3de9a8c61b1e62c87f55aa4 was found to be new since the last import
3. A patch file was generated for that commit
4. The patch was edited to add the line "(From OE-Core rev: 812eb3121e0aabe4e3de9a8c61b1e62c87f55aa4)" to the commit message
5. The commit was merged into the poky repository, retaining its original committer information

As far as git's concerned, this isn't particularly magic; its happy to apply commits wherever you ask it to.

Packagegroups are just bitbake recipes for all intents and purposes. Therefore, you can simply create a new directory relative to your image directory, and put it there. Historically, I've done this

You're running out of inotify watches. Software such as Sublime and the program you're running here (among others) use inotify watches to detect changes to the file system, such as being able to track when files are changing or when the contents of a directory changes.

There's a (user settable) upper limit to the number of watches that can be in use at once, and the rather cryptic error message you're seeing here is a symptom of the limit being reached and the program failing to obtain a watch.

The default value for the maximum inotify watches may not be set high enough on your system for the software (and volume of files) that you're using, but you can change that if you like.

The output at the bottom of your error diagnotic information shows how you can view/adjust the upper limit. The following question also shows how you could do this as well.

https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached

The entire problem is due to the CRLF vs LF issue that you fixed for bitbake itself. Run that tool over all of the layers you checked out, or ideally figure out why the line endings are Windows-style and fix that: maybe you did the initial clone in Windows before moving to Linux? If so, just re-clone in Linux.