-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Description
Instruction to sync to master after rewrite
If you do not have local changes, you can simply do git reset --hard [HASHTAG-OF-NEW-HEAD]
Please use the following commands
# Add upstream if you have not yet done so
git remote add upstream https://github.com/dmlc/tvm
git remote add prefilter https://github.com/tqchen/tvm
git fetch upstream
git fetch prefilter
# checkout a local branch for safety reason,
# you can always reset your master to the old head
git checkout -b backup
git checkout master
# Bring your changes on top of the most recent prefilter branch
git rebase prefilter/prefilter
# sync your local changes to master
git rebase --onto upstream/master e316f03d2d2e0c06019b6d026b9696b7d3f67b8d
# force push to your upstream master
git push --forceHere e316f03d2d2e0c06019b6d026b9696b7d3f67b8d is the hashtag of the head before fiilter. The last command will take the commits between ``e316f03``` and your head and apply it to the upstream/master's HEAD
Context
The history has been rewritten
- An old history branch is kept at branch prefilter, and we will delete it after 0.4
This is to followup issue on #1189
So far in the SGX demo, we introduced private keys into the commit history. Although the private key is only used for demo purposes and poses no security concern, it triggers false alarm of security scanning tools.
Currently, the private keys are shallowed removed. But it can still trigger the alarm due to the fact that the file is still in git history.
I have created https://gist.github.com/tqchen/ca5f1b898e27035621130d87aa9bebaf to deeply filter the history to remove the file. With an example branch here https://github.com/tqchen/tvm/commits/filter that gives the result of filter-branch.
Note that filter-brach causes divergence from the current tree, and in order to bring this change to master, we have to force rewrite the history and push to master -- note that commits contributions are preserved, but it indeed will cause troubles for our contributors.
This is a decision that can not be made lightly. So this is an RFC post, to hear opinions from the community on whether we should do this or not. Please express your opinions in this thread.
This thread will remain open for one week before we reach a decision
Pros and Cons
- Pros: avoid security check alarm in the future, although it is a false alarm.
- Cons: require contributors to sync up with the master via history rewriting.