Most of git hand book and tutorial tell how to obtain git repos, manage git repos, see what is changed, how to merge, and so on. But I haven’t found a good guide for supporting developers who need to keep track of the main development, while providing their own modification for easy merge back to trunk.
Indeed, quite a lot of tutorial already mentioned how to cooperate with others, but have you encountered the following:
- Whenever upstream updates po files, you have to manually edit them all to resolved conflict, though you never touch it.
- After merge, there were dozens of conflicts, though you only changed a few files before merge.
- Finally, some folks kindly tell you that git-rebase is the way to go, but if you actually do it, there will be hundred of conflicts waiting to kill your time.
I still believe that those hand books might enlighten us about the relieves of these symptoms. providing you have sufficient time an patient to actually understand it, but I don’t.
Here are some tips:
- Keep the latest untouched-by-you upstream commit ID in mind, suppose it is “untouched-by-me”
- Add –rebase when using git-pull
- If you see some conflict on the files you don’t even want to touch,
roll back these files by
git-checkout untouched-by-me files
- No need to dash directly into the hell of conflicts by running git-mergetool,
- Make your patch:
git-diff untouched-by-me your-latest-touch > patch-file
- Reset back and get the update from upstream.
- Apply back your patch:
And yeah, now is the time you resolve conflict.
- Commit when done.
- Remember to use
Caps Lock is used in chewing and other input method as mode switch key. Caps off for Chinese mode; and on for English mode, for example. However, it is not so simple to tame the Caps lock.
Paragan kindly gave me a link of keylockx, a program to detect and set the lock mode. Tagoh also told me that lock-keys-applet, a GNOME applet can also to the similar. While both programs do change and reflect the real Caps mode; unfortunately, the LED on USB keyboard does not reflect such changes.
Things get even wierder when synergy is involved. The lock stage switch happens in synergy client, which is all right and correct. Problem is, synergy server LED does not reflect this.
Ok, I know synergy server lock LEDs does not have to synchronize with client, and might cause more trobles if forced to do so. But it still confuses inexperienced end users, as client do not necessary have lock LED on them.
Mmm, may be that’s why lock-keys-applet has its own position, as it showed the real lock state on the client. But story does not end here, as input methods usualy just process the CapsLock event, do not care what’s current status and where the event from… arrrgaghhhh