This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Switching to using git on eCosForge


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]