Workflow
We use a centralized rebase workflow. We have a central repository with a single branch "master" and a linear history. Developers work in local topical branches but commit them to the "master" branch on the central repository.
No local changes should be made to the local "master" branch: all changes should occur on a topical branch. For simplicity, pulls and pushes are done directly on the topical branch, so normally the local "master" branch is rarely used.
Clone the repository, either via ssh if you've set up ssh keys in your Github profile:
git clone git@github.com:DynamoRIO/drmemory.git
Or via https:
git clone https://github.com/DynamoRIO/drmemory.git
Now run the development setup script:
make/git/devsetup.sh
Ensure origin is up to date:
git fetch origin
Then create a new branch for the feature or project, called a "topical" branch. Replace "topical" here with a name of your choice:
git checkout --track -b topical origin/master
If you've run the development setup script, you can shorten this to:
git newbranch topical
Now perform your work in the topical branch, committing locally.
To bring upstream changes into your local topical branch:
git pull --rebase
git submodule update
If you've run the development setup script, you don't need the --rebase
argument, and you can use the alias pullall to perform both steps at
once:
git pullall
Once the code in your topical branch has been reviewed, passed the test suite, and is ready to commit upstream, you can push it by running this command while on the topical branch:
git push origin HEAD:master
If you've run the development setup script, you can shorten this to:
git dcommit
Once you've pushed your changes upstream, you can delete your topical branch with these commands (substituting your branch's name for "topical"):
git checkout master
git pull --rebase
git branch -d topical
Be careful with submodules when pulling upstream changes. If a submodule
was modified upstream and only a git pull is run without a subsequent
git submodule update, that upstream change will be reverted upon the next
git push. Please use the pullall alias as described below to avoid
accidentally clobbering submodule changes.
We do have a pre-commit hook in place that will warn you if you try to roll back the dynamorio submodule while checking in at least one other file:
% git commit -a
Error: the dynamorio submodule is being rolled back.
This is likely a mistake: did you pull but not run git submodule update?
Aborting commit.
Run git checkout <hash> to update DynamoRIO to that hash:
cd dynamorio
git checkout 0c81acfc9aaea949e6f6ecfe0b4157c06a014dda
For more details, see UpdatingDR.
If you want to split off the first commit or two from a feature branch and you issue a command like this:
git checkout -b tocheckin 35d4e9c87de22ec9b3a8a110cae2d83821c88ee0
The tocheckin branch will not be a tracking branch, and thus the git dcommit will not work. You'll need to issue this command:
git branch --set-upstream-to=origin/master tocheckin
If you've run the development setup script, you can run both commands at once with:
git split tocheckin 35d4e9c87de22ec9b3a8a110cae2d83821c88ee0
Some potentially useful aliases that are not in the development setup script include the common tasks of looking at the log of changes versus the remote master:
git config alias.dlog "log --stat origin/master.."
And looking at the full diff versus the remote master:
git config alias.ddiff "diff origin/master.."
