[mythtv] FFmpeg plans

Brian J. Murrell brian at interlinx.bc.ca
Mon Apr 30 13:17:16 UTC 2018


On Mon, 2018-04-30 at 00:14 -0400, David Hampton wrote:
> 
> If I recall correctly, a git submodule requires write permission on
> the
> other repository (e.g. FFmpeg) in order to commit and
> changes/tags/etc.

Yes, that's because with git submodule, you only put a reference to a
sha1 of the repo you are setting up as a submodule.  Think of this like
creating a symlink to a directory somewhere else.

With a sub{tree|repo} you actually create an entire copy of the source
of the module you are subbing in your own repo.  Think of this like
creating a recursive copy of that directory somewhere else.

> That's probably a non-starter.

Of course.  Particularly where the remote repository maintainers are
unwilling to merge your changes.

> I'd love to hear more about your experience with subrepos.

It's been fine.  Using git subrepo (URL previously posted in this
thread), I did find I needed to switch to the 0.4.0 release branch
pretty quickly as the 0.3.0 branch was giving me problems.  But I would
not entirely rule out that that could have just been learning curve
with the limitations of git subrepo (probably applies to git subtree
also) and rebasing commits for/from the subrepo.

> I've been
> meaning to update many of the other external components, and haven't
> done so yet because I haven't had time to fully research submodules
> vs.
> subtrees (and now vs. subrepos).  Whichever we decide to use, we
> should
> use it consistently across all the external modules.

Agreed, well mostly.  I do still have a like for submodules, where they
fit, particularly if I am the maintainer of both the parent and child
modules.

One use case for using git sub* is not just to fork and keep changes in
an external repo but to keep code that is common to many projects in
one git module.  For this use-case, I tend to like git submodule better
as it truly does just mean maintaining the common code in one place and
then adding git submodule (references, not copies) to the projects that
want to use the module.  Because changes *have* to be made in the
module directly, it instills a workflow that requires changes be made
to the module itself and doesn't allow consumers of the module to keep
local changes (i.e. forget to push them back to the original module).

Where you want to keep local changes and don't have commit rights to
the module you are consuming, git sub{tree|repo} are the better tool. 
The one thing that does grate me the wrong with with git sub{tree|repo}
is the duplication.  I'm efficiency-OCD and hate waste so duplicating
an entire source tree feels wasteful to me.

As for which of git sub{tree|repo} to use, they both achieve the same
goal.  git subrepo is supposed to just be a better git subtree.  From
the README there:


   This command is an improvement from git-submodule and git-subtree;
   two other git commands with similar goals, but various problems.

I'll let you decide if subrepo is better than subtree since it's pretty
subjective.

Cheers,
b.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20180430/398fc4f4/attachment.sig>


More information about the mythtv-dev mailing list