[mythtv] FFmpeg plans

[Ian Campbell]

On Sat, 2018-05-12 at 12:29 -0400, Peter Bennett wrote:
> > For cherry-picking there is a process given in https://stackoverflow.co
> > m/questions/12978260/how-do-i-go-to-a-specific-commit-using-git-subtree
> >   (second half of first answer) which looks pretty plausible to me, but
> > it does rely on not using `--squash` for the regular merges (although
> > possibly it could be adapted).
> It is a bit messy - 5 step process.

Yeah, it might be possible to script a bunch of it in a nice way.
Perhaps it is worth dropping a line to the git devs with a wishlist
request?

> > TBH I'd recommend not using squash anyway, it'll give a more accurate
> > picture of the history which is useful for people doing archaeology
> > which crosses into the ffmpeg tree (it shows the actual upstream
> > commits and authors instead of the subtree-merger) and I think git does
> > a better job of merging etc if it has more granular history to look at
> > (e.g. I think it can spot when the same changes appear in two commits
> > in different branches, perhaps due to cherry-picking, which helps merge
> > do the right thing more often).
> The thing I was concerned about with that is that there are so many 
> commits in FFmpeg compared with MythTV, that they would overwhelm the 
> history. There are 91000 commits in the master branch of FFmpeg. I 
> feared that the day I pulled in the subtree without squash, it may 
> become very difficult to find anything useful pertaining to MythTV in 
> the log. Perhaps that would only affect certain views of the log.

`git log` orders things by commit date, so if the 91,000 ffmpeg commits
were largely historical then it wouldn't be so bad. But I suspect that
the ongoing flow of patches into ffmpeg probably outstrips mythtv by a 
fair bit, in which case your concerns would be true by default.

You can use `git log --not «branch|commit|etc»` to say "don't mention
things which are in here (i.e. `git log --not ffmpeg/master`), but
that's a bit tedious to remember to do.

> I am currently trying an approach of having a private copy of the FFmpeg 
> repository. Then I can use the simpler option at the bottom of the 
> stackoverflow  article, that says "Another more simple option, if you 
> have access to the original subtree repository, is to make the cherry 
> pick there in a branch and then just git subtree pull that specific 
> branch.".

That's effectively what the 5 step cherry-pick process above is doing,
it's just doing it all in the one repo using branches and bare
checkouts. It's certainly less things to keep straight in ones head to
do it in a separate repo though.

A separate repo presumably makes it easier to keep track of where
you've gotten up to (i.e. most recently merged) and lets you have
branches for fixes/30 etc and still keep cherry picking onto those
independently of master.

Ian.