Re: [Mlt-devel] Some patches to reduce build warnings in mlt and kdenlive

[Dan D. <da...@de...>]

On Fri, Apr 10, 2009 at 11:12 AM, Ray Lehtiniemi <ra...@ma...> wrote:
> On Friday 10 April 2009 00:04:04 Dan Dennedy wrote:
>> I have a git question for you. I want to use git more, and hoperfully
>> eventually cut over to it exclusively for MLT
>
> sweet :-)
>
>
>> I used git-svn to clone
>> the top-level SF SVN repo because I want to reorganize mlt++/ into
>> mlt/ and pull miracle and valerie out of mlt/. Therefore, the top
>> level of my mlt git repo (git://mltframework.org/mlt.git) contains
>> mlt/, mlt++/, shotcut/, and vizinni/.
>
> yep, looks good.  i see a few svn revisions didn't make it into the
> git history:  some are for internal cvs2svn branch purposes, and the
> rest are for the various tagged releases.  these are the missing svn
> revisions in the git tree.
>
> 4
[...]
>
> for kdenlive, i ignored the internal branch commits, and just manually
> created the release tags on the appropriate git commits.

I had asked git svn to create tags... oh, I see, my working git repo
has remote branches that correspond to each tag. Then, I cloned a
public bare one from that. I will eventually tag the releases when I
have finalized the public git repos.

>> If I try to merge your branch into one of mine, then
>> it puts the contents of mlt++/ into the top level!
>
> our two trees won;t be mergable.  the histories are completely
> different.  even though mine is a strict subset of yours, the way git
> handles parent links makes corresponding svn commits into two distinct
> git commits. thus, merge has no common starting point to work from.
>
> i'll use your mlt.git tree from now on if i make patches to mlt/mlt++.
> that way, the merges should work more smoothly for you.

I have second thoughts about this approach. I would like to have a
single git repo for mlt and mlt++, but separate repos each for
shotcut, vizinni, miracle/valerie/albino/humperdink. Maybe wait a bit
before doing this. I already have made separate working trees for mlt
and mlt++ that I used to pull your branches and svn dcommit.

>> Hmm... maybe I should git svn clone each sub-project and instead
>> reorganize files in the subversion repo. Then, simply git svn rebase
>> each sub-project to pull down the new organization.

well, this is the path I started down last night except for
reorganization, of course. I think I shall do the reorg at the end of
the month - after the next release in days and some business travel I
have apr 19 - 24.

> perhaps... i'm not really an expert on git svn rebase.  i basically treat
> svn->git as a one way mirroring operation. i generally just use patch
> files on svn when putting git changes into kdenlive svn.
>
> i think marco tried to rebase the kdenlive git tree i built, and it got pretty
> confused.  this was likely due to the hoops i had to jump through to get
> a nice clean history for kdenlive... the KDE4 branch copy to trunk seemed
> to trigger some non-optimal behavior in git svn import, so the history
> is manually hacked together...  it is an accurate reflection of the svn
> tree, but i'm not sure the git side of it has the right metadata for things
> like rebase to work. i think the kdenlive git tree is probably "one way only"
> from svn to git, but not in the reverse direction.  with the simpler mlt svn
> history, bidirectional operation might be possible...

It seems to be working rather well for me. I am getting some mixed
forms of git history into svn - sometimes a separate svn commit for
each git one as it should be, but sometimes not. Maybe this depends
upon if I merge your branch into my master (svn remote) or first into
a new branch that I then merge into master.

My biggest problem currently is that my public git repo does not
retain your proper git history because of how I am pushing into svn
and then pulling back down in order to push to my public :-/. But
again, that git organization is temporary until I reorg. Ugh, rather a
mess.

> if you can describe the tree reorganization you want to do, perhaps i can
> help... i know git is quite good at handling reorganizations.  for example,

It is not simply moving files, but fixing up the build, which is not
based on something "high level" and I'd rather not bother you with.
Also, I plan to rename some things (inigo, fezzik, westley) in the new
mlt tree to remove the trademark infringements. Yes, this will have a
big impact, but so will the reorganization, so I may as well have one
big event instead of two.

> all the patches i do for kdenlive start out on a private tree in which i have
> completely reorganized the src/ folder into several subfolders.  git is perfectly
> able to backport those patches into the monolithic src/ folder when i generate
> branches for review, and it is also trivial to forward port the reorganization onto
> a new HEAD every day when i update git from svn.

impressive, but sounds fragile

-- 
+-DRD-+