Your question is actually a commonly encountered situation in git - making localized changes using git.
When you use git pull
, you only get the diff between the local git image and the remote git server. whenever you make local changes, you can issue git diff
to see the differences. So for you your steps should be:
git diff > mydiff.patch
to get a patch difference of the changes u have made.
git checkout -f
to revert back to the original image before your localized changes.
git pull
to do a full git update from remote server. this is where repo sync
can come in as well - as repo sync
drop to basically a sequence of git command (viewed via ps -ef
)
then you re-apply your localized changes again via patch -p1 --dry-run < mydiff.patch
to test out the reapplication. If successful, do the real patching via:
patch -p1 < mydiff.patch
If not successful, it only means that your changes is conflicting with some changes done on the remote server side that others have committed, and this is where you have to manually redo your changes again - tedious but no choice.
Take note: git
can be applied at each directory where you see a .git
directory, and the git command only take effect at that directory level. If you have make multiple changes in different directories with .git
subdirectory, then you have do a git diff
and git checkout -f
for each of those directory.
For example, while doing a repo sync
update I got:
Fetching projects: 100% (172/172), done.
Syncing work tree: 2% (4/171) error: You have local changes to 'core/base_rules.mk'; cannot switch branches.
Syncing work tree: 3% (6/171) error: You have local changes to 'tools/dx-tests/Android.mk'; cannot switch branches.
Syncing work tree: 100% (171/171), done.
external/dbus/: discarding 43 commits
error: build/: platform/build checkout 0683a77348f2a0a529a8e2bcfdf4b6dc6b4c5f5b
error: cts/: platform/cts checkout a3779fa378345bfd8699e91de46b29563be4beb2
Traversing downwards, I discovered that under the cts
directory is a .git
, so cd cts
and git diff
gives the difference.
The above scheme is simple enough, as there is always only one branch - the master branch, and your changes is always on top of that.
Alternatively you have to use git branch
to build your own branch, and then git merge
to merge your branch into the default master branch (read this).
The command for merging will be git merge topic
, where topic
is the branch created with git branch
to house your customized changes.
Overall the operations are still the same as above - conflicts will occur if the master and your branch modify the same file at the same line, or your modification comes AFTER the master.