The Codebelay Blog

Category: git

  • Git: How to Cherry Pick Commits and Package them Under a Tag

    I’ve pretty much come to rely on git to pull me out of any bad jams in the chaotic environment I work in.

    One thing I’ve had to learn to do is cherry pick commits and package them under a tag in git.

    Here’s how to do it if you were working with my newLISP project called Sitebeagle:

    fork sitebeagle on this page

    cd sitebeagle

    git fetch –tags

    git checkout 8f5bb33a771f7811d21b8c96cec67c28818de076

    git checkout -b sample_cherry_pick

    git cherry-pick 22aab7

    git cherry-pick b1334775

    git diff sample_cherry_pick..master

    git tag leaving_out_one_commit

    git push origin –tags

    At this point, you should have a tagged branch that doesn’t have the commit with the change to the “2nd file.” The diff should look exactly like this:

    diff –git a/test.lsp b/test.lsp
    index 9cf1667..158b625 100755
    — a/test.lsp
    +++ b/test.lsp
    @@ -1,6 +1,7 @@
    #!/usr/bin/newlisp

    ; test tag test_a
    +; cherry pick test 2

    (load “sitebeagle.lsp”)
    (load “twitter.lsp”);

  • Getting Around the Politics of Subversion with git

    This is the nightmare scenario. You are working with a coder who overwrites your changes in subversion. You’ve told this coder once, twice, three times, “Hey, please don’t do that. Hey, let’s talk about your changes before you commit them.”

    But this coder for some reason thinks that he or she is the gift of the gods when it comes to coding, and continues to overwrite your changes.

    This is where git comes in. If I had learned about this feature of git and the idea of accepting or rejecting changes in git sooner, I would have avoided the whole nightmare of re-comitting code and lengthy merge debates.

    Most projects you work won’t involve the worst case above. Most of the time, there will be a great developing rule that says never commit bugs into subversion. But whenever you have to re-factor code and commit each line, branching and then later merging can be an issue in subversion, and it’s slow too.

    On a project that I’m working on now the client wants only good code in svn which is great, and so I’m using git with svn. I got this idea thanks to Jakob Heuser. Thanks, Jakob!!!!

    This is where git comes in. Here’s a quick cheat sheet and it assumes you are using GitHub:

    mkdir newlispoauth
    cd newlispoauth/
    git init
    touch README
    git add README
    git commit -m ‘first commit’
    git remote add origin git@github.com:barce/newlispoauth.git
    git push origin master

    Now we have to pull in changes from subversion:

    mate .git/config

    In the config file add something that looks like this:

    [svn-remote “newlispoauth/trunk”]
      url = http://codebelay.com/newlispoauth/trunk
      fetch = :refs/remotes/newlispoauth/trunk

    Now we’re gonna fetch the subversion repo:

    git-svn fetch newlispoauth/trunk
    git checkout -b local-svn/trunk newlispoauth/trunk
    git svn rebase
    git checkout master
    git merge local-svn/trunk
    git mergetool # if there are conflicts with the README file above
    git add README # if you had to make changes with the mergetool
    git commit
    git push origin master

    Now you are working with “master” and “local-svn/trunk”.

    “master” is for your changes to share with your team on git-hub
    “local-svn/trunk” is for you and where you push changes to subversion.

    You basically pull in changes from newlispoauth/trunk and do your work in local-svn/trunk.

    Let’s put the changes in master into “newlispoauth/trunk” and commit those changes to subversion:

    git checkout local-svn/trunk # you did commit your changes in origin right?
    git merge master
    git-svn dcommit