Replace Mercurial with GIT as SCM

Replace Mercurial with GIT as SCM

[Patrick Boettcher]

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.

To start right away: I'm in favour of using GIT because of difficulties I 
have with my "daily" work with v4l-dvb. It is in my nature do to mistakes, 
so I need a tool which assists me in fixing those, I have not found a 
simple way to do my stuff with HG.

I'm helping out myself using a citation from which basically describes why 
GIT fits the/my needs better than HG (*):

"The culture of mercurial is one of immutability. This is quite a good
thing, and it's one of my favorite aspects of gnu arch. If I commit
something, I like to know that it's going to be there. Because of this,
there are no tools to manipulate history by default.

git is all about manipulating history. There's rebase, commit amend,
reset, filter-branch, and probably other commands I'm not thinking of,
many of which make it into day-to-day workflows. Then again, there's
reflog, which adds a big safety net around this mutability."

The first paragraph here describes exactly my problem and the second 
descibes how to solve it.

My suggestion is not to have the full Linux Kernel source as a new base 
for v4l-dvb development, but "only" to replace the current v4l-dvb hg with 
a GIT one. Importing all the history and everything.

Unfortunately it will change nothing for Mauro's job.

I also understand that it does not give a lot to people who haven't used 
GIT until now other than a new SCM to learn. But believe me, once you've 
done a rebase when Mauro has asked you to rebuild your tree before he can 
merge it, you will see what I mean.

I'm waiting for comments.

Thanks,

(*)
http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/

--

Patrick
http://www.kernellabs.com/

Re: Replace Mercurial with GIT as SCM

[Domenico Andreoli]

On Tue, Dec 01, 2009 at 03:59:20PM +0100, Patrick Boettcher wrote:
> Hi all,

hi,

> 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 should not be stopped by a tool i'm not familiar with (that is hg)
but actually it is a barrier for me. i'd like to regularly follow v4l-dvb
and surely with git i'd not waste the time as with hg.

the result is that i have a separate git tree for "my" tw68xx driver
and the integration with v4l-dvb and hg is not my topomost priority
given also that everything needs to be ported back to git before kernel
inclusion.

while i accept that people doing real work should use the tool the
prefer i consider this fracture with the kernel SCM a mistake.

this is only my opinion, my intent is not to start any flamewar.

regards,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: Replace Mercurial with GIT as SCM

[Alex Deucher]

On Tue, Dec 1, 2009 at 9:59 AM, Patrick Boettcher
<pboettcher@kernellabs.com> 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.
>
> To start right away: I'm in favour of using GIT because of difficulties I
> have with my "daily" work with v4l-dvb. It is in my nature do to mistakes,
> so I need a tool which assists me in fixing those, I have not found a simple
> way to do my stuff with HG.
>
> I'm helping out myself using a citation from which basically describes why
> GIT fits the/my needs better than HG (*):
>
> "The culture of mercurial is one of immutability. This is quite a good
> thing, and it's one of my favorite aspects of gnu arch. If I commit
> something, I like to know that it's going to be there. Because of this,
> there are no tools to manipulate history by default.
>
> git is all about manipulating history. There's rebase, commit amend,
> reset, filter-branch, and probably other commands I'm not thinking of,
> many of which make it into day-to-day workflows. Then again, there's
> reflog, which adds a big safety net around this mutability."
>
> The first paragraph here describes exactly my problem and the second
> descibes how to solve it.
>
> My suggestion is not to have the full Linux Kernel source as a new base for
> v4l-dvb development, but "only" to replace the current v4l-dvb hg with a GIT
> one. Importing all the history and everything.
>
> Unfortunately it will change nothing for Mauro's job.
>
> I also understand that it does not give a lot to people who haven't used GIT
> until now other than a new SCM to learn. But believe me, once you've done a
> rebase when Mauro has asked you to rebuild your tree before he can merge it,
> you will see what I mean.
>
> I'm waiting for comments.

I prefer git myself, but I'm not really actively working on v4l at the
moment, so, I leave it up to the active devs.  One nice thing about
git is the ability to maintain patch authorship.

Alex

Re: Replace Mercurial with GIT as SCM

[Antti Palosaari]

On 12/01/2009 04:59 PM, Patrick Boettcher wrote:
> I'm waiting for comments.

GIT

I have never used Git but as it is used by main Linux kernel devel tree 
I would prefer that too.

Antti
-- 
http://palosaari.fi/

Re: Replace Mercurial with GIT as SCM

[Trent Piepho]

On Tue, 1 Dec 2009, Patrick Boettcher wrote:
> To start right away: I'm in favour of using GIT because of difficulties I
> have with my "daily" work with v4l-dvb. It is in my nature do to mistakes,
> so I need a tool which assists me in fixing those, I have not found a
> simple way to do my stuff with HG.

Try the mq extension.  It's included by default with mercurial, you just
need to add:
[extensions]
hgext.mq=
to your .hgrc file.  It lets you maintain a stack of patches that you can
freely push and pop.  You can make changes and then commit them to one of
the existing patches.  Like git commit -amend, except you can amend any
patch not just the last one.  IMHO, it's better than stock git when you're
trying to make a good patch series.  There is something called stgit which
is very much like mq and a little better I think.

Re: Replace Mercurial with GIT as SCM

[Andy Walls]

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.

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...

Regards,
Andy

Re: Replace Mercurial with GIT as SCM

[Domenico Andreoli]

On Tue, Dec 01, 2009 at 06:25:00PM -0500, 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.
> 
> 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...

no, it would not. in case you feel better to clone something before a
rebase, you can clone it locally.

rebasing is an easily abused practice which destroys the history of
a branch and puts in trouble the followers of that branch. published
branch which is often rebased is usually frown upon.

git is a branch-merge-branch-throw-away-branch-branch-merge-... tool.
commit massaging is another tempting practice, it's so easy to produce a
cleaned up history of your branch. writing code in 2D is already pretty
difficult, God save us from writing code in 3D.

cheers,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: Replace Mercurial with GIT as SCM

[Hans Verkuil]

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.
>
> 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...

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.

Regards,

	Hans

>
> Regards,
> Andy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Replace Mercurial with GIT as SCM

[Hans de Goede]

+1 for git, I really really really miss being able to do
a simple "git rebase", and no rebase is not evil not as long
as you don't use it for anything but local patches.

Regards,

Hans




On 12/01/2009 03:59 PM, 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.
>
> To start right away: I'm in favour of using GIT because of difficulties
> I have with my "daily" work with v4l-dvb. It is in my nature do to
> mistakes, so I need a tool which assists me in fixing those, I have not
> found a simple way to do my stuff with HG.
>
> I'm helping out myself using a citation from which basically describes
> why GIT fits the/my needs better than HG (*):
>
> "The culture of mercurial is one of immutability. This is quite a good
> thing, and it's one of my favorite aspects of gnu arch. If I commit
> something, I like to know that it's going to be there. Because of this,
> there are no tools to manipulate history by default.
>
> git is all about manipulating history. There's rebase, commit amend,
> reset, filter-branch, and probably other commands I'm not thinking of,
> many of which make it into day-to-day workflows. Then again, there's
> reflog, which adds a big safety net around this mutability."
>
> The first paragraph here describes exactly my problem and the second
> descibes how to solve it.
>
> My suggestion is not to have the full Linux Kernel source as a new base
> for v4l-dvb development, but "only" to replace the current v4l-dvb hg
> with a GIT one. Importing all the history and everything.
>
> Unfortunately it will change nothing for Mauro's job.
>
> I also understand that it does not give a lot to people who haven't used
> GIT until now other than a new SCM to learn. But believe me, once you've
> done a rebase when Mauro has asked you to rebuild your tree before he
> can merge it, you will see what I mean.
>
> I'm waiting for comments.
>
> Thanks,
>
> (*)
> http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
>
>
> --
>
> Patrick
> http://www.kernellabs.com/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Replace Mercurial with GIT as SCM

[Laurent Pinchart]

On Thursday 03 December 2009 09:04:48 Hans de Goede wrote:
> +1 for git, I really really really miss being able to do
> a simple "git rebase", and no rebase is not evil not as long
> as you don't use it for anything but local patches.

For what it's worth, I second that. "git rebase -i" is one of git's killer 
features (I personally learned about it during Linus' talk at the LPC 2009, so 
if you haven't heard about "git rebase -i" before, take a look at it).

-- 
Regards,

Laurent Pinchart

Re: Replace Mercurial with GIT as SCM

[Guennadi Liakhovetski]

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.
> >
> > 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...
> 
> 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...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: Replace Mercurial with GIT as SCM

[Mauro Carvalho Chehab]

Em Thu, 3 Dec 2009 22:42:38 +0100 (CET)
Guennadi Liakhovetski <g.liakhovetski@gmx.de> 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