* [ECOS] Re: Switching to using git on eCosForge
@ 2009-09-21 14:39 Alex Schuilenburg
2009-09-21 20:06 ` Sergei Organov
2009-09-21 22:08 ` [ECOS] Re: Switching to using git on eCosForge Sergei Gavrikov
0 siblings, 2 replies; 16+ messages in thread
From: Alex Schuilenburg @ 2009-09-21 14:39 UTC (permalink / raw)
To: eCos Disuss
[Apologies to sergei for repost - grrr]
Sergei Organov wrote on 2009-09-21 14:05:
> Alex Schuilenburg <alexs@ecoscentric.com> writes:
>
> [...]
>
>
>> Both bazaar and mercurial were a lot easier to learn and work with
>> than git. git's Windows support is also limited and is mostly
>> restricted to the 100's of cmd apps which make up git under cygwin.
>>
>
> Once again, I'm not a Windows user, but is this really true nowadays?
>
> E.g., what about this one:
>
> <http://code.google.com/p/tortoisegit/>
>
> Isn't it good enough for Windows users?
>
and hg has TortoiseHG <http://tortoisehg.sourceforge.net/>
(http://tortoisehg.sourceforge.net/). Like I said, feature comparison
between git and hg is pretty much on a par...
Lack of windows support/integration is not my main argument against git
FWIW.
My main argument against git is it has a very steep initial learning
curve, and from experience you can hang yourself if you do not know what
you are doing. (Yes, there are rollbacks, etc, but sometimes it is a
while down the line before you realise you did something wrong). You
really don't want to force new users on an additional learning curve.
There are 100's of commands to remember, whereas both bzr and hg have one.
Also, while documentation is improving (http://book.git-scm.com/), it is
not as good or complete as mercurial (http://hgbook.red-bean.com/read/)
in terms of non-power users. Both have books in print available from
places like Amazon.
For example, I started my evaluation with bzr, then hg then git. bzr and
hg were a lot easiest to pick up and start using than git. I also have
done most of my eval on Linux, dropping back to Windows to see how easy
it was to use and integrate graphical diff tools, etc.
For other comparisons see:
http://code.google.com/p/support/wiki/DVCSAnalysis
http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands
http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29
...
but bear in mind that arguments against either git or hg may have
disappeared with more recent versions. You really need to try both...
-- Alex Schuilenburg
>>>> Visit us at ESC-Boston http://www.embedded.com/esc/boston <<<<
>>>> Sep 22-23 on Stand 226 at Hynes Convention Center, Boston <<<<
>>>> Visit us at ESC-UK http://www.embedded.co.uk <<<<
>>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Switching to using git on eCosForge 2009-09-21 14:39 [ECOS] Re: Switching to using git on eCosForge Alex Schuilenburg @ 2009-09-21 20:06 ` Sergei Organov 2009-09-21 22:41 ` Alex Schuilenburg 2009-09-21 22:08 ` [ECOS] Re: Switching to using git on eCosForge Sergei Gavrikov 1 sibling, 1 reply; 16+ messages in thread From: Sergei Organov @ 2009-09-21 20:06 UTC (permalink / raw) To: ecos-discuss Alex Schuilenburg <alexs@ecoscentric.com> writes: [...] > My main argument against git is it has a very steep initial learning > curve, Really? Not in my experience. IMHO, those 3 we discuss are roughly the same, just having raw corners in different places. E.g., there is even a table of commands equivalence between hg and git somewhere. > and from experience you can hang yourself if you do not know what > you are doing. (Yes, there are rollbacks, etc, but sometimes it is a > while down the line before you realise you did something wrong). It's a very nice thing with git that it's virtually impossible to loose your work as soon as you committed it to git, really, even if you keep doing something wrong. Even though nowadays git does automatically run garbage collection, the reflog feature still keeps all unreferenced data intact for rather long time. > You really don't want to force new users on an additional learning > curve. There are 100's of commands to remember, whereas both bzr and > hg have one. Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only one as well: 'git' ;-) One does need additional learning curve switching from CVS to any of DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again, with git you can have gitcvsserver running to keep "CVS forever" users happy with their favorite clients. > Also, while documentation is improving (http://book.git-scm.com/), it is > not as good or complete as mercurial (http://hgbook.red-bean.com/read/) > in terms of non-power users. Both have books in print available from > places like Amazon. For me git's documentation was more than enough to have a quick-start. > > For example, I started my evaluation with bzr, then hg then git. bzr and > hg were a lot easiest to pick up and start using than git. I wonder, do you remember what the problem(s) with git was (were)? Care to give an example where git is harder than any of the other two? > I also have done most of my eval on Linux, dropping back to Windows to > see how easy it was to use and integrate graphical diff tools, etc. > > For other comparisons see: > http://code.google.com/p/support/wiki/DVCSAnalysis > http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ > http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ > http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands > http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/ > http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29 > ... > > but bear in mind that arguments against either git or hg may have > disappeared with more recent versions. You really need to try both... Yes, all 3 are improving and do borrow from each other. However, in my opinion, git is preferred in the long run as it has very clear, simple yet powerful model in its core, when hg already outlived its initial simple design model based on "every branch is a separate repository" idea (now it has 3(!) different kinds of branches), and bzr is being built from use-cases down (see how many times they have already changed format of repository). Yes, sure, me could be entirely wrong ;-) -- Sergei. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-21 20:06 ` Sergei Organov @ 2009-09-21 22:41 ` Alex Schuilenburg 2009-09-22 6:28 ` [ECOS] JFFS2 Or Compiler Issue Ramgopal Kota ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Alex Schuilenburg @ 2009-09-21 22:41 UTC (permalink / raw) To: Sergei Organov; +Cc: ecos-discuss Sergei Organov wrote: > Alex Schuilenburg <alexs@ecoscentric.com> writes: > [...] > >> My main argument against git is it has a very steep initial learning >> curve, >> > Really? Not in my experience. Yes, really, and not only my experience either. I guess I must be below the curve on learning new technology, but then it could also be my age ;-) > IMHO, those 3 we discuss are roughly the > same, just having raw corners in different places. E.g., there is even a > table of commands equivalence between hg and git somewhere. > Several places actually. And yes, functionality on each is roughly the same. > >> and from experience you can hang yourself if you do not know what >> you are doing. (Yes, there are rollbacks, etc, but sometimes it is a >> while down the line before you realise you did something wrong). >> > > It's a very nice thing with git that it's virtually impossible to loose > your work as soon as you committed it to git, really, even if you keep > doing something wrong. Even though nowadays git does automatically run > garbage collection, the reflog feature still keeps all unreferenced data > intact for rather long time. > > And yes, functionality on each is roughly the same. I think we should stop going round in circles. We appear to agree all three have similar functionality. If you want a contest on which is the most powerful, I will save you the trouble. git is currently the most powerful. If you want an example of a powerful feature git has that is harder to do in the others, let me save you the trouble again: git commit --amend (in hg if the commit is buried you will need to have been using queues and will have to export changesets, fix and re-import - more painful, but achievable). However, I would point out again that all three borrow from the others, so evaluating is always going to be a moving target. >> You really don't want to force new users on an additional learning >> curve. There are 100's of commands to remember, whereas both bzr and >> hg have one. >> > > Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only > one as well: 'git' ;-) > > One does need additional learning curve switching from CVS to any of > DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again, > with git you can have gitcvsserver running to keep "CVS forever" > users happy with their favorite clients. > % ls -l /usr/bin/git-* | wc -l 136 % and I only have git-core installed on that machine... FWIW I already had come upto speed with DRCS with bzr and hg before I played with git. Figuring out which command to use to do a specific task without resorting to a manual was my initial stumbling block - I just initially felt somewhat overwhelmed. bzr and hg seemed easier to pick up and start using where with git I was never quite sure if I was using the correct options. Too many bells and whistles I guess which was compounded by not easily being able to find pointers to assure me I was doing the right thing. Hence I never quite felt comfortable using git in the beginning. But of course this is a subjective opinion - YMMV. >> Also, while documentation is improving (http://book.git-scm.com/), it is >> not as good or complete as mercurial (http://hgbook.red-bean.com/read/) >> in terms of non-power users. Both have books in print available from >> places like Amazon. >> > > For me git's documentation was more than enough to have a quick-start. > > >> For example, I started my evaluation with bzr, then hg then git. bzr and >> hg were a lot easiest to pick up and start using than git. >> > > I wonder, do you remember what the problem(s) with git was (were)? Care > to give an example where git is harder than any of the other two? > I never said I had problems doing things in git - I said I had problems finding out how to do them. Tell me with a straight face that the number of options in some of the git commands did not overwhelm you the first time you saw them? When you want to encourage community development, you really need to keep it simple for developers to keep abreast of advances and contribute back. Not have so many bells and whistles that they feel like they should not touch anything in case it breaks, or worse, have someone who thinks they know what they are doing but does not. > >> I also have done most of my eval on Linux, dropping back to Windows to >> see how easy it was to use and integrate graphical diff tools, etc. >> >> For other comparisons see: >> http://code.google.com/p/support/wiki/DVCSAnalysis >> http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ >> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ >> http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands >> http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/ >> http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29 >> ... >> >> but bear in mind that arguments against either git or hg may have >> disappeared with more recent versions. You really need to try both... >> > > Yes, all 3 are improving and do borrow from each other. However, in my > opinion, git is preferred in the long run as it has very clear, simple > yet powerful model in its core, when hg already outlived its initial > simple design model based on "every branch is a separate repository" > idea (now it has 3(!) different kinds of branches), and bzr is being > built from use-cases down (see how many times they have already changed > format of repository). Yes, sure, me could be entirely wrong ;-) > Not entirely wrong ;-) When working with branches ever run "git submodule update" when you've made and committed changes within a submodule without checking out the branch first, only to discover later that the changes were silently overwritten? However, I strongly disagree with your comment "hg already outlived its initial simple design..." though. hg's design is just as simple as git and there is nothing in hg's design IMHO that limits what it can do. It is still evolving, just like git and eCos. The forests extension has been around just as long as sub-modules AFAIKT, but I admit it is taking a while for hg to make it part of their core functionality. I am sure we can equally find flaws in the others preferred DRCS just as we can find features... And defintely yes, all three borrow from each other, even documentation in the case of git ;-) http://cworth.org/hgbook-git/tour/). But IMHO hg still has stronger documentation and is easier for newcomers to start with. Anyway, it is good to have an alternative view on what the best choice of DRCS for eCos is. I guess you and I can agree to disagree on what that choice should be though, and let others tell us what they think ;-) -- Alex Schuilenburg >>>> Visit us at ESC-Boston http://www.embedded.com/esc/boston <<<< >>>> Sep 22-23 on Stand 226 at Hynes Convention Center, Boston <<<< >>>> Visit us at ESC-UK http://www.embedded.co.uk <<<< >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<< -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] JFFS2 Or Compiler Issue. 2009-09-21 22:41 ` Alex Schuilenburg @ 2009-09-22 6:28 ` Ramgopal Kota 2009-09-22 9:55 ` [ECOS] Re: Switching to using git on eCosForge Peter Korsgaard ` (2 subsequent siblings) 3 siblings, 0 replies; 16+ messages in thread From: Ramgopal Kota @ 2009-09-22 6:28 UTC (permalink / raw) To: eCos Discussion [-- Attachment #1: Type: text/plain, Size: 9113 bytes --] Hi, I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue. In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below struct jffs2_unknown_node marker = { .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), .totlen = cpu_to_je32(c->cleanmarker_size) }; struct jffs2_unknown_node { /* All start like this */ jint16_t magic; jint16_t nodetype; jint32_t totlen; /* So we can skip over nodes we don't grok */ jint32_t hdr_crc; } __attribute__((packed)); I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER. If I change the code to the following it is working fine... struct jffs2_unknown_node marker = { .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), .totlen = cpu_to_je32(c->cleanmarker_size) }; marker.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK); I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag. I am attaching the specs for the compiler I am using. Compiler I am using is gcc version 3.2.1 (eCosCentric) Thanks & Regards, Ramgopal Kota -----Original Message----- From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Alex Schuilenburg Sent: Tuesday, September 22, 2009 4:12 AM To: Sergei Organov Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Re: Switching to using git on eCosForge Sergei Organov wrote: > Alex Schuilenburg <alexs@ecoscentric.com> writes: > [...] > >> My main argument against git is it has a very steep initial learning >> curve, >> > Really? Not in my experience. Yes, really, and not only my experience either. I guess I must be below the curve on learning new technology, but then it could also be my age ;-) > IMHO, those 3 we discuss are roughly the > same, just having raw corners in different places. E.g., there is even a > table of commands equivalence between hg and git somewhere. > Several places actually. And yes, functionality on each is roughly the same. > >> and from experience you can hang yourself if you do not know what >> you are doing. (Yes, there are rollbacks, etc, but sometimes it is a >> while down the line before you realise you did something wrong). >> > > It's a very nice thing with git that it's virtually impossible to loose > your work as soon as you committed it to git, really, even if you keep > doing something wrong. Even though nowadays git does automatically run > garbage collection, the reflog feature still keeps all unreferenced data > intact for rather long time. > > And yes, functionality on each is roughly the same. I think we should stop going round in circles. We appear to agree all three have similar functionality. If you want a contest on which is the most powerful, I will save you the trouble. git is currently the most powerful. If you want an example of a powerful feature git has that is harder to do in the others, let me save you the trouble again: git commit --amend (in hg if the commit is buried you will need to have been using queues and will have to export changesets, fix and re-import - more painful, but achievable). However, I would point out again that all three borrow from the others, so evaluating is always going to be a moving target. >> You really don't want to force new users on an additional learning >> curve. There are 100's of commands to remember, whereas both bzr and >> hg have one. >> > > Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only > one as well: 'git' ;-) > > One does need additional learning curve switching from CVS to any of > DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again, > with git you can have gitcvsserver running to keep "CVS forever" > users happy with their favorite clients. > % ls -l /usr/bin/git-* | wc -l 136 % and I only have git-core installed on that machine... FWIW I already had come upto speed with DRCS with bzr and hg before I played with git. Figuring out which command to use to do a specific task without resorting to a manual was my initial stumbling block - I just initially felt somewhat overwhelmed. bzr and hg seemed easier to pick up and start using where with git I was never quite sure if I was using the correct options. Too many bells and whistles I guess which was compounded by not easily being able to find pointers to assure me I was doing the right thing. Hence I never quite felt comfortable using git in the beginning. But of course this is a subjective opinion - YMMV. >> Also, while documentation is improving (http://book.git-scm.com/), it is >> not as good or complete as mercurial (http://hgbook.red-bean.com/read/) >> in terms of non-power users. Both have books in print available from >> places like Amazon. >> > > For me git's documentation was more than enough to have a quick-start. > > >> For example, I started my evaluation with bzr, then hg then git. bzr and >> hg were a lot easiest to pick up and start using than git. >> > > I wonder, do you remember what the problem(s) with git was (were)? Care > to give an example where git is harder than any of the other two? > I never said I had problems doing things in git - I said I had problems finding out how to do them. Tell me with a straight face that the number of options in some of the git commands did not overwhelm you the first time you saw them? When you want to encourage community development, you really need to keep it simple for developers to keep abreast of advances and contribute back. Not have so many bells and whistles that they feel like they should not touch anything in case it breaks, or worse, have someone who thinks they know what they are doing but does not. > >> I also have done most of my eval on Linux, dropping back to Windows to >> see how easy it was to use and integrate graphical diff tools, etc. >> >> For other comparisons see: >> http://code.google.com/p/support/wiki/DVCSAnalysis >> http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ >> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ >> http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands >> http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/ >> http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29 >> ... >> >> but bear in mind that arguments against either git or hg may have >> disappeared with more recent versions. You really need to try both... >> > > Yes, all 3 are improving and do borrow from each other. However, in my > opinion, git is preferred in the long run as it has very clear, simple > yet powerful model in its core, when hg already outlived its initial > simple design model based on "every branch is a separate repository" > idea (now it has 3(!) different kinds of branches), and bzr is being > built from use-cases down (see how many times they have already changed > format of repository). Yes, sure, me could be entirely wrong ;-) > Not entirely wrong ;-) When working with branches ever run "git submodule update" when you've made and committed changes within a submodule without checking out the branch first, only to discover later that the changes were silently overwritten? However, I strongly disagree with your comment "hg already outlived its initial simple design..." though. hg's design is just as simple as git and there is nothing in hg's design IMHO that limits what it can do. It is still evolving, just like git and eCos. The forests extension has been around just as long as sub-modules AFAIKT, but I admit it is taking a while for hg to make it part of their core functionality. I am sure we can equally find flaws in the others preferred DRCS just as we can find features... And defintely yes, all three borrow from each other, even documentation in the case of git ;-) http://cworth.org/hgbook-git/tour/). But IMHO hg still has stronger documentation and is easier for newcomers to start with. Anyway, it is good to have an alternative view on what the best choice of DRCS for eCos is. I guess you and I can agree to disagree on what that choice should be though, and let others tell us what they think ;-) -- Alex Schuilenburg >>>> Visit us at ESC-Boston http://www.embedded.com/esc/boston <<<< >>>> Sep 22-23 on Stand 226 at Hynes Convention Center, Boston <<<< >>>> Visit us at ESC-UK http://www.embedded.co.uk <<<< >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<< -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss [-- Attachment #2: 1.txt --] [-- Type: text/plain, Size: 8342 bytes --] *asm: %{G*} %{EB} %{EL} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32} %{mips64}%{mips16:%{!mno-mips16:-mips16}} %{mno-mips16:-no-mips16} %(subtarget_asm_optimizing_spec) %(subtarget_asm_debugging_spec) %{membedded-pic} %{mabi=32:-32}%{mabi=o32:-32}%{mabi=n32:-n32}%{mabi=64:-64}%{mabi=n64:-64} %(target_asm_spec) %(subtarget_asm_spec) *asm_debug: %{gdwarf-2*:--gdwarf2}%{!gdwarf-2*:%{g*:--gstabs}} *asm_final: %{mmips-as: %{!mno-mips-tfile: mips-tfile %{v*: -v} %{K: -I %b.o~} %{!K: %{save-temps: -I %b.o~}} %{c:%W{o*}%{!o*:-o %b.o}}%{!c:-o %U.o} %{.s:%i} %{!.s:%g.s}}} *asm_options: %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O} *invoke_as: %{!S:-o %{|!pipe:%g.s} | as %(asm_options) %{!pipe:%g.s} %A } *cpp: %{.m: -D__LANGUAGE_OBJECTIVE_C -D_LANGUAGE_OBJECTIVE_C -D__LANGUAGE_C -D_LANGUAGE_C} %{.S|.s: -D__LANGUAGE_ASSEMBLY -D_LANGUAGE_ASSEMBLY %{!ansi:-DLANGUAGE_ASSEMBLY}} %{!.S: %{!.s: %{!.cc: %{!.cxx: %{!.cpp: %{!.cp: %{!.c++: %{!.C: %{!.m: -D__LANGUAGE_C -D_LANGUAGE_C %{!ansi:-DLANGUAGE_C}}}}}}}}}} %(subtarget_cpp_size_spec) %{mips3:-U__mips -D__mips=3 -D__mips64} %{mips4:-U__mips -D__mips=4 -D__mips64} %{mips32:-U__mips -D__mips=32} %{mips64:-U__mips -D__mips=64 -D__mips64} %{mgp32:-U__mips64} %{mgp64:-D__mips64} %{mfp32:-D__mips_fpr=32} %{mfp64:-D__mips_fpr=64} %{!mfp32: %{!mfp64: %{mgp32:-D__mips_fpr=32} %{!mgp32: %(cpp_fpr_spec)}}} %{msingle-float:%{!msoft-float:-D__mips_single_float}} %{m4650:%{!msoft-float:-D__mips_single_float}} %{msoft-float:-D__mips_soft_float} %{mabi=eabi:-D__mips_eabi} %{mips16:%{!mno-mips16:-D__mips16}} %{EB:-UMIPSEL -U_MIPSEL -U__MIPSEL -U__MIPSEL__ -D_MIPSEB -D__MIPSEB -D__MIPSEB__ %{!ansi:-DMIPSEB}} %{EL:-UMIPSEB -U_MIPSEB -U__MIPSEB -U__MIPSEB__ -D_MIPSEL -D__MIPSEL -D__MIPSEL__ %{!ansi:-DMIPSEL}} %(long_max_spec) %(subtarget_cpp_spec) *cpp_options: %(cpp_unique_options) %{std*} %{d*} %{W*} %{w} %{pedantic*} %{fshow-column} %{fno-show-column} %{fsigned-char&funsigned-char} %{fleading-underscore} %{fno-leading-underscore} %{fno-operator-names} %{ftabstop=*} *cpp_unique_options: %{C:%{!E:%eGNU C does not support -C without using -E}} %{nostdinc*} %{C} %{v} %{I*} %{P} %{$} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*}}}}} %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2 -D__GNUC_PATCHLEVEL__=%v3 -D__GXX_ABI_VERSION=102} %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs} %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}} %{fno-inline|O0|!O*:-D__NO_INLINE__} %{ffast-math:-D__FAST_MATH__} %{fshort-wchar:-U__WCHAR_TYPE__ -D__WCHAR_TYPE__=short\ unsigned\ int} %{ffreestanding:-D__STDC_HOSTED__=0} %{fno-hosted:-D__STDC_HOSTED__=0} %{!ffreestanding:%{!fno-hosted:-D__STDC_HOSTED__=1}} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{E|M|MM:%W{o*}} *trad_capable_cpp: %{traditional|ftraditional|traditional-cpp:trad}cpp0 *cc1: %{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1}}}}} %{mips1:-mfp32 -mgp32} %{mips2:-mfp32 -mgp32}%{mips3:%{!msingle-float:%{!m4650:-mfp64}} -mgp64} %{mips4:%{!msingle-float:%{!m4650:-mfp64}} -mgp64} %{mips32:-mfp32 -mgp32} %{mips64:%{!msingle-float:%{!m4650:-mfp64}} -mgp64} %{mfp64:%{msingle-float:%emay not use both -mfp64 and -msingle-float}} %{mfp64:%{m4650:%emay not use both -mfp64 and -m4650}} %{mint64|mlong64|mlong32:-mexplicit-type-size }%{mgp32: %{mfp64:%emay not use both -mgp32 and -mfp64} %{!mfp32: -mfp32}} %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} %{pic-none: -mno-half-pic} %{pic-lib: -mhalf-pic} %{pic-extern: -mhalf-pic} %{pic-calls: -mhalf-pic} %{save-temps: } %(subtarget_cc1_spec) %(cc1_cpu_spec) *cc1_options: %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} %{g*} %{O*} %{W*} %{w} %{pedantic*} %{std*} %{ansi} %{traditional} %{v:-version} %{pg:-p} %{p} %{f*} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} *cc1plus: *link_gcc_c_sequence: %G %L %G *endfile: crtend%O%s crtn%O%s *link: %(endian_spec) %{G*} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32} %{mips64} %{bestGnum} %{shared} %{non_shared} *lib: *libgcc: -lgcc *startfile: crti%O%s crtbegin%O%s %{!mno-crt0: } *switches_need_spaces: *predefines: -Dmips -DMIPSEB -DR3000 -D_mips -D_MIPSEB -D_R3000 *cross_compile: 1 *version: 3.2.1 *multilib: . !msoft-float !EL !EB !mips32 !mips64;soft-float msoft-float !EL !EB !mips32 !mips64;el !msoft-float EL !EB !mips32 !mips64;eb !msoft-float !EL EB !mips32 !mips64;mips32 !msoft-float !EL !EB mips32 !mips64;mips64 !msoft-float !EL !EB !mips32 mips64;el/mips32 !msoft-float EL !EB mips32 !mips64;el/mips64 !msoft-float EL !EB !mips32 mips64;eb/mips32 !msoft-float !EL EB mips32 !mips64;eb/mips64 !msoft-float !EL EB !mips32 mips64;soft-float/el msoft-float EL !EB !mips32 !mips64;soft-float/eb msoft-float !EL EB !mips32 !mips64;soft-float/mips32 msoft-float !EL !EB mips32 !mips64;soft-float/mips64 msoft-float !EL !EB !mips32 mips64;soft-float/el/mips32 msoft-float EL !EB mips32 !mips64;soft-float/el/mips64 msoft-float EL !EB !mips32 mips64;soft-float/eb/mips32 msoft-float !EL EB mips32 !mips64;soft-float/eb/mips64 msoft-float !EL EB !mips32 mips64; *multilib_defaults: EB mips32 *multilib_extra: *multilib_matches: msoft-float msoft-float;EL EL;EB EB;mips32 mips32;mips64 mips64; *multilib_exclusions: *multilib_options: msoft-float EL/EB mips32/mips64 *linker: collect2 *link_libgcc: %D *md_exec_prefix: *md_startfile_prefix: *md_startfile_prefix_1: *subtarget_cc1_spec: *cc1_cpu_spec: %{!mcpu*: %{m3900:-march=r3900 -mips1 -mfp32 -mgp32 %n`-m3900' is deprecated. Use `-march=r3900' instead. } %{m4650:-march=r4650 -mmad -msingle-float %n`-m4650' is deprecated. Use `-march=r4650' instead. }} *subtarget_cpp_spec: *subtarget_cpp_size_spec: %{mabi=eabi: %{mips1|mips2|mips32|mlong32|mgp32:%{!mips3:%{!mips4:%{!mips5:%{!mips64:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}}}}} %{mlong64: %{mgp64:-D__SIZE_TYPE__=long\ unsigned\ int -D__PTRDIFF_TYPE__=long\ int} %{!mgp64:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}} %{mips3|mips4|mips5|mips64:-D__SIZE_TYPE__=long\ unsigned\ int -D__PTRDIFF_TYPE__=long\ int}} %{!mips1:%{!mips2:%{!mips3:%{!mips4:%{!mips5:%{!mips32:%{!mips64:%{!mlong32:%{!mlong64:%{!mgp32:%{!mgp64:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}}}}}}}}}}}%{mabi=o64: %{mlong64: %{!mgp32:-D__SIZE_TYPE__=long\ unsigned\ int -D__PTRDIFF_TYPE__=long\ int} %{mgp32:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}} %{!mlong64:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}} %{mabi=32:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int}%{mabi=meabi|!mabi=*:-D__SIZE_TYPE__=unsigned\ int -D__PTRDIFF_TYPE__=int} *long_max_spec: %{mabi=64:-D__LONG_MAX__=9223372036854775807L} %{mlong64:-D__LONG_MAX__=9223372036854775807L} %{mgp64:-D__LONG_MAX__=9223372036854775807L} *cpp_fpr_spec: -D__mips_fpr=32 *mips_as_asm_spec: %{!.s:-nocpp} %{.s: %{cpp} %{nocpp}} %{pipe: %e-pipe is not supported} %{K} %(subtarget_mips_as_asm_spec) *gas_asm_spec: %{march=*} %{mtune=*} %{mcpu=*} %{m4650} %{mmad:-m4650} %{m3900} %{v} %{mgp32} %{mgp64} %(abi_gas_asm_spec) %{mabi=32:%{!mips*:-mips1}} *abi_gas_asm_spec: *target_asm_spec: %{mmips-as: %(mips_as_asm_spec)} %{!mmips-as: %(gas_asm_spec)} *subtarget_mips_as_asm_spec: %{v} *subtarget_asm_optimizing_spec: %{noasmopt:-O0} %{!noasmopt:%{O:-O2} %{O1:-O2} %{O2:-O2} %{O3:-O3}} *subtarget_asm_debugging_spec: %{g} %{g0} %{g1} %{g2} %{g3} %{ggdb:-g} %{ggdb0:-g0} %{ggdb1:-g1} %{ggdb2:-g2} %{ggdb3:-g3} %{gstabs:-g} %{gstabs0:-g0} %{gstabs1:-g1} %{gstabs2:-g2} %{gstabs3:-g3} %{gstabs+:-g} %{gstabs+0:-g0} %{gstabs+1:-g1} %{gstabs+2:-g2} %{gstabs+3:-g3} %{gcoff:-g} %{gcoff0:-g0} %{gcoff1:-g1} %{gcoff2:-g2} %{gcoff3:-g3} *subtarget_asm_spec: *endian_spec: %{!EL:%{!mel:-EB}} %{EL|mel:-EL} *link_command: %{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}} [-- Attachment #3: Type: text/plain, Size: 148 bytes --] -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-21 22:41 ` Alex Schuilenburg 2009-09-22 6:28 ` [ECOS] JFFS2 Or Compiler Issue Ramgopal Kota @ 2009-09-22 9:55 ` Peter Korsgaard 2009-09-22 11:08 ` Alex Schuilenburg 2009-09-22 12:21 ` Sergei Organov 2009-09-22 17:03 ` [ECOS] JFFS2 Issue Ramgopal Kota 3 siblings, 1 reply; 16+ messages in thread From: Peter Korsgaard @ 2009-09-22 9:55 UTC (permalink / raw) To: ecos-discuss >>>>> "AS" == Alex Schuilenburg <alexs@ecoscentric.com> writes: Hi, AS> % ls -l /usr/bin/git-* | wc -l AS> 136 AS> % That hasn't been the situation since git 1.6.0, released 13 months ago. When evaluating something as fast moving as DVCS'es, please use the latest stable release of the tools. -- Bye, Peter Korsgaard -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-22 9:55 ` [ECOS] Re: Switching to using git on eCosForge Peter Korsgaard @ 2009-09-22 11:08 ` Alex Schuilenburg 2009-09-22 11:21 ` Sergei Gavrikov 2009-09-22 11:38 ` Peter Korsgaard 0 siblings, 2 replies; 16+ messages in thread From: Alex Schuilenburg @ 2009-09-22 11:08 UTC (permalink / raw) To: Peter Korsgaard; +Cc: ecos-discuss Peter Korsgaard wrote on 2009-09-22 10:55: >>>>>> "AS" == Alex Schuilenburg <alexs@ecoscentric.com> writes: >>>>>> > > Hi, > > AS> % ls -l /usr/bin/git-* | wc -l > AS> 136 > AS> % > > That hasn't been the situation since git 1.6.0, released 13 months > ago. When evaluating something as fast moving as DVCS'es, please use > the latest stable release of the tools. > Ah, for 1.6.x you mean # ls -l /usr/libexec/git-core | wc -l 132 # ls -l /usr/bin/git* | wc -l 4 # You can run but you cannot hide ;-) I think if we are going to switch sooner rather than later you need to evaluate what is available pre-packaged from whatever distro or OS provider. i.e. what the regular users are going to be able to access easily without having to upgrade their system or build the tools themselves. Don't get me wrong, git is great and all empowering. But IMHO that is the problem - there is enough rope to hang yourself. For example, consider the following subtlety: "If you are staging an updated submodule for commit manually, be careful to not add a trailing slash when specifying the path. With the slash appended, Git will assume you are removing the submodule and checking that directory's contents into the containing repository." A trailing slash is what my bash completion puts in my path and is likely to be *my* default behaviour. IMHO that is broken, but I am sure someone in git-land thinks it makes perfect sense and is perfectly acceptable behaviour. If I was a git expert, maybe I would too. But the average Joe is not and not likely to want to be one. We are not talking here what is the most superior DRCS, we are talking what is the most suitable for eCos. You don't need a 10lb hammer to crack a nut. -- Alex Schuilenburg >>>> Visit us at ESC-Boston http://www.embedded.com/esc/boston <<<< >>>> Sep 22-23 on Stand 226 at Hynes Convention Center, Boston <<<< >>>> Visit us at ESC-UK http://www.embedded.co.uk <<<< >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<< -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-22 11:08 ` Alex Schuilenburg @ 2009-09-22 11:21 ` Sergei Gavrikov 2009-09-22 11:41 ` Edgar Grimberg 2009-09-22 11:52 ` Alex Schuilenburg 2009-09-22 11:38 ` Peter Korsgaard 1 sibling, 2 replies; 16+ messages in thread From: Sergei Gavrikov @ 2009-09-22 11:21 UTC (permalink / raw) To: Alex Schuilenburg; +Cc: Peter Korsgaard, ecos-discuss On Tue, Sep 22, 2009 at 12:08:17PM +0100, Alex Schuilenburg wrote: > Peter Korsgaard wrote on 2009-09-22 10:55: > >>>>>> "AS" == Alex Schuilenburg <alexs@ecoscentric.com> writes: > >>>>>> > > > > Hi, > > > > AS> % ls -l /usr/bin/git-* | wc -l > > AS> 136 > > AS> % > > > > That hasn't been the situation since git 1.6.0, released 13 months > > ago. When evaluating something as fast moving as DVCS'es, please use > > the latest stable release of the tools. > > > Ah, for 1.6.x you mean > # ls -l /usr/libexec/git-core | wc -l > 132 > # ls -l /usr/bin/git* | wc -l > 4 > # > > You can run but you cannot hide ;-) Ah, that's poor-poor busybox :-) and what do you think about Easy Git? Would you like observe these, please? http://www.gnome.org/~newren/eg/ http://www.gnome.org/~newren/eg/documentation/ Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-22 11:21 ` Sergei Gavrikov @ 2009-09-22 11:41 ` Edgar Grimberg 2009-09-22 17:29 ` Ilija Kocho 2009-09-22 11:52 ` Alex Schuilenburg 1 sibling, 1 reply; 16+ messages in thread From: Edgar Grimberg @ 2009-09-22 11:41 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: Alex Schuilenburg, Peter Korsgaard, ecos-discuss Hi, My 2 cents on the topic: * eCos maintainers need to follow up on patches and bugs. The kernel and other "common" areas should have priority over specific HALs. This is a place where things must go without any hiccups. I've been around the office when Oyvind found the sscanf bug. Imagine the frustration finding a 2 years old patch just rotting out there... Maybe a clear procedure must be written and published. Something like in the emergency rooms: sever bugs - one day to commit, normal bugs in common areas - 3 days to commit, normal bugs in HAL - 7 days to commit, silly problems - 14 days to commit. * no matter what source control to use, it is a must to be easy for the maintainers to use it. The regular users will be able, with a command described somewhere on the web, to get all the sources. The "super-"users to send patches will able to find a way to do so no matter what source control system will be chosen (also a command or two on the webpages can help a lot in that regard). Regards, Edgar -- Edgar Grimberg System Developer Zylin AS ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html Phone: (+47) 51 63 25 00 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-22 11:41 ` Edgar Grimberg @ 2009-09-22 17:29 ` Ilija Kocho 0 siblings, 0 replies; 16+ messages in thread From: Ilija Kocho @ 2009-09-22 17:29 UTC (permalink / raw) To: ecos-discuss Edgar Grimberg wrote: > Hi, > > My 2 cents on the topic: > and another one from me > * no matter what source control to use, it is a must to be easy for > the maintainers to use it. The regular users will be able, with a > command described somewhere on the web, to get all the sources. I agree with this. Maintainers' time is valuable to all of us. I have no preference over any of the 3 options, but I can note that almost all discussion is between git and hg, so as a fist step we can narrow choice between these two. Then, when emergency comes, we can throw a coin instead of dice. Regards Ilija -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-22 11:21 ` Sergei Gavrikov 2009-09-22 11:41 ` Edgar Grimberg @ 2009-09-22 11:52 ` Alex Schuilenburg 1 sibling, 0 replies; 16+ messages in thread From: Alex Schuilenburg @ 2009-09-22 11:52 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-discuss Sergei Gavrikov wrote on 2009-09-22 12:24: > [...] > and what do you think about Easy Git? Would you like observe these, > please? > > http://www.gnome.org/~newren/eg/ > http://www.gnome.org/~newren/eg/documentation/ > > Looks great and certainly helps simplify things. It's perl, so should run on most systems, but how well does it really run on Windows (cygwin or native perl) ;-) /me ducks and runs -- Alex Schuilenburg >>>> Visit us at ESC-Boston http://www.embedded.com/esc/boston <<<< >>>> Sep 22-23 on Stand 226 at Hynes Convention Center, Boston <<<< >>>> Visit us at ESC-UK http://www.embedded.co.uk <<<< >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<< -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-22 11:08 ` Alex Schuilenburg 2009-09-22 11:21 ` Sergei Gavrikov @ 2009-09-22 11:38 ` Peter Korsgaard 1 sibling, 0 replies; 16+ messages in thread From: Peter Korsgaard @ 2009-09-22 11:38 UTC (permalink / raw) To: ecos-discuss >>>>> "AS" == Alex Schuilenburg <alexs@ecoscentric.com> writes: Hi, AS> Ah, for 1.6.x you mean AS> # ls -l /usr/libexec/git-core | wc -l AS> 132 AS> # ls -l /usr/bin/git* | wc -l AS> 4 AS> # AS> You can run but you cannot hide ;-) But that's an implementation detail. I as a user don't care if the various git subcommands are implemented in seperate binaries or a single multi-function binary. Again, the working set (E.G. common commands) are pretty similar: svn help|wc -l 47 git help|wc -l 26 hg help|wc -l 67 -- Bye, Peter Korsgaard -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-21 22:41 ` Alex Schuilenburg 2009-09-22 6:28 ` [ECOS] JFFS2 Or Compiler Issue Ramgopal Kota 2009-09-22 9:55 ` [ECOS] Re: Switching to using git on eCosForge Peter Korsgaard @ 2009-09-22 12:21 ` Sergei Organov 2009-09-22 17:03 ` [ECOS] JFFS2 Issue Ramgopal Kota 3 siblings, 0 replies; 16+ messages in thread From: Sergei Organov @ 2009-09-22 12:21 UTC (permalink / raw) To: ecos-discuss Alex Schuilenburg <alexs@ecoscentric.com> writes: > Sergei Organov wrote: >> Alex Schuilenburg <alexs@ecoscentric.com> writes: >> [...] [...] > However, I would point out again that all three borrow from the others, > so evaluating is always going to be a moving target. >>> You really don't want to force new users on an additional learning >>> curve. There are 100's of commands to remember, whereas both bzr and >>> hg have one. >> >> Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only >> one as well: 'git' ;-) >> >> One does need additional learning curve switching from CVS to any of >> DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again, >> with git you can have gitcvsserver running to keep "CVS forever" >> users happy with their favorite clients. >> > % ls -l /usr/bin/git-* | wc -l > 136 > % > > and I only have git-core installed on that machine... You shouldn't be running them directly, and anyway now it is already addressed: $ git --version git version 1.6.4.2.254.g99ccf $ which git ~/git/bin/git $ ls ~/git/bin git git-receive-pack git-upload-archive gitk git-cvsserver git-shell git-upload-pack $ Most of the 'git-*' are now hidden in an out-of-your-path directory. What I actually wanted to point out is that it was unfair to say that git has hundreds of commands to remember whereas both bzr and hg have one. The fact that one was allowed to say 'git-COMMAND' instead of 'git COMMAND' does not in fact make number of commands different. I suspect one needs to remember roughly the same amount of commands to perform similar operations no matter which DVCS of the above is in use. [...] >>> Also, while documentation is improving (http://book.git-scm.com/), it is >>> not as good or complete as mercurial (http://hgbook.red-bean.com/read/) >>> in terms of non-power users. Both have books in print available from >>> places like Amazon. >>> >> >> For me git's documentation was more than enough to have a quick-start. >> >>> For example, I started my evaluation with bzr, then hg then git. bzr and >>> hg were a lot easiest to pick up and start using than git. >>> >> >> I wonder, do you remember what the problem(s) with git was (were)? Care >> to give an example where git is harder than any of the other two? >> > I never said I had problems doing things in git - I said I had problems > finding out how to do them. Tell me with a straight face that the number > of options in some of the git commands did not overwhelm you the first > time you saw them? Well, no they did not, as I've already seen tar and diff manpages before git. BTW, cvs diff has about 60 options and nobody cares. IMHO, it's git's explicit staging area (aka index, aka cache) that makes it different from others and maybe somewhat harder to get used to. Selecting what to commit and actually committing are made to be two separate actions. If it's worth additional complexity... I don't know. However, it's not that difficult concept as it's semantically similar to what one does in a GUI when selecting files to be included into the next commit, then pushing the commit button. > When you want to encourage community development, you really need to > keep it simple for developers to keep abreast of advances and contribute > back. Not have so many bells and whistles that they feel like they > should not touch anything in case it breaks, or worse, have someone who > thinks they know what they are doing but does not. I just wanted to point out that git is not that hard to use that anybody looking at it the first time should run away screaming! :-) [...] > Not entirely wrong ;-) When working with branches ever run "git > submodule update" when you've made and committed changes within a > submodule without checking out the branch first, only to discover > later that the changes were silently overwritten? No, I didn't, I didn't try to play with git submodules yet. However, I doubt the data are actually lost if they were committed to the submodule, really. One must be rather proficient in git to force it to loose some data, but then he already knows what he is doing. [...] > However, I strongly disagree with your comment "hg already outlived its > initial simple design..." though. hg's design is just as simple as git > and there is nothing in hg's design IMHO that limits what it can do. It > is still evolving, just like git and eCos. The forests extension has > been around just as long as sub-modules AFAIKT, but I admit it is taking > a while for hg to make it part of their core functionality. To be fair, I think the submodules in git are also rather unpolished yet, as you've already got a chance to figure out. And you are definitely right all these comparisons are moving target. -- Sergei. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] JFFS2 Issue. 2009-09-21 22:41 ` Alex Schuilenburg ` (2 preceding siblings ...) 2009-09-22 12:21 ` Sergei Organov @ 2009-09-22 17:03 ` Ramgopal Kota 2009-09-23 12:37 ` Ramgopal Kota 2009-09-25 0:16 ` Jonathan Larmour 3 siblings, 2 replies; 16+ messages in thread From: Ramgopal Kota @ 2009-09-22 17:03 UTC (permalink / raw) To: eCos Discussion Hi, I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue. In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below struct jffs2_unknown_node marker = { .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), .totlen = cpu_to_je32(c->cleanmarker_size) }; struct jffs2_unknown_node { /* All start like this */ jint16_t magic; jint16_t nodetype; jint32_t totlen; /* So we can skip over nodes we don't grok */ jint32_t hdr_crc; } __attribute__((packed)); I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER. If I change the code to the following it is working fine... struct jffs2_unknown_node marker = { .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), .totlen = cpu_to_je32(c->cleanmarker_size) }; marker.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK); I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag. Compiler I am using is gcc version 3.2.1 (eCosCentric) Thanks & Regards, Ramgopal Kota -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [ECOS] JFFS2 Issue. 2009-09-22 17:03 ` [ECOS] JFFS2 Issue Ramgopal Kota @ 2009-09-23 12:37 ` Ramgopal Kota 2009-09-25 0:16 ` Jonathan Larmour 1 sibling, 0 replies; 16+ messages in thread From: Ramgopal Kota @ 2009-09-23 12:37 UTC (permalink / raw) To: eCos Discussion Can some body help me ? I am worried as it may lead so many other issues in future .. Please let me know what could be reasons for this kind of behavior ?? Thanks & Regards, Ramgopal Kota -----Original Message----- From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Ramgopal Kota Sent: Tuesday, September 22, 2009 10:33 PM To: eCos Discussion Subject: [ECOS] JFFS2 Issue. Hi, I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue. In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below struct jffs2_unknown_node marker = { .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), .totlen = cpu_to_je32(c->cleanmarker_size) }; struct jffs2_unknown_node { /* All start like this */ jint16_t magic; jint16_t nodetype; jint32_t totlen; /* So we can skip over nodes we don't grok */ jint32_t hdr_crc; } __attribute__((packed)); I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER. If I change the code to the following it is working fine... struct jffs2_unknown_node marker = { .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), .totlen = cpu_to_je32(c->cleanmarker_size) }; marker.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK); I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag. Compiler I am using is gcc version 3.2.1 (eCosCentric) Thanks & Regards, Ramgopal Kota -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] JFFS2 Issue. 2009-09-22 17:03 ` [ECOS] JFFS2 Issue Ramgopal Kota 2009-09-23 12:37 ` Ramgopal Kota @ 2009-09-25 0:16 ` Jonathan Larmour 1 sibling, 0 replies; 16+ messages in thread From: Jonathan Larmour @ 2009-09-25 0:16 UTC (permalink / raw) To: Ramgopal Kota; +Cc: eCos Discussion Ramgopal Kota wrote: > Hi, > > I am integrating JFFS2 into our MIPS Malta board. I am seeing a strange issue. > In JFFS2 erase.c file and function jffs2_mark_erased_block , code section as below > > struct jffs2_unknown_node marker = { > .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), > .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), > .totlen = cpu_to_je32(c->cleanmarker_size) > }; > > struct jffs2_unknown_node > { > /* All start like this */ > jint16_t magic; > jint16_t nodetype; > jint32_t totlen; /* So we can skip over nodes we don't grok */ > jint32_t hdr_crc; > } __attribute__((packed)); > > I am seeing that both .magic and .nodetype are filled with 0x2003 which is the value of JFFS2_NODETYPE_CLEANMARKER. > > If I change the code to the following it is working fine... > > struct jffs2_unknown_node marker = { > .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), > .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), > .totlen = cpu_to_je32(c->cleanmarker_size) > }; > > marker.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK); > > I don't know if it is CFLAGS issue or Compiler issue.I am thinking it is a compiler optimisation re-ordering issue.I am using -Os flag. > Compiler I am using is gcc version 3.2.1 (eCosCentric) I recommend you eCos 3.0 and the updated GNU tools instead (you can't really use the updated tools with eCos much before 3.0). You should have got an error compiling JFFS2 due to this in src/fs-ecos.c: #if (__GNUC__ == 3) && (__GNUC_MINOR__ == 2) && \ (defined (__arm__) || defined (_mips)) #error This compiler is known to be broken. Please see: #error "http://ecos.sourceware.org/ml/ecos-patches/2003-08/msg00006.html" #endif Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Switching to using git on eCosForge 2009-09-21 14:39 [ECOS] Re: Switching to using git on eCosForge Alex Schuilenburg 2009-09-21 20:06 ` Sergei Organov @ 2009-09-21 22:08 ` Sergei Gavrikov 1 sibling, 0 replies; 16+ messages in thread From: Sergei Gavrikov @ 2009-09-21 22:08 UTC (permalink / raw) To: Alex Schuilenburg; +Cc: eCos Disuss On Mon, Sep 21, 2009 at 03:39:09PM +0100, Alex Schuilenburg wrote: > [Apologies to sergei for repost - grrr] > > Sergei Organov wrote on 2009-09-21 14:05: > > Alex Schuilenburg <alexs@ecoscentric.com> writes: > > > > [...] > > > > > >> Both bazaar and mercurial were a lot easier to learn and work with > >> than git. git's Windows support is also limited and is mostly > >> restricted to the 100's of cmd apps which make up git under cygwin. > >> > > > > Once again, I'm not a Windows user, but is this really true nowadays? > > > > E.g., what about this one: > > > > <http://code.google.com/p/tortoisegit/> > > > > Isn't it good enough for Windows users? > > > and hg has TortoiseHG <http://tortoisehg.sourceforge.net/> > (http://tortoisehg.sourceforge.net/). Like I said, feature comparison > between git and hg is pretty much on a par... > > Lack of windows support/integration is not my main argument against git > FWIW. > > My main argument against git is it has a very steep initial learning > curve, and from experience you can hang yourself if you do not know what > you are doing. (Yes, there are rollbacks, etc, but sometimes it is a > while down the line before you realise you did something wrong). You > really don't want to force new users on an additional learning curve. > There are 100's of commands to remember, whereas both bzr and hg have one. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Excuse, please, my thougths the below. Any *nix CLI environment has something like the above :-) BUT, with those 100's {text,file}utils someone is able to do everything (even make world), but, today, *nix does not make him/her use those 100's. If somebody wants, he/she may use only `cp' and `mv' + $EDITOR, like `Explorer' + ... well, lets that will be `Notepad' to make things spin, if he/she wants, they can use only IDE likes Eclipse to do everything like it he/she did in Visual Studio. The most modern IDEs have all VCS modules/plugins, e.g. Komodo (Git, CVS, Perforce, Bazaar, Mercurial, etc.) and, BTW, Eclipse has Git plugin, etc. I'm not Git user, but I think it is possible to overlap those 100's by N*100 clicks in IDE, if anyone wants that, they do it for them! I do not belive that maintainers will suggest then, Use IDE 'A' and do not use IDE 'B' for development with eCos. Just now I entered in search box 'CVS refcard', I download it and open the card. 100's commands? No, there are not. It seems there are a lot of options. How many CVS options we use(d) every day? I think what _any_ VC's (git is not exception) _every_day_in_use_ refcard will be that A4 sheet or half it. Thin things for CLI fans, so, they may `make world', IMO, others use A4 sheet and it will be enougth, it seems for me those IDEs implement (A4 on both sides) in GUI and that's enough. A thougth what Git == 100's CLI is the same myth likes *nix is life with ksh. Another issue. Do you really expect to find in a future any assistances here with _any_ VCS+GUI like the below, for example: - What IDE do you use? - Bla-bla-bla - Hm, that does not like any Tortoise. Test a moment, please... Well, Click there, expand that node, turn on that switch, then click [Ok] - What dialog are you seeing now? - ... I guess that this will be type then in the list, e.g., invoke $ {git,hg,bzr,svn} [option] <command> or read, please, for start: ecos.sourceware.org/anyvcs.html and follow the ref links there for a far reading. Why I think so? It's the real world. I did not meet here a lot assistance with configtool, for example, (BTW, CT is official GUI configuration tool for eCos), n.b. just get the suggests here to import some CDL options with ecosconfig. This is the real world. It seems for me that we try to decrease troubles for windows users because they have it enough, but, unfortunately, they is/will be in trouble with 10's CLI commands (hg, bzr) as well as with the 100's CLI commands (git). Of course, if they will be use CLI and not any Tortoise*. I say 'trouble' == 'remember' :-) > Also, while documentation is improving (http://book.git-scm.com/), it is > not as good or complete as mercurial (http://hgbook.red-bean.com/read/) > in terms of non-power users. Both have books in print available from > places like Amazon. > For example, I started my evaluation with bzr, then hg then git. bzr and > hg were a lot easiest to pick up and start using than git. I also have > done most of my eval on Linux, dropping back to Windows to see how easy > it was to use and integrate graphical diff tools, etc. Today I'm mercurial user (my way was from lanchpad (bzr) to bitbucket (hg), but I have not tried github yet :-) and it was happy that I'm CLI user. In those days when I read Bryan O'Sullivan HG book I observed a lot of examples like the below echo a>a echo b>b hg ci -A -m 'add a,b' echo c>>a hg diff AFAIR, HG book in those days was 99.9% of CLI examples. It seems I must re-read new revision... What a nice thing to get $40.00 from every reader which could only see in his prev life: C:\> Unfortunately, in fact, it is not possible to give a full power for windows users without CLI, even with very friendly VCS, because, even eCos on Windows, in fact, it is CLI (Cygwin + GNU). In any case, then windows users hear here new words: objcopy, readelf, strip, size, etc. very often. So, what world will be added then (git, hg, bzr), it's no matter. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-09-25 0:16 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-21 14:39 [ECOS] Re: Switching to using git on eCosForge Alex Schuilenburg 2009-09-21 20:06 ` Sergei Organov 2009-09-21 22:41 ` Alex Schuilenburg 2009-09-22 6:28 ` [ECOS] JFFS2 Or Compiler Issue Ramgopal Kota 2009-09-22 9:55 ` [ECOS] Re: Switching to using git on eCosForge Peter Korsgaard 2009-09-22 11:08 ` Alex Schuilenburg 2009-09-22 11:21 ` Sergei Gavrikov 2009-09-22 11:41 ` Edgar Grimberg 2009-09-22 17:29 ` Ilija Kocho 2009-09-22 11:52 ` Alex Schuilenburg 2009-09-22 11:38 ` Peter Korsgaard 2009-09-22 12:21 ` Sergei Organov 2009-09-22 17:03 ` [ECOS] JFFS2 Issue Ramgopal Kota 2009-09-23 12:37 ` Ramgopal Kota 2009-09-25 0:16 ` Jonathan Larmour 2009-09-21 22:08 ` [ECOS] Re: Switching to using git on eCosForge Sergei Gavrikov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).