Re: Replace Mercurial with GIT as SCM
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
Em Thu, 3 Dec 2009 22:42:38 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
+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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
On Tue, Dec 1, 2009 at 9:59 AM, Patrick Boettcher pboettc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
