Em Thu, 3 Dec 2009 22:42:38 +0100 (CET)
Guennadi Liakhovetski <[email protected]> escreveu:
> On Thu, 3 Dec 2009, Hans Verkuil wrote:
>
> > On Wednesday 02 December 2009 04:55:00 Andy Walls wrote:
> > > On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote:
> > > > Hi all,
> > > >
> > > > I would like to start a discussion which ideally results in either
> > > > changing the SCM of v4l-dvb to git _or_ leaving everything as it is
> > > > today
> > > > with mercurial.
> > > >
> > > >
> > > > I'm waiting for comments.
GIT.
However, just using what we have in -hg at -git won't give much benefits. We
should really move forward and use a clone of Linus tree.
I intend to work on a way to allow us to move to -git, while preserving our
building system. My target is to do it at the beginning of the next year.
> > >
> > > I only have one requirement: reduce bandwidth usage between the server
> > > and my home.
> > >
> > > The less I have to clone out 65 M of history to start a new series of
> > > patches the better. I suppose that would include a rebase...
The first clone of the Linus -git tree will be more painful than 65 Mb of
downloads
Well, -git supports partial clone, were it discards the old history:
$git help clone
...
--depth <depth>
Create a shallow clone with a history truncated to the specified
number of revisions. A shallow
repository has a number of limitations (you cannot clone or fetch
from it, nor push from nor into it),
but is adequate if you are only interested in the recent history
of a large project with a long history,
and would want to send in fixes as patches.
...
I never used it, so I can't tell if this works properly.
However, the big advantage with -git is that, once you have one local clone,
you may do other clones that will use a shared repository of objects.
Here, I use one git full clone of the Linus tree, created with:
git clone --bare <git repository> master-git-repo.git
Being a bare tree, it will only contain the objects (we generally name bare
repos with .git extension).
Then, my -git working dirs are created with:
git clone -s
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
linux-2.6.git
This clone is very fast, since it is local and is sharing the bare objects.
I then add, at myclone/.git/config two remote repositories, like:
[remote "linus"]
URL = /home/myhome/tokernel/bare/linus.git/
fetch = +refs/tags/*:refs/remotes/linus/*
fetch = +refs/heads/master:refs/remotes/linus/upstream
tagopt = --no-tags
[remote "origin"]
URL =
ssh://my.remote.site.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
fetch = +refs/heads/*:refs/remotes/linux-2.6.git/*
Push = refs/heads/*:refs/heads/*
This way, every time I want to update from upstream or from my remote repo,
I run a script with something like:
$ (cd linux-2.6.git && git fetch)
$ (cd myclone && git remote update)
And, every time I want to push to my remote repo, i do:
$ git push origin
The advantage of having a bare directory is that I can have several other local
git
trees, each completely independent from the bare, and all with all the files
checked-out.
If you're doing lots of things at the same time, this is a way safer than using
branches.
Btw, git branch work really really well. Also, as git revlog provides a
changelog history,
you can do rollbacks if needed.
Ah, with respect to rebase, the better way, IMHO, to rebase your directory is
to create
a new branch based on the latest upstream, pull the patches there, and then
rebase.
The big advantage is that you'll keep your old work untouched, so, if you do
something wrong,
you can simply delete the new branch an do it again.
> >
> > Unfortunately, one reason for moving to git would be to finally be able to
> > make changes to the arch directory tree. The fact that that part is
> > unavailable in v4l-dvb is a big problem when working with SoCs. And these
> > will
> > become much more important in the near future.
>
> FWIW, tomorrow (or a day or two later) I'll have to spend time again
> back-porting arch changes from git to hg, to be able to push my current
> patches...
My current maintainership live is to do ports/backports between hg and git.
This is
very time demanding those days... Moving to git will be really great.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
