[FFmpeg-devel] [RFC] FFmpeg "developers conference"

Uoti Urpala uoti.urpala
Wed Jun 20 17:30:32 CEST 2007


On Wed, 2007-06-20 at 16:39 +0200, Reimar D?ffinger wrote:
> On Wed, Jun 20, 2007 at 05:19:21PM +0300, Uoti Urpala wrote:
> > I didn't mean you couldn't update the repositories you create of course.
> 
> And I meant that I do not have to transfer the data needed to bring a
> branch up-to-date! Even though I even have "broadband" transferring the
> data of one week of patches still takes about 4 minutes for
> downloading, uploading is a fact of 8 to that!
> And all that just to push patches that are on exactly the same server
> already!
> 
> > > Just make the main tree read-only either via script or policy.
> > 
> > This sounds basically the same as what I meant (and different from your
> > original "make the git-svn clone writeable" - the git-svn part would not
> > be writable).
> 
> Actually I really meant "make the git-svn clone writeable". I didn't
> mean committing into the master branch that tracks svn, but I
> (incorrectly) assumed that to be obvious since then it wouldn't track
> svn anymore...

If you're only talking about sharing objects that does not require
making the git-svn repository writable or keeping everything as branches
within the same repository. You can set a pointer to an existing local
repository as an alternate to get objects from. See the "--reference"
argument to git-clone.

> > Having svn still in use will make merges somewhat harder compared to
> > pure git, as committed things will change as they go through git-svn and
> > back to git.
> 
> How, in what respect?

Because working with git-svn and making commits usually involves rebase,
and history gets changed in any case when you commit something to svn
and it comes back via git-svn. If there are multiple repositories using
git merges between them would normally work cleanly as long as people
don't rewrite their history for other reasons. The history rewrites
implied by svn use make merges trickier.

> > I suppose the git history will also be changed at some point to match
> > commit messages that were modified in svn history?
> 
> That brings me to a good question, how to change commit messages for
> git?

To change your latest commit message use "commit --amend" (this of
course modifies history so be careful if you've already distributed it
to other people). I'm not sure how to efficiently create a history graph
that is the same shape as an arbitrary given graph but with one commit
changed (this must necessarily involve recreating every commit which is
a descendant of this node in the ancestry graph). If the history after
commit X is linear then you can delete later commits, modify X to X' and
then rebase the original history after X on X'.





More information about the ffmpeg-devel mailing list