[Cuis] Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])
Germán Arduino
garduino at gmail.com
Mon Dec 31 15:20:43 CST 2012
Sure, a great contribution of Angel with knowledge about Git.
Thanks.
2012/12/31 Juan Vuletich <juan at jvuletich.org>
> Thanks Angel. Your insights will surely be very useful, even if we'll take
> it slow.
>
> Cheers,
>
> Juan Vuletich
>
> Angel Java Lopez wrote:
>
>> Hi people!
>>
>> I don't know enough of Smalltalk (and its source code in file) to see the
>> best o better way of using GitHub. But I see in other technologies, used in
>> this way:
>>
>> - Branch x is an experimental branch, on new or improved feature a. For
>> example, x == stm and the feature is a == Software Transactional Memory.
>> Eventually, the branch dissapears, or it is merged with the main one
>>
>> - Branch x is for other platform. Some people uses branch in this way, or
>> eventually it fork another project. But this way of use is rare, AFAIK
>>
>> - Branch x is an experimental branch, but born from an external pull
>> request. That is, some other author wrote a Software Transactional Memory
>> implementation, and then, the main author(s) of the central repo, accept
>> his/her contribution, but not in master yet, only to be testes and stressed
>> by all.
>>
>> In forked repos, branches are used by the external contributor in the
>> following way. He/she has many ideas, fixes, issues it can resolved. Then,
>> forks the original repo, and not start to work DIRECTLY on this new fork.
>> Instead, he/she creates a branch FOR EACH idea, fix, bug solution, etc...
>> The branches are used like the patches in other systems. Author makes a
>> pull request to central repo, per branch. So, the central authors can
>> accept or reject by branch.
>>
>> Regarding Juan question, about "elaborate", the above was about branch.
>> About tags, you can see in the Smalltalk GNU project the use of tags for
>> versions. That is the "standard" way on most technologies.
>>
>> Angel "Java" Lopez
>> @ajlopez
>> github:ajlopez
>>
>>
>> On Mon, Dec 31, 2012 at 5:49 AM, H. Hirzel <hannes.hirzel at gmail.com<mailto:
>> hannes.hirzel at gmail.**com <hannes.hirzel at gmail.com>>> wrote:
>>
>> I have now done a sample how a repository could look like, see
>> https://github.com/hhzl/Cuis
>>
>> A copy of PetitParser is in a subdirectory 'packages'.
>>
>> I did this following the instructions of Angel in the 'Learning github
>> ...' thread. Thank you, Angel.
>>
>> What is still missing is the proper use of branches. This should not
>> be done in a main branch but in a 'PetitParser' branch.
>>
>> --Hannes
>>
>> On 12/31/12, H. Hirzel <hannes.hirzel at gmail.com
>> <mailto:hannes.hirzel at gmail.**com <hannes.hirzel at gmail.com>>> wrote:
>> > Sorry, the last two mails should have gone under the 'Learning git'
>> > subject line.
>> >
>> > As for building a Cuis distribution from *.pck files I think we
>> need a
>> > 'packages' and a 'scripts' directory in the main repository
>> >
>> > https://github.com/jvuletich/**Cuis<https://github.com/jvuletich/Cuis>
>> >
>> > And as we are at adding directories...
>> > in addition a 'documentation' directory
>> >
>> > --Hannes
>> >
>> > On 12/31/12, H. Hirzel <hannes.hirzel at gmail.com
>> <mailto:hannes.hirzel at gmail.**com <hannes.hirzel at gmail.com>>> wrote:
>> >> and later
>> >>
>> >> <citation>
>> >> Because a branch in Git is in actuality a simple file that contains
>> >> the 40 character SHA-1 checksum of the commit it points to,
>> branches
>> >> are cheap to create and destroy. Creating a new branch is as
>> quick and
>> >> simple as writing 41 bytes to a file (40 characters and a newline).
>> >>
>> >> This is in sharp contrast to the way most VCS tools branch, which
>> >> involves copying all of the project’s files into a second
>> directory.
>> >> This can take several seconds or even minutes, depending on the
>> size
>> >> of the project, whereas in Git the process is always instantaneous.
>> >> Also, because we’re recording the parents when we commit, finding a
>> >> proper merge base for merging is automatically done for us and is
>> >> generally very easy to do. These features help encourage
>> developers to
>> >> create and use branches often.
>> >> </citation>
>> >>
>> >> Angel,
>> >>
>> >> how do you think we should use branches?
>> >>
>> >> Amber https://github.com/**NicolasPetton/amber<https://github.com/NicolasPetton/amber>(Smalltalk which
>> compiles
>> >> to JavaScript and runs on node.js or in a browser) for example only
>> >> has 5.
>> >>
>> >>
>> >> --Hannes
>> >>
>> >> On 12/31/12, H. Hirzel <hannes.hirzel at gmail.com
>> <mailto:hannes.hirzel at gmail.**com <hannes.hirzel at gmail.com>>> wrote:
>> >>> There are about 40 branches with names like 'Seaside',
>> 'Omnibrowser',
>> >>> 'Filesystem' ....
>> >>>
>> >>> and the tags are used for version numbers.
>> >>>
>> >>> It seems that the integration/development of a subsystem is
>> done in a
>> >>> branch.
>> >>>
>> >>> I think we all have to read Chapter 3 of the git book
>> >>>
>> >>> http://git-scm.com/book/en/**Git-Branching<http://git-scm.com/book/en/Git-Branching>
>> >>>
>> >>> <citation>
>> >>> Some people refer to the branching model in Git as its “killer
>> >>> feature” , and it certainly sets Git apart in the VCS
>> community. Why
>> >>> is it so special? The way Git branches is incredibly lightweight,
>> >>> making branching operations nearly instantaneous and switching
>> back
>> >>> and forth between branches generally just as fast. Unlike many
>> other
>> >>> VCSs, Git encourages a workflow that branches and merges
>> often, even
>> >>> multiple times in a day. Understanding and mastering this feature
>> >>> gives you a powerful and unique tool and can literally change
>> the way
>> >>> that you develop.
>> >>> </citation>
>> >>>
>> >>> :-)
>> >>>
>> >>> --Hannes
>> >>>
>> >>>
>> >>> On 12/31/12, Juan Vuletich <juan at jvuletich.org
>> <mailto:juan at jvuletich.org>> wrote:
>> >>>> Can you elaborate? You see here something I don't get.
>> >>>>
>> >>>> Thanks,
>> >>>> Juan Vuletich
>> >>>>
>> >>>> Angel Java Lopez wrote:
>> >>>>> Interesting... see the combination of tags and branches
>> >>>>>
>> >>>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel
>> <hannes.hirzel at gmail.com <mailto:hannes.hirzel at gmail.**com<hannes.hirzel at gmail.com>
>> >
>> >>>>> <mailto:hannes.hirzel at gmail.**com <hannes.hirzel at gmail.com>
>>
>> <mailto:hannes.hirzel at gmail.**com <hannes.hirzel at gmail.com>>>> wrote:
>> >>>>>
>> >>>>> And I think it is useful to have a look at the directory
>> structure
>> >>>>> of
>> >>>>> https://github.com/bonzini/**smalltalk<https://github.com/bonzini/smalltalk>(GNU Smalltalk)
>> >>>>>
>> >>>>> --Hannes
>> >>>>>
>> >>>>
>> >>>>
>> >>>> ______________________________**_________________
>> >>>> Cuis mailing list
>> >>>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>>
>> >>>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>> >>>>
>> >>>
>> >>
>> >
>>
>> ______________________________**_________________
>> Cuis mailing list
>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>
>>
>> ------------------------------**------------------------------**
>> ------------
>>
>>
>> ______________________________**_________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>>
>>
>
>
> ______________________________**_________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20121231/1c027ca2/attachment-0002.html>
More information about the Cuis
mailing list