It seems that GIT package update is in the working order. Great job, team!
However, the documentation is not integrated yet, I have to visit 4 pages to make it working:
- Fedora project’s Package_update_HOWTO (yes, with that name).
- Fedora project’s Using_Fedora_GIT
- For know that I need a new version of fedora-packager
- and this for let git push to the branch you are tracking
I think it will help to provide a step by step or check-list, at least as my personal note.
- sudo yum –enablerepo=updates-testing update fedora-packager
you need version fedora-packager-0.5.1 and newer to work.
This will bring git as dependency.
- fedora-cert -n
For update client side certificate
- git config –global –add push.default tracking
Init (clone) package
You only need to run once per each package you are interested:
fedpkg clone <packageName>
It creates a directory in the name of <packageName>
cd to this directory to continue working.
Update package in devel branch
- Import srpm
fedpkg import <SRPM File>
- Commit and push in one go, it will show which files have been changed. You can exit the editor without saving to cancel the pushing, as you normally do with git-commit
fedpkg commit -p
- Build package
Update package in stable branches
For example, if you are going to push your updates in F-13, then
- fedpkg import -b f13 <SRPM File>
- fedpkg switch-branch f13
Then follow the steps of “Update package in devel branch”
|Show Src URL
||git remote show origin
|Ignore pattern file
|Ignore pattern syntax
|Local ignore pattern*
* Ignore pattern in subdirectory and for subdirectory.
Well, I do think mercurial can be more convenient if it supports the local ignore pattern,
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