Thursday, March 20th, 2008 by Marcin Juszkiewicz
Due to recent discussion on OpenEmbedded mailing list I decided to give GIT second chance (first one was few months ago).
I imported Poky using git-svn tool and started hacking. First work was switching to OPKG (described in other post). I created branch for it and changed bit after bit — result was patchset with 17 patches. I pushed them into official Subversion repository in a bit other order and as few less revisions. After that I dropped branch as not needed any more.
Next was creating few branches for local hacks. Merging branches is easy when there are no conflicts and require manual calling of git mergetool FILE (instead of that being called automatically). Cherry picker works very nice and “rebasing” branches recognize such revisions.
Nasty thing is that every change has to be committed before switching branches as there is only one “working copy” at time (not like in CVS, Subversion or Monotone where you need “working copy” per branch).
What do I feel about GIT now? I started to like it.
Tags: git poky scm 1 Comment »
Wednesday, November 14th, 2007 by Marcin Juszkiewicz
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…
Tags: git linux scm 1 Comment »