Page History

...

• svn diff
git diff (shows only unstaged changes, git diff --cached shows prepared commit)
  
• svn add
git add – used to stage for commit
  
• svn update
git pull
  
• svn commit
git commit, followed by git push. You need to stage (aka add all files which should be commited)
  
• svn status
  (optionally refresh local state git fetch then) git status
  
• {{svn revert }}path
  {{git checkout -- }}path
  
• svn info
git remote -v lists all remotes and git remote show <name> shows details about remote (for example git 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'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.

$ 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"