GIT and I do not match

For both of my desktop machines I use git kernels and from time to time I add some additional patches to get something experimental to test. By default I use “quilt” to manage patches so my usual kernel session looks like:

quilt pop -a
git pull
quilt push -a

And as a result I have updated kernel with all my patches applied. If one of them do not apply I usually do updating by hand and call quilt refresh or search for newer version of patch.

Today I decided to do another attempt to use just GIT for managing my patched kernel tree instead of using GIT + quilt. And I failed :(

I cannot understand why GIT developers say that they hate CVS but follow its way when it comes to merging stuff… If any operation ends in merge conflicts all you get is file with CVS conflict markers inside. You need to call merge tool by hand, resolve problem, add files back to repository (do not ask me why adding files already known to SCM is needed) and tell that you resolved conflict. Even CVS or Subversion does not works that way…

I like the way it works with monotone — if there is conflict during update (so git pull like) merge tool is called (kdiff3 on my system) and user has to resolve all conflicts before monotone will go into next step. Whole merging stuff is then stored as another revision (with git it can be then remove during git rebase).

Maybe one day I will find a way to get familiar with git but it is not today…

One thought on “GIT and I do not match

  1. Pingback: GIT - second try » Hrw website

Comments are closed.

  1. […] Due to recent discussion on OpenEmbedded mailing list I decided to give GIT second chance (first one was few months ago). […]