Git
Subsystems (2)
As a heads up, I've started playing with GIT as the replacement of CVS. For information on the status of that conversion please see
http://www.linux-mips.org/wiki/Git
The converted repositories are accessible at via rsync at
rsync://ftp.linux-mips.org/git
And there gitweb, a web frontend to replace cvsweb available at:
http://www.linux-mips.org/wiki/git
Browse around, let me know if you find anything that doesn't work as you want it to.
For those with write permission into CVS, for now continue using CVS as always. For now the conversion is still only for testing and figuring out all the kinks.
Ralf
Quoted 3 lines
As a heads up, I've started playing with GIT as the replacement of CVS. For information on the status of that conversion please see
I assume the reason for choosing GIT was because the main line kernel uses the same source management tool. No chance of using Subversion I guess.
-Steve
Quoted 6 lines · On Tue, Sep 13, 2005 at 07:15:03AM -0500, [email protected] wrote:
Quoted 3 lines
As a heads up, I've started playing with GIT as the replacement of CVS. For information on the status of that conversion please see
I assume the reason for choosing GIT was because the main line kernel uses the same source management tool. No chance of using Subversion I guess.
Subversion maybe better but not good enough to justify the pain of switching, I think.
Btw, can subversion do a checkout in 10s?
Ralf
Quoted 6 lines · On Tue, 2005-09-13 07:15:03 -0500, [email protected]…
Quoted 3 lines
As a heads up, I've started playing with GIT as the replacement of CVS. For information on the status of that conversion please see
I assume the reason for choosing GIT was because the main line kernel uses the same source management tool. No chance of using Subversion I guess.
Is SVN already distributed? In the past, the non-distributed reality of CVS is what bought me a lot of trouble. And SVN isn't really designed for distribution, is it?
I for one see SVN as a CVS rewrite with some design flaws fixed, but it's for sure not what I actually want to use.
So I'm currently learning to use GIT. It's a bit strange when you start using it (because usually I interact with git itself as well as with eg. cogito), but I slowly get used to it :-)
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 11 lines · Jan-Benedict Glaw
Quoted 6 lines · On Tue, 2005-09-13 07:15:03 -0500, [email protected]…
Quoted 3 lines
As a heads up, I've started playing with GIT as the replacement of CVS. For information on the status of that conversion please see
I assume the reason for choosing GIT was because the main line kernel uses the same source management tool. No chance of using Subversion I guess.
Is SVN already distributed? In the past, the non-distributed reality of CVS is what bought me a lot of trouble. And SVN isn't really designed for distribution, is it?
SVN isn't, but SVK (which uses regular SVN) is.
Quoted 6 lines
I for one see SVN as a CVS rewrite with some design flaws fixed, but it's for sure not what I actually want to use.
So I'm currently learning to use GIT. It's a bit strange when you start using it (because usually I interact with git itself as well as with eg. cogito), but I slowly get used to it :-)
I think for kernel development git is the way to go.
Thiemo
Quoted 4 lines · Ralf Baechle
As a heads up, I've started playing with GIT as the replacement of CVS. For information on the status of that conversion please see
Which docs did you use to get yourself started? I'm also on the way getting familiar with GIT, doing my very first steps. It would be nice if we'd present what we know in Oldenburg (I already offered to do so, Joey planed it for Saturday).
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 7 lines · Jan-Benedict Glaw
Quoted 4 lines · Ralf Baechle
As a heads up, I've started playing with GIT as the replacement of CVS. For information on the status of that conversion please see
Which docs did you use to get yourself started?
The tutorial.txt that comes with git is ok I guess; cvs-migration.txt is helpful for CVS [1] experienced users. And of course, my favorite search engine.
Quoted 4 lines
I'm also on the way
getting familiar with GIT, doing my very first steps. It would be nice if we'd present what we know in Oldenburg (I already offered to do so, Joey planed it for Saturday).
Sounds like a plan. And maybe present some of the other alternatives to CVS as well?
Ralf
Since I didn't understand it, I did some digging around. I recorded what I figured out so far (which may, of course, be deeply wrong) in a wiki page
http://www.linux-mips.org/wiki/WhatIsGit
Unless and until someone else comes up with a link to something better like this - which I appreciate quite likely exists somewhere - perhaps this will get amended by others and become useful.
--
Dominic Sweetman
PATCH 1/1 Ethernet for TX4927(37) platform
Hello All!
This as a patch to add ethernet support for TX4927 platform. Does it makes sence to push it in?
Regards,
Vladimir
Description:
Ethernet support for TX4927/37 platform in 2.6.
drivers/net/ne.c +7 -1
@@ -54,7 +54,9 @@ static const char version2[] =#include <asm/system.h> #include <asm/io.h> -#if defined(CONFIG_TOSHIBA_RBTX4927 ) || defined(CONFIG_TOSHIBA_RBTX4938 ) +#if defined(CONFIG_TOSHIBA_RBTX4927 ) +#include <asm/tx4927/toshiba_rbtx4927.h> +#elif defined(CONFIG_TOSHIBA_RBTX4938 )#include <asm/tx4938/rbtx4938.h> #endif
@@ -237,6 +239,10 @@ struct net_device * __init ne_probe(int dev->base_addr =0x07f20280 ; dev->irq =RBTX4938_RTL_8019_IRQ ;#endif +#ifdef CONFIG_TOSHIBA_RBTX4927 + dev->base_addr =RBTX4927_RTL_8019_BASE ; + dev->irq =RBTX4927_RTL_8019_IRQ ; +#endif err =do_ne_probe (dev);if (err) goto out;
PATCH 1/1 RTC for TX4927(37) platform
Hello All!
This as a patch to add RTC support for TX4927 platform. The current RTC_DS1742=y can't be ever compiled.
Does it makes sence to push it in?
Regards,
Vladimir
Description:
RTC support for TX4927/37 platform in 2.6.
arch/mips/tx4927/common/Makefile +1 -1
@@ -6,7 +6,7 @@ # unless it's something special (ie not a .c file). # -obj-y += tx4927_prom.o tx4927_setup.o tx4927_irq.o tx4927_irq_handler.o +obj-y += tx4927_prom.o tx4927_setup.o tx4927_irq.o tx4927_irq_handler.o rtc_ds1742.o obj-$(CONFIG_TOSHIBA_FPCIB0) += smsc_fdc37m81x.o obj-$(CONFIG_KGDB) += tx4927_dbgio.o
include/asm-mips/tx4927/toshiba_rbtx4927.h +1 -0
@@ -49,6 +49,7 @@#define RBTX4927_SW_RESET_ENABLE 0xbc00f002#define RBTX4927_SW_RESET_ENABLE_SET 0x01 +#define RBTX4927_RTC_BASE 0xbc010000#define RBTX4927_RTL_8019_BASE (0x1c020280-TBTX4927_ISA_IO_OFFSET)#define RBTX4927_RTL_8019_IRQ (29)
arch/mips/tx4927/common/rtc_ds1742.c new file +141 -0
141 lines not on this page · raw message
arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c +0 -3
@@ -133,9 +133,6 @@ JP7 is not bus master -- do NOT use -- o#include <asm/time.h> #include <linux/bootmem.h> #include <linux/blkdev.h> -#ifdef CONFIG_RTC_DS1742 -#include <linux/ds1742rtc.h> -#endif #ifdef CONFIG_TOSHIBA_FPCIB0 #include <asm/tx4927/smsc_fdc37m81x.h> #endif
arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c +6 -58
85 lines not on this page · raw message
include/asm-mips/ds1742.h new file +29 -0
@@ -0,0 +1,29 @@ +/* +* Machine dependent access functions for RTC registers. +* +* Do not include this file directly. It's included from linux/ds1742rtc.h +* +* Author: Vladimir Barinov <[email protected]> +* +* (c) 2005 MontaVista Software, Inc. This file is licensed under the +* terms of the GNU General Public License version 2. This program is +* licensed "as is" without any warranty of any kind, whether express +* or implied. +*/ + +#ifndef __LINUX_DS1742_H +#define __LINUX_DS1742_H + +extern unsigned long rtc_base; + +static inline unsigned char CMOS_READ (unsigned long addr) +{ +return (*(volatile u8 *)(rtc_base + addr)); +} + +static inline void CMOS_WRITE (unsigned char data,unsigned long addr) +{ + *(volatile u8 *)(rtc_base + addr) = data; +} + +#endif /* __LINUX_DS1742_H */
arch/mips/tx4927/Kconfig +8 -0
@@ -1,3 +1,11 @@ +config TOSHIBA_TX4927_CPU_SPEED + int "CPU speed of the TX4927 processor (MHz)" + depends on TOSHIBA_RBTX4927 + default 200 + help + This sets the speed for the TX4927 processor. The default speed + is 200 MHz. + config TOSHIBA_FPCIB0 bool "FPCIB0 Backplane Support" depends on TOSHIBA_RBTX4927
PATCH 1/1 Remove compile warnings for TX4927(37) platform
Hello All!
This as a patch to aviod compile warnings for TX4927 platform.
Does it makes sence to push it in?
Regards,
Vladimir
Description:
Patch to aviod compile warnings from TX4927/37 platform.
arch/mips/tx4927/common/tx4927_irq.c +2 -0
@@ -567,6 +567,8 @@ int tx4927_irq_nested(void)#ifdef CONFIG_TOSHIBA_RBTX4927 { +extern int toshiba_rbtx4927_irq_nested (int + sw_irq); sw_irq =toshiba_rbtx4927_irq_nested (sw_irq); }#endif
arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c +2 -0
@@ -293,8 +293,10 @@ u32 bit2num(u32 num)int toshiba_rbtx4927_irq_nested (int sw_irq) {u32 level3; +#ifdef CONFIG_TOSHIBA_FPCIB0 u32 level4;u32 level5; +#endif level3 =reg_rd08 (TOSHIBA_RBTX4927_IOC_INTR_STAT ) &0x1f ;if (level3) {
arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c +1 -1
@@ -74,7 +74,7 @@ void __init prom_init(void)else mips_machtype =MACH_TOSHIBA_RBTX4937 ; - toshiba_name = toshiba_name_list[mips_machtype]; + toshiba_name = (char *)toshiba_name_list[mips_machtype]; msize =tx4927_get_mem_size ();add_memory_region (0 , msize <<20 ,BOOT_MEM_RAM );
arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c +7 -3
@@ -134,6 +134,9 @@ int tx4927_using_backplane = 0;extern void gt64120_time_init (void );extern void toshiba_rbtx4927_irq_setup (void ); +extern char *prom_getcmdline (void ); +extern void rtc_ds1742_init (unsigned long ); +#ifdef CONFIG_PCI #define CONFIG_TX4927BUG_WORKAROUND #undef TX4927_SUPPORT_COMMAND_IO
@@ -268,7 +271,9 @@ static int __init tx4927_pcibios_init(vou8 v08_64;u32 v32_b0;u8 v08_e1; +#ifdef TOSHIBA_RBTX4927_SETUP_DEBUG char *s =" sb/isa --" ; +#endif TOSHIBA_RBTX4927_SETUP_DPRINTK (TOSHIBA_RBTX4927_SETUP_PCIBIOS, ":%s beg\n",
@@ -353,7 +358,9 @@ static int __init tx4927_pcibios_init(vou8 v08_41;u8 v08_43;u8 v08_5c; +#ifdef TOSHIBA_RBTX4927_SETUP_DEBUG char *s =" sb/ide --" ; +#endif TOSHIBA_RBTX4927_SETUP_DPRINTK (TOSHIBA_RBTX4927_SETUP_PCIBIOS, ":%s beg\n",
@@ -971,9 +978,6 @@ void __init toshiba_rbtx4927_setup(void)void __init toshiba_rbtx4927_time_init (void ) { -u32 c1; -u32 c2; -TOSHIBA_RBTX4927_SETUP_DPRINTK (TOSHIBA_RBTX4927_SETUP_TIME_INIT ,"-\n" );rtc_ds1742_init (RBTX4927_RTC_BASE );
PATCH 1/1 Fix module insertion fail for TX4927/TX4938 platforms
Hello All!
This patch fixes module insertion fail for TX4927/TX4938 platforms for several drivers:
*** Warning: "__wbflush" [fs/reiserfs/reiserfs.ko] undefined!
*** Warning: "__wbflush" [fs/jbd/jbd.ko] undefined!
*** Warning: "__wbflush" [drivers/usb/gadget/net2280.ko] undefined!
*** Warning: "__wbflush" [drivers/usb/gadget/g_serial.ko] undefined!
*** Warning: "__wbflush" [drivers/net/ppp_generic.ko] undefined!
Does it makes sence to push it in?
Regards,
Vladimir
Description:
Fix module insertion fail on TX4927/TX4938 platforms
arch/mips/tx4927/common/tx4927_setup.c +2 -0
@@ -231,3 +231,5 @@ void pk0(void) printk("k0=[0x%08x]\n", val); }#endif + +EXPORT_SYMBOL (__wbflush);
arch/mips/tx4938/common/setup.c +2 -0
@@ -89,3 +89,5 @@ void __init tx4938_timer_setup(struct irwrite_c0_compare (count); c2 =read_c0_count (); } + +EXPORT_SYMBOL (__wbflush);
Re: [PATCH] Ethernet for TX4927(37) platform
In reply to Vladimir A. BarinovQuoted 4 lines · Vladimir A. Barinov
Hello All!
This as a patch to add ethernet support for TX4927 platform. Does it makes sence to push it in?
Whenever you want to start a new thread of discussion, please do so and don't simply press 'Reply' on some unrelated email and change the subject line. Your patches don't correspond to the GIT discossen, so please keep out out of it.
Thanks, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 8 lines · Ralf Baechle
Quoted 4 lines · Jan-Benedict Glaw
I'm also on the way
getting familiar with GIT, doing my very first steps. It would be nice if we'd present what we know in Oldenburg (I already offered to do so, Joey planed it for Saturday).Sounds like a plan. And maybe present some of the other alternatives to CVS as well?
I'm not sure if it's worth it. Linus decided against all other SCMs. I did use (for small test projects) monotone, darcs and arch. (I think all other alternatives aren't.)
monotone
Is quite nice'n'easy to use for CVS users, you'll have quite a fast start. The network sync protocol can be a bit lengthy at a time, but it works. It's acceptable in speed, but not exactly "fast". Written in C, code can easily be read and hacked.
darcs
Is easy to use, too, and quite some helpful. Network operations are a bit slower than those of monotone, but the real point is that it's merging algorithms are awfully slow. Also, it's written in Haskell (and getting a working compiler isn't exactly trivial), so the code is hard to read (for a C person), mostly because Haskell's concept are so different (it's a function programming language, after all.)
arch
Arch can do almost everything; it's network sync protocol is quite fast (can use several transports and will make use of caches). However, it's not exactly easy to use because of it's thousands of commands and it's project name conventions are, um, ugly. It has very good merging capabilities, but it's heavy use of local caches forces you to have loads of free HDD space.
CVS
Um, we all know the problems, don't we?
SVN
Not distributed, easy to use. Though there's a different frontend with distribution capabilities. Personally, SVN feels like CVS with it's major conceptual problems fixed.
More SCM questions?
So my famous last words are: I don't think it's worth really presenting all the other alternatives (except probably reading down the above text).
To get fixes/port updates/subsystem updates upstream to Linus, GIT is the way[tm] to go, so we'd try to get familiar with it.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 7 lines · Jan-Benedict Glaw
Quoted 6 lines · Ralf Baechle
Quoted 4 lines · Jan-Benedict Glaw
I'm also on the way
getting familiar with GIT, doing my very first steps. It would be nice if we'd present what we know in Oldenburg (I already offered to do so, Joey planed it for Saturday).
Quoted 6 lines
Quoted 2 lines
Sounds like a plan. And maybe present some of the other alternatives to CVS as well?
I'm not sure if it's worth it. Linus decided against all other SCMs. I did use (for small test projects) monotone, darcs and arch. (I think all other alternatives aren't.)
Have you tried mercurial?
Quoted 2 lines
To get fixes/port updates/subsystem updates upstream to Linus, GIT is the way[tm] to go, so we'd try to get familiar with it.
Still using plain patches and email...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 8 lines · Geert Uytterhoeven
Quoted 7 lines · Jan-Benedict Glaw
Quoted 6 lines · Ralf Baechle
Quoted 4 lines · Jan-Benedict Glaw
I'm also on the way
getting familiar with GIT, doing my very first steps. It would be nice if we'd present what we know in Oldenburg (I already offered to do so, Joey planed it for Saturday).
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Sounds like a plan. And maybe present some of the other alternatives to CVS as well?
I'm not sure if it's worth it. Linus decided against all other SCMs. I did use (for small test projects) monotone, darcs and arch. (I think all other alternatives aren't.)
Have you tried mercurial?
Nope. I've only used it's web frontend on http://www.kernel.org/hg/ .
Mercurial's author claims that it scales even better than git, esp. on its network transfer. However, I'm not aware how it scales there right now, since git got its "packs" implemented.
Quoted 4 lines
Quoted 2 lines
To get fixes/port updates/subsystem updates upstream to Linus, GIT is the way[tm] to go, so we'd try to get familiar with it.
Still using plain patches and email...
...which is a nice and actually working scheme, too. At least, it doesn't require to learn working with a new SCM :-P Though I think it's a good idea.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 1 line · Jan-Benedict Glaw
If you actually expect finite time answer, don't delete the cc list ...
Quoted 6 lines
monotone
Is quite nice'n'easy to use for CVS users, you'll have quite a fast start. The network sync protocol can be a bit lengthy at a time, but it works. It's acceptable in speed, but not exactly "fast". Written in C, code can easily be read and hacked.
Git has taken some ideas from Monotone.
Quoted 8 lines
darcs
Is easy to use, too, and quite some helpful. Network operations are a bit slower than those of monotone, but the real point is that it's merging algorithms are awfully slow. Also, it's written in Haskell (and getting a working compiler isn't exactly trivial), so the code is hard to read (for a C person), mostly because Haskell's concept are so different (it's a function programming language, after all.)
In my tests at the beginning of the year darcs's performance was undescribably low. The speedup factor needed to make it useful for any large project probably cannot be described in a floating point number.
Quoted 8 lines
arch
Arch can do almost everything; it's network sync protocol is quite fast (can use several transports and will make use of caches). However, it's not exactly easy to use because of it's thousands of commands and it's project name conventions are, um, ugly. It has very good merging capabilities, but it's heavy use of local caches forces you to have loads of free HDD space.
Git is a huge diskspace consumer also unless repositories are converted. For example, the Linux kernel repository from CVS did inflate itself to over 4GB and over 340,000 files. After packing I got that down to like 170MB. Not bad compared to the some 770MB of RCS files it's using currently and < 11s checkout from git can't be wrong either ;-)
Quoted 4 lines
SVN
Not distributed, easy to use. Though there's a different frontend with distribution capabilities. Personally, SVN feels like CVS with it's major conceptual problems fixed.
And plenty of reports about database corruption that are not terribly old so I'd feel uneasy to keep the crown jewels there.
Quoted 2 lines
To get fixes/port updates/subsystem updates upstream to Linus, GIT is the way[tm] to go, so we'd try to get familiar with it.
The other accepted currency of the trade are still simple patches, see
http://www.linux-mips.org/wiki/The_perfect_patch.
Ralf
Ralf Baechle wrote:
[snip]
Quoted 7 lines
Quoted 4 lines
SVN
Not distributed, easy to use. Though there's a different frontend with distribution capabilities. Personally, SVN feels like CVS with it's major conceptual problems fixed.And plenty of reports about database corruption that are not terribly old so I'd feel uneasy to keep the crown jewels there.
This was related to the underlying berkeleydb, the switch to fsfs fixed that. (SVN is used for several larger Debian projects like its Xfree86/XOrg tree, it holds up quite well there.)
Btw, there's also SVK which implements a distributed system on top of SVN. Some general comparision of the various SCMs:
http://linuxmafia.com/faq/Apps/scm.html
http://www.dwheeler.com/essays/scm.html
Thiemo
Quoted 9 lines · Ralf Baechle
Quoted 6 lines · Jan-Benedict Glaw
monotone
Is quite nice'n'easy to use for CVS users, you'll have quite a fast start. The network sync protocol can be a bit lengthy at a time, but it works. It's acceptable in speed, but not exactly "fast". Written in C, code can easily be read and hacked.Git has taken some ideas from Monotone.
Though monotone uses a (berkeley?) DB to store all objects...
Quoted 9 lines
Quoted 8 lines
arch
Arch can do almost everything; it's network sync protocol is quite fast (can use several transports and will make use of caches). However, it's not exactly easy to use because of it's thousands of commands and it's project name conventions are, um, ugly. It has very good merging capabilities, but it's heavy use of local caches forces you to have loads of free HDD space.
Quoted 5 lines
Git is a huge diskspace consumer also unless repositories are converted. For example, the Linux kernel repository from CVS did inflate itself to over 4GB and over 340,000 files. After packing I got that down to like 170MB. Not bad compared to the some 770MB of RCS files it's using currently and < 11s checkout from git can't be wrong either ;-)
Well, Arch *may* cache any tree version you check out. So take a source tree and check-out some 15 tree versions, you may end up with a really *hugh* cache. You're free to delete it, though...
Quoted 5 lines
Quoted 2 lines
To get fixes/port updates/subsystem updates upstream to Linus, GIT is the way[tm] to go, so we'd try to get familiar with it.
The other accepted currency of the trade are still simple patches, see
http://www.linux-mips.org/wiki/The_perfect_patch.
ACK. But unless you've got the perfect Patch Queue Manager that'll re-diff and re-send your patches automatically to Linus, you keep on doing some manual work or at least starting your scripts ever and ever again :)
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 9 lines · Jan-Benedict Glaw
Quoted 8 lines
Quoted 4 lines
To get fixes/port updates/subsystem updates upstream to Linus, GIT is the way[tm] to go, so we'd try to get familiar with it.
The other accepted currency of the trade are still simple patches, see
http://www.linux-mips.org/wiki/The_perfect_patch.
Quoted 7 lines
ACK. But unless you've got the perfect Patch Queue Manager that'll re-diff and re-send your patches automatically to Linus, you keep on doing some manual work or at least starting your scripts ever and ever again :)
Speaking of patch management, has anyone tried out Stacked GIT (aka StGIT, aka quilt on GIT) at http://www.procode.org/stgit/? It looks like it could be useful, and can be used in conjunction with other porcelain like Cogito.
Nigel
Ni Nigel!
Quoted 11 lines · Nigel Stephens
Quoted 9 lines · Jan-Benedict Glaw
Quoted 4 lines
Quoted 2 lines
To get fixes/port updates/subsystem updates upstream to Linus, GIT is the way[tm] to go, so we'd try to get familiar with it.
The other accepted currency of the trade are still simple patches, see
http://www.linux-mips.org/wiki/The_perfect_patch.ACK. But unless you've got the perfect Patch Queue Manager that'll re-diff and re-send your patches automatically to Linus, you keep on doing some manual work or at least starting your scripts ever and ever again :)
Quoted 4 lines
Speaking of patch management, has anyone tried out Stacked GIT (aka StGIT, aka quilt on GIT) at http://www.procode.org/stgit/? It looks like it could be useful, and can be used in conjunction with other porcelain like Cogito.
No, not yet, mostly due to time reasons. But I second it sounds useful.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Quoted 5 lines · In message <[email protected]> you wrote:
Which docs did you use to get yourself started? I'm also on the way getting familiar with GIT, doing my very first steps. It would be nice if we'd present what we know in Oldenburg (I already offered to do so, Joey planed it for Saturday).
I collected a bit of information, like postings from the git mailing list I found especially informative, at
http://source.denx.net/en/Documents/GitDocs
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] It is clear that the individual who persecutes a man, his brother, because he is not of the same opinion, is a monster. - Voltaire