96ca3fe470
* Makefile
* config/*
* contrib/*
* doc/*
* extras/*
* include/*
* lib/*
* package/*
* src/*
* tests/*
* utils/*
* removed empty lines left after removed '$' + 'Id' + '$' identifiers
106 lines
4.4 KiB
Plaintext
106 lines
4.4 KiB
Plaintext
HOW TO USE THE SOURCE REPOSITORY
|
|
--------------------------------
|
|
|
|
Content
|
|
=======
|
|
|
|
1.1 Here's how to prepare for uploading to the Git server
|
|
1.2 Here's how to upload your changes to the Git server
|
|
1.3 Here's how to format your ChangeLog entries
|
|
1.4 Here's how to use the Git server in anonymous read-only mode
|
|
1.5 Things to do to avoid damaging the Git repository
|
|
|
|
1.1 Here's how to prepare for uploading to the Git server
|
|
=========================================================
|
|
by Viktor Szakats
|
|
|
|
1) Read the Harbour README.md, monitor the development mailing list,
|
|
consult with the developers, make contributions. This way your chances
|
|
are high to get a R/W access to the repository.
|
|
2) Before uploading anything you'll need push permission for the
|
|
Harbour Git server. To get this please make a request on the development
|
|
list. Note that getting Developer status is not an automatic process.
|
|
3) You'll need an Git client for your platform.
|
|
4) Do a 'git clone' to get your own local development Git repository.
|
|
|
|
1.2 Here's how to upload your changes to the Git server
|
|
=======================================================
|
|
by Viktor Szakats
|
|
|
|
1) Make the changes in the source
|
|
2) Do a 'git pull'
|
|
3) Resolve any conflicts
|
|
4) Run 'hbrun bin/commit' to check any commit pre-checks
|
|
and to create new ChangeLog.txt entry template
|
|
5) Edit ChangeLog.txt with a text editor (do not use notepad.exe)
|
|
6) Copy the last ChangeLog.txt entry to the clipboard
|
|
If it's a single atomic change, it's better to copy only
|
|
the description itself without the entry header and list
|
|
of files.
|
|
7) Do a 'git commit [-a]'
|
|
8) Paste clipboard content to the text editor that popped up
|
|
9) Save and exit in editor
|
|
10) Git is now committing
|
|
11) Do a 'git push' to publish your changes online to the
|
|
master repository
|
|
|
|
1.3 Here's how to format your ChangeLog.txt entries
|
|
===================================================
|
|
by Viktor Szakats
|
|
|
|
- Use 'hbrun bin/commit' to create a new ChangeLog entry
|
|
|
|
- Add description below each group of changed files.
|
|
Describe what you've changed, the reasons, and other comments
|
|
and explanations you find useful.
|
|
|
|
- In case of incompatible changes visible on the user-level,
|
|
add the word 'INCOMPATIBLE' to the text.
|
|
|
|
- Mark comments suggesting further fixes with 'TOFIX: ', further
|
|
todos as 'TODO: ', and update these to '[DONE]' when implemented.
|
|
|
|
- Mark changes to merge with different branch as '[TOMERGE x.0]'.
|
|
Changes these to '[MERGED x.0]' when merge is completed.
|
|
|
|
- Leave an empty line after the body.
|
|
|
|
1.4 Here's how to use the Git server in read-only mode
|
|
======================================================
|
|
|
|
git clone git://github.com/harbour/core.git harbour-core
|
|
|
|
1.5 Things to do to avoid damaging the Git repository
|
|
=====================================================
|
|
by David G. Holm
|
|
|
|
1) Always do your Harbour development using your local source tree. Do not
|
|
do your development outside your local source tree and then copy your
|
|
changes into your local source tree to commit them, because that leads
|
|
easily to accidentally overwriting changes made by others, because
|
|
you didn't notice that a module that you were also working on was
|
|
changed by someone else. By always doing Harbour development using
|
|
your local source tree, changes made by others will be merged with your
|
|
changes and you only need to recompile and retest before committing.
|
|
|
|
2) Always run 'git pull' from the 'harbour' directory before you run
|
|
'git commit'. Run 'hbmk2 bin/commit' before committing, which will
|
|
create a new entry at the top of ChangeLog.txt, which you can then
|
|
edit with the description of changes.
|
|
|
|
If you see any conflicts reported in the update output, then you need
|
|
to resolve them before committing. Git is generally good at merging
|
|
changes, so you probably won't see conflicts very often, but if you
|
|
edit the ChangeLog.txt before you run 'git pull' and other changes
|
|
have been committed by others, then ChangeLog.txt will have conflicts.
|
|
To resolve those conflicts, you need to resolve the conflict. What
|
|
I do to avoid conflicts to ChangeLog.txt is to record my changes in
|
|
changes.txt and then copy them into ChangeLog.txt between the update
|
|
and the commit.
|
|
|
|
|
|
[ Copyright (c) 1999-2013 Viktor Szakats (vszakats.net/harbour)
|
|
Licensed under Creative Commons Attribution-ShareAlike 3.0:
|
|
http://creativecommons.org/licenses/by-sa/3.0/
|
|
See COPYING.txt. ]
|