karzilla: a green fist above the word SMASH! (Default)

Bug counts: resolved 399, assigned 8, needs-review 1



Two things:

1) I am currently doing some branch gymnastics with vgifts and wanted to record my process here.

Given one published branch "bug0215-submitted" which was just pulled into develop on Github, and another unpublished, temporary branch with additional changes waiting in the wings, here is what I did to update my original working branch with the new changes:

> git co develop
> git pull dreamwidth develop
> git co bug0215-submitted
> git merge develop
[note: here bug0215-submitted and develop are identical]
> git co (temp branch)
> git rebase bug0215-submitted
> git co bug0215-submitted
> git merge (temp branch)
[note: here bug0215-submitted and temp branch are identical]
> git branch -d (temp branch)

Now all of my new code is tacked onto my existing published branch and just needs to be pushed to my Github repository, along with the updated develop branch.

2) I cannot recommend GitX (http://rowanj.github.io/gitx/) highly enough for showing me at a glance how the state of my working repository changed with each command I executed above, giving me the confidence to proceed all the way through (gulp) deleting my unpublished branch.
karzilla: a green fist above the word SMASH! (Default)

Bug counts: resolved 395, assigned 10, needs-review 1



I'm back! While I was at OSCON last week I finally got to spend some time with Git. It is significantly different from Mercurial, but the good news is that it has a killer feature that I love - the ability to easily stage bits and pieces of your changes, instead of all or nothing. For a huge project like vgifts, this is making my progress much easier to track.

It's a bit confusing at first. If you don't know about the staging process, you'll probably change a file, go to commit it, and be told there's nothing to commit - because the changes haven't been staged. You have to use "git add" which in Mercurial is used to add new files to the repository, but Git expects you to use it every time you make any changes you want to keep. It saves a snapshot of the file as it appears at that instant, which means if you make further changes before committing, you will have to do "git add" again. (Or if you're just making a small change, you can use "git commit -a" to skip staging and automatically commit all modified files.)

There's an awesome interactive command line tool, "git add -i", that will help you through the process of staging multiple files and even cherry-picking particular hunks of a changed file. This is great for making sure a given commit only contains changes related to a single topic. I think the rebase command also supports the interactive option, but I'm still scared of rebases. :)

Also, for people who were lamenting the loss of Mercurial Queues, "git stash" provides very similar functionality. It lets you quickly move an unsaved set of changes out of the way, and maintains an ordered stack if you need multiple stashes. Between that and the ease of creating topical branches in Git, I may never need to juggle patch files again!

The study material that I used was the Pro Git book, which is available for free in several translations, either to read online or as an ebook. If you prefer a video tutorial, the one [staff profile] denise swears by is Git for Ages 4 and Up, which is the one that uses Tinkertoys as a teaching tool. I also found an hg to git cheat sheet which shows equivalent commands, but doesn't seem to know about git stash as an alternative to MQ.

Hope that helps someone!
karzilla: a green fist above the word SMASH! (Default)

Bug counts: resolved 347, assigned 8, needs-review 0



Heh, the new BBEdit 10 has a "Strip trailing whitespace" preference.

I just resaved LJ/User.pm for the first time with that feature turned on, and it found several instances of trailing whitespace to strip out for me.

Whee!
Page generated Mar. 26th, 2017 05:16 am
Powered by Dreamwidth Studios