With the IronBee project (https://github.com/ironbee/ironbee/ - which has a
TS plugin) I ran into similar issues with submodules.  They just do not cut
it were prone to get out of date and sensitive to git versions as I think
you are finding here.  I moved to use git-subtree instead.  For IronBee I
pull in luajit like this:

Create a remote:

    git remote add luajit-2.0 http://luajit.org/git/luajit-2.0.git

Then merge in the upstream source with:

    git subtree pull --squash --prefix=libs/luajit-2.0-ironbee luajit-2.0

NOTE: Be careful not to add a trailing "/" on the --prefix= as this will
cause problems.

The libs/luajit-2.0-ironbee subdirectory is now part of the IronBee tree,
but can still be updated easily when upstream changes.  By using the
--squash, you get nice snapshot merges of the luajit source in the IronBee
history.  There are some subtle issue with rebasing, but for the most part
I have been very happy with doing this.

For example, my last sync with upstream on Mar 26 looks like this, which
has a nice summary of changes from luajit and notes any conflicts during
the merge (I have local changes to the Makefiles).

commit 85d629a046b95d8523121b72d2fd1ed20c60fd9b
Merge: 4c2b23f bab6d34
Author: Brian Rectanus <brecta...@qualys.com>
Date:   Wed Mar 26 23:04:52 2014 -0500

    luajit: Sync with upstream v2.0.3.

    Conflicts:
        libs/luajit-2.0-ironbee/Makefile
        libs/luajit-2.0-ironbee/src/Makefile

commit bab6d34e7a07d90a3d90d6128525669f5f14f0f8
Author: Brian Rectanus <brecta...@qualys.com>
Date:   Wed Mar 26 23:02:37 2014 -0500

    Squashed 'libs/luajit-2.0-ironbee/' changes from f2397a8..541182e

    880ca30 RELEASE LuaJIT-2.0.3
    30c5757 Update changelog.
    80efb07 DynASM: Emit version check after .arch directive.
    416abff Don't access dangling reference to reallocated IR.
    e941508 Fix frame depth display for bytecode dump in -jdump.
    ef3cc47 Fix recording of BC_VARG.
    900d0ce Fix for -jdump docs.
    6a47e12 Add PS4 port.
    998651f Don't purge modified function from stack slots in BC_RET.
    1994a24 FFI: Disallow nested VLS.
    2bc63bb Prevent BASE register coalescing if parent uses IR_RETF.
    e3d5b21 Fix quoting in xedkbuild.bat (again).
    2be62dc Fix exception unwind struct declaration.
    9247541 Fix OSX build issue.
    dd910f0 Fix initial maxslot for down-recursive traces.
    3db3cc1 Fix compiler warnings.
    926686a Fix OSX build issue.
    45c067d FFI: Fix cts->L for cdata unsinking in snapshot restore.
    ef59e54 Bump copyright date to 2014.
    6964a77 Fix ABC elimination.
    b779f31 Fix MinGW build.
    ca67c89 MIPS: Cosmetic fix for interpreter.
    89e8d70 Fix compilation of string.byte(s, nil, n).
    279673d Fix MinGW build.
    0ded8e8 Fix call unroll checks in the presence of metamethod frames.
    916f09d x64: Fix store to upvalue for lightuserdata values.
    f371ed6 Respect jit.off(func) when returning to a function, too.
    9d90988 Follow-up fix for GC step threshold fix.
    751eace Improve msvcbuild.bat static linking.
    db64b2b FFI: Clarify ffi.cdef behavior.
    5a25a73 Fix type punning alias analysis for constified pointers.
    8941b19 Fix for last commit
    7b4d530 Fix GC steps threshold handling when called by JIT-compiled
code.
    8944e27 Fix handling of redundant PHIs.
    7e538b5 Check for failure to mark memory as executable (restricted
kernels).
    4fba08a Fix line number for relocated bytecode after closure fixup.
    5d25645 FFI: Rehash finalizer table after GC cycle, if needed.
    3cdeb54 Check for MAP_32BIT presence instead of checking for Linux.
    474bb21 Fix ABC elimination.
    f1e7a44 Fix snapshot restore for exit to function header.
    1f7b326 DynASM: Emit #line <n> <file> instead of #<n> <file>.
    782787f FFI/x64: Fix passing of vector arguments to calls.
    93c2b93 FFI: Fix argument checks for ffi.string().
    b6ec7c7 Fix quoting in xedkbuild.bat.
    7873c8d Recent GCC versions need more memory.
    fffe75a Fix frame traversal for backtraces.
    a6936be Fix compiler warning.
    fd1a8dd Fix argument checks for math.deg()/math.rad().
    362260b Fix jit.flush(func|true).
    99d588b Compatibility fix for old GCC versions.
    6a878b0 ARM: Fix register allocation when rematerializing FPRs.
    6dc0245 FFI: Properly unload loaded DLLs.
    ec96d8b DynASM/x64: Add VREG support to mov64.
    9aa5d04 Fix compilation on NetBSD/x64.
    519ef0c Add support for multilib distro builds.
    b2a13dd DynASM/x86: Add lock prefix.
    053041a FFI: Add missing GC steps for callback argument conversions.
    9211a66 Improve ULOAD forwarding for open upvalues.

    git-subtree-dir: libs/luajit-2.0-ironbee
    git-subtree-split: 541182eebacdf11b552ccdd3c95c602e60ec5f98


--
Brian Rectanus


On Tue, Apr 15, 2014 at 7:26 PM, Thomas Jackson <jacksontj...@gmail.com>wrote:

> I'd prefer to keep it as a submodule because it will make porting fixes etc
> significantly easier. Do we have any specifics about the problems in the
> build systems? I use git submodules for some tooling internally-- so I
> might be able to give a hand. The submodule stuff has been there for a
> while so I doubt its a problem with the version of git-- more likely the
> commands in the build scripts aren't running the appropriate updates etc.
>
>
>
>
>
>
> On Tue, Apr 15, 2014 at 4:51 PM, Phil Sorber <sor...@apache.org> wrote:
>
> > On Tue, Apr 15, 2014 at 4:44 PM, Leif Hedstrom <zw...@apache.org> wrote:
> >
> > > Hi all,
> > >
> > > we added LuaJIT as a submodule, and it seems to be breaking in odd ways
> > on
> > > the build systems. Some of them handles it, others do not. Presumably
> > > different git versions? E.g. it works on CentOS5, but not CentOS6, etc.
> > etc.
> > >
> > > How do we feel about simply just “importing” this into the tree, and
> deal
> > > with merging in upstream changes as necessary ? Unless someone else
> has a
> > > solution to this, I think that’s what we’ll have to do.
> > >
> >
> > I know some people have issues with that, and it's not ideal, but I am +1
> > on it. In my experience, git submodule does not always work as expected.
> I
> > dunno if it's not heavily used/tested, or flawed design. If we plan to
> > stick with one version anyway, it shouldn't be much of an issue and if
> > someone figures out what we are doing wrong with submodule we can always
> go
> > back to it in the future.
> >
> >
> > >
> > > Cheers,
> > >
> > > — Leif
> > >
> > >
> >
>

Reply via email to