Definite's Extractor

My findings on Life, Linux, Open Source, and so on.

Tag Archives: git

Fedora GIT package update (fedpkg) step by step.

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:

  1. Fedora project’s Package_update_HOWTO (yes, with that name).
  2. Fedora project’s Using_Fedora_GIT
  3. For know that I need a new version of fedora-packager
  4. 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.

Setup

  1. 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.

  2. fedora-cert -n
    For update client side certificate

  3. fedora-packager-setup
  4. git config –global –add push.default tracking

Package Handling

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

  1. Import srpm
    fedpkg  import <SRPM File> 
    
  2. 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
    
  3. Build package
    fedpkg build
    

Update package in stable branches

For example, if you are going to push your updates in F-13, then

  1. fedpkg import -b f13 <SRPM File>
  2. fedpkg switch-branch f13

Then follow the steps of “Update package in devel branch”

Quick note of “Mercurial vs Git”

  Mercurial Git
Show Src URL hg paths git remote show origin
Ignore pattern file .hgignore .gitignore
Ignore pattern syntax regex/glob glob
Local ignore pattern* Unsupported Supported

* Ignore pattern in subdirectory and for subdirectory.

Well, I do think mercurial can be more convenient if it supports the local ignore pattern,

git tips — as a supporting developer

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,
    instead,

    1. Make your patch:
      git-diff untouched-by-me your-latest-touch > patch-file
    2. Reset back and get the update from upstream.
      git-reset untouched-by-me
      git-pull
    3. Apply back your patch:
      git-apply patch-file

      And yeah, now is the time you resolve conflict.

    4. Commit when done.
  • Remember to use
    git-pull --rebase

    next time.