...
svn diff
git diff
(shows only unstaged changes,git diff --cached
shows prepared commit)svn add
git add
– used to stage for commitsvn update
git pull
svn commit
git commit
, followed bygit push
. You need to stage (akaadd
all files which should be commited)svn status
(optionally refresh local stategit fetch
then)git status
- {{svn revert }}path
{{git checkout -- }}path svn info
git remote -v
lists all remotes andgit remote show <name>
shows details about remote (for examplegit remote show origin
for the default remote name).svn cp
_https://svn.apache.org/.../trunk_ _https://svn.apache.org/.../tags/my-tag_-m message
git tag -m message my-tag
(or better, add also -s or -u option to create a cryptographically signed tag)
...
If you accept a pull request, you have to apply it as a patch to the Apache WIP repository, this commit will then be propagated to the GitHub mirror. In the comment of the commit/merge you should use GitHub syntax (closes #xx) to close the PR. There is GitHub provides a nice API for retrieving diffs for pull requests: just add ".diff" or ".patch" to the PR URL and you will get the diff/patch, for example https://github.com/apache/commons-foo/pull/72.diff. In the comment of the commit/merge you should use GitHub syntax (closes #xx) to close the PR. There is no other way to close pull requests. So to reduce the INFRA teams workload (to work on your tickets with close requests) remember this procedure.
...
First of all, make sure the the PR you want to merge does not contain merge conflicts. If that is the case you can start not the case, it's best to ask the contributor to resolve any merge conflicts by rebasing against the master branch. If all conflicts have been resolved you can start merging the PR by fetching it into your local clone of repository. To do this the GitHub mirror has to be defined as a remote in your local clone. This only has to be done once and you can check whether you already did it with:
...
No Format |
---|
$ git remote show -n
github
origin
|
If you don't have an entry for the github mirror yet, you can add one with:
...
The pull makes sure you have the lastest changes from the Apache repository in your local clone. Merging with --no-ff option will create a separate merge commit. This is why your $EDITOR will be started asking you to provide a commit message. The first line will be "Merge branch 'fix-foo-in-bar'". You should leave it this way so the fact that this branch has been merged can be seen in the history. Furthermore a reference to the corrensponding Jira should be added. For an example see https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=commit;h=640953167adf3580a2c21077d78e7e7ce84ead03 If the PR did not contain merge conflicts, only the commits you added before merging can produce merge conflicts. This happens for example if you've added the corresponding jira issue to changes.xml but the master branch already contained newer entries. Resolve all conflicts, all files using $ git add .
and then finalize the merge with $ git commit
. Up to this point you've only modified your local repository. So it's time to push the changes back to the Apache git repository:
No Format |
---|
$ git push origin master
|
If you've done it right, the PR will be marked as merged at GitHub. Remember that this will only work if the original commits of the contributor show up in the history of the component's repository.
Applying Pull Requests (for git based components) - alternative approach
Much like for svn based you can download a git patch file by appending ".patch" to the URI of the pull request, e.g. https://github.com/apache/commons-foo/pull/72.patch
Inside the working copy of your commons component check out the master branch and apply the patch using "git am", this will preserve the original information of the original commits.
No Format |
---|
$ git checkout master
$ git pull
$ git am 72.patch
|
If there haven't been any merge conflicts you can simply push the result. Otherwise you've got to resolve the conflict and commit the result of the merge before pushing.
Fixing line endings in working copy
Ensure that .gitattributes is set up correctly.
If your version of git honors it you can apply the attributes to your existing working copy by pulling, removing .git/index and then running "git reset
--hard"