Kevin Old

Stepping down as Nodevember organizer

Mon, 05 Sep 2016 00:00:00 +0000

Edit 2016-09-06 1:32PM CT - Clarification: Remove typo of “apart” and reword “I was not apart of the decision…” to read “I did not take part in the decision…”.

Edit 2016-09-06 8:20AM CT - Clarification: I do not condone any form of hate. I love everyone. Everyone has value, should feel welcomed and loved. I pray for peace on all sides.

“34 I give you a new command: Love one another. Just as I have loved you, you must also love one another. 35 By this all people will know that you are My disciples, if you have love for one another.” John 13:34-35

Edit 2016-09-06 7:55AM CT - I am told there were DM’s received to the Nodevember twitter account on 2016-09-01 related to this. I had no knowledge of them and as a result failed to mention in my view of the timeline below.

I have stepped down as an organizer of Nodevember.

I officially stepped down after much prayer and thought on the situation on 2016-09-03.

I’d like to offer thoughts on why I made such a decision after investing so much in organizing a community event over the past few years.

For backstory, the outsider’s view collected in this post is an extremely accurate account of external and internal turmoil surrounding the controversy. It also provides details as far as allegations go against Mr. Crockford.

Lack of team effort

In short, I did not take part in the decision to uninvite Douglas Crockford to Nodevember.

By the time I’d received notice of the event unfolding on the evening of 2016-09-01, the decision was already made by the main organzier, swiftly and without discussion.

This, to me, is not the way to respond.

Allegations should be investigated, discussed and a consensus reached, by the entire organizing committee prior to any communication or adjustment to the schedule.

The decision should be communiciated with clear evidence and explaination of the decision and allegations leading up to the decision.

None of this took place.

The manner in which the allegations reached us, was in a public and confrontational manner; via Twitter.

And in a moment of confusion, a poor decision was made to remove Douglas Crockford as a speaker, by the main organizer.

I did not and still do not see a reason to uninvite him.

Diversity

As the controversy unfolded we had a list of yet-to-be-announced 48 speakers that made up the main portion of the conference.

Of those speakers, one would find it filled with a diverse group of speakers which line up with the list in the Nodevember Code of Conduct - These are “gender, sexual orientation, disability, physical appearance, body size, race, or religion”. Each of these were most likely represented. Of course, religion or disability are hard to distinguish, as some religions do not have outward representation, or disabilities such as mental illnesses are not plainly visible. It is also possible for a speaker and/or attendee to represent multiple forms of diversity.

For the event itself, every effort would be made to ensure that every person would feel comfortable during the event.

This seemed to work well for Nodevember 2015, in which Douglas Crockford and Kassandra Perch were present, along with several notable, names representing diversity in the JavaScript community. The list of speakers and presentations can be found on the Nodevember 2015 Youtube playlist. It is worth noting that no incidents were reported related to our Code of Conduct, prior, during or after the event.

Regarding the diversity in keynotes, I personally reached out to the following speakers of diversity and did not receive a reply or received a “No” to the offer to keynote the conference.

This list includes:

David Nolen @swannodette
Ben Alpert @soprano
Cheng Lou @_chenglou

Tolerance

I did not feel that the tweets fired at Nodevember were sent in a peaceful manner, per the code of conduct.

A suggestion to boycott the conference was made, because of suspicion that diverisity and inclusivity were not top priority. This tweet was speculation without evidence.

The tweets go on to chastize the conference for being held at a “Christian university”. It is worth noting: I am a Christian. I would challenge that I am in the minority among most conference attendees.

The acceptance of persons from all religions are part of diversity and inclusivity, as a whole. This is a postion I support and encourage.

We, as organizers, were being publicly shamed because of our inclusion of a speaker, in which another speaker had a preference against.

This is not tolerance. This is not acceptance. This is not inclusivity.

In closing

It is my personal experience and belief that everything possible was done to build a diverse conference of speakers and attendees.

We aimed to recreate the exciting and inviting atomosphere from last year.

The events of the past few days are saddening and in response to them I have decided to part ways with conference organizing for the time being.

Serverless GraphQL

Mon, 01 Feb 2016 00:00:00 +0000

I have been working with two bleeding edge projects, GraphQL and Serverless. Recently, it occurred to me that they might work well together, offering an infinitely scalable deployment of an amazing query language and runtime.

I thought, “I wonder if graphql-js would work as an AWS Lambda function?”. Sure enough; it did.

Development and Deployment whoas

I typically approach a project with a number of things in mind. What are the frontend, backend and scalablity requirements. Planning for success, often the scalable pieces of the project grow more difficult with each iteration. Load balancers, master-slave database setups, job queues, caching layers. It adds up. Quickly.

I’ve been searching for a way to allow more focus on the project itself rather than managing the scalable pieces.

In 2014, Amazon announced AWS Lambda. The possibilities were endless, but I couldn’t get past the need to interact with the service via manually uploading a zip file with my code. Fast forward to the summer of 2015 when the JAWS framework (now Serverless) was announced! Finally a way to interact with Lambda and other AWS offerings straight from the command line.

Serverless

“Serverless is an open source application framework for building serverless web, mobile and IoT applications exclusively on AWS Lambda.”

It offers a command line abstraction of AWS resources. This includes CloudFormation, API Gateway and Lambda services along with the overall orchestration of these resources.

The Serverless CLI makes the process of intializing and interacting with your project extremely smooth with a command line driven approach to creating the scaffolding and additional resources. Deployment of your Lambda functions and API Gateway endpoints are quick and completely abstracted. Issue a command to deploy and a few seconds later you’re able to interact with them.

Furthermore, you pay only when your Lambda functions and API Gateway endpoints are used.

GraphQL

With GraphQL, the query is the center of attention. Sure, there are types and schemas, but in my opinion, it’s all about the query.

“GraphQL queries declaratively describe what data the issuer wishes to fetch from whoever is fulfilling the GraphQL query.” – graqhql.org

These queries allows clients to request and receive the exact data they need. This allows Facebook to support over 1,000 versions of their mobile applications without out the need to modify their backend.

Since it’s release in the summer of 2015, GraphQL has grown on me as the preferred interface I would like to have from a frontend perspective. It allows my clients the ability to query for exactly the data they need, including nested data, and eliminate the need for addtional requests and data overfetching.

Simply put, it’s a dream to work with.

Instead of adding new endpoints, application logic and database queries, I simply define or update GraphQL types and schemas, populate the

resolve()

function’s to the data source (database query or Ajax call if the data is kept in another system) and deploy.

GraphQL is delivered via a single enpoint

/graphql

I knew that this would be the perfect candidate to run as a Lambda function.

Implementation

I decided that the perfect test of the idea, one that would allow enough nested data without too much complexity would be a Blog.

From conception of the idea of Serverless GraphQL a few weeks ago, to the reference implementation of Serverless GraphQL Blog I have spent less than $1 on AWS resources and only a few hours implementing.

I was able to generate my project, component, module and function in a few commands. Serverless offers these “four tiers of organization” for each project to allow for reusable pieces of code.

Iteration was quick and easy in that I’m able to use my favorite editor (Vim) to edit code and

1	serverless dash deploy

to deploy my Lambda function and API Gateway Endpoint into my development stage.

Given that Serverless orchestrates CloudFormation templates, I was able to define DynamoDB tables for the

Post

1
Author

and

1
Comment

types and they are automatically created with the proper permissions when issuing a

1
serverless resources deploy

. This was all achieved in the

1
s-project.json

I was able to keep my GraphQL schema and DynamoDB interactions in a resusable

/lib

directory and only expose a single function (

1
runGraphQL

) to Lambda. This code could (and should) be unit tested separate from Serverless, since it is just JavaScript.

Reusability

What’s ingenious is that with a recent release of Serverless, they have made other Serverless Projects installable into either a new Serverless Project or into an existing Serverless Project! Even the serverless-starter project can be setup with two simple commands

1	npm install serverless -g

and

1
serverless project install serverless-starter

This means, my reference implementation of a Serverless GraphQL Blog is installable with a single command

1	serverless project install serverless-graphql-blog

Heck, I can generalize this implementation into a

1	serverless-graphql-api

project and when the need arises in another project for a GraphQL instance, installing that project will instantly provide the scaffolding needed.

The Road Ahead

What started out as a crazy “what if?” has turned into a new direction for apps I plan to build in the future. Now that I’m able to use GraphQL in the most scalable and cost effective way possible, I’m certain that the days of deploying DigitalOcean servers are in the rearview mirror.

Apps that were previously 10’s and 100’s of endpoints are now possible with a single endpoint running GraphQL via Serverless on AWS Lambda.

Frontends can be published on S3. CORS support is already available for Serverless resources. Authentication via a custom Lambda endpoint (or Amazon Cognito, Auth0, etc). The pieces of a serverless architecture are starting to take shape.

The future looks mighty scalable.

Configure Webpack Dev Server and React Hot Loader with Ruby on Rails

Wed, 04 Feb 2015 00:00:00 +0000

Developing with React.js and a Node.js based server is a dream! When your stack isn’t full JavaScript, taking advantage of the latest dev tools can be a challenge.

I faced a similar situation with the wish to use the awesome React Hot Loader with Webpack in a recent Ruby on Rails project.

React Hot Loader is a plugin for Webpack that allows instantaneous live refresh without losing state while editing React components.

While the syntax make be less than desirable and a bit confusing at times, I was able to get everything working with the Webpack Dev Server alongside Ruby on Rails and step through the process below.

Before we begin

If you’re new to installing and working with webpack, I recommend Pete Hunt’s awesome webpack-howto. I also recommend reading through Justin Gordon’s Fast Rich Client Rails Development With Webpack and the ES6 Transpiler for an initial integration of Webpack and Ruby on Rails.

Installation

Install webpack, webpack-dev-server and react-hot-loader via npm:

npm install --save-dev webpack webpack-dev-server react-hot-loader

Webpack, Webpack Dev Server and HotModuleReplacementPlugin

A separate “hot” version of the configuration is recommended, based off of an original development webpack configuration file.

Add the webpack-dev-server and the hot reloading server in the array before your app’s entry point file. Note that we add a client url to the webpack-dev-server entry.

We will output a file with

1	wp_bundle.js

as the suffix to help identify files that were generated by Webpack and saved to the Asset Pipeline directories for further processing. It is also important to specify a

1
publicPath

that matches the client url set above with the webpack-dev-server.

Add a section for plugins and require the

1	HotModuleReplacementPlugin()

. Optionally, but recommended, add the

1
NoErrorsPlugin()

that will pause when it encounters a syntax error. Once you fix the error it will automatically resume hot loading.

Finally, add the

react-hot

loader to your loaders block.

The complete

1	webpack.hot.config.js

Rails config/environments/development.rb

In development we will instruct the Asset Pipeline to send requests for files with the suffix of

1	wp-bundle.js

to the webpack-dev-server, which we have running on 8080. This will update the URI to be fully qualified (e.g. http://localhost:8080/assets/App_wp_bundle.js). All other assets will be served as normal from Ruby on Rails.

Add a block to configure the asset_host:

Development

With configuration complete, it’s time to run the setup. During development you can manually start the webpack-dev-server separate from your

rails s

command.

From the Rails Root:

webpack-dev-server --config webpack.hot.config.js --hot --progress --inline

Note: The

--inline

flag is required for this to inject the hot loader script into Rails

An alternative would be to start both Rails and webpack-dev-server with a single command using foreman:

To run:

foreman start -f Procfile.dev

Summary

You now have a working Webpack configuration with React Hot Loader, served by webpack-dev-server via port 8080. Rails has also been modified to serve assets with the suffix of

1	wp_bundle.js

from Webpack Dev Server when in development mode.

Resources

Takeaways from React.js Conf 2015

Sat, 31 Jan 2015 00:00:00 +0000

tl;dr

React.js is rapidly being adopted and used by major players in the industry. NetFlix, Codecademy, Thinkmill, Bolster, Instructure, Inc and many more are using React, React + Flux or React and a twist on the idea of Flux in their projects and products to improve overall quality of code.
React Native - This is game changing! Introduced in the React.js Conf 2015 Keynote - Introducing React Native and React.js Conf 2015 Keynote 2 - A Deep Dive into React Native, React Native enables JavaScript developers to write native iOS and Android applications.
Flux, the project/pattern/concept/idea, is not going away and it is being implemented in various ways, neither of them are “wrong”.
Immutability is here to stay in JavaScript and can drastically improve the reliability, efficiency and simplicity of your JavaScript data collections. Immutable aims to have you “Developing with immutable data encourages you to think differently about how data flows through your application.”
Relay is an interation in the world of React + Flux based apps. Incorporating lessons learned with building large scale apps (Facebook Ads) they have determined that allowing components to retrieve their own data (via the forthcoming GraphQL).
Surprisingly there was no mention of Jest at the conference.
Videos from the conference are being posted in this Youtube playlist
Christopher Chedeau (vjeux) and team did an AMAZING JOB of organizing the entire conference!

React.js

The conference was all things React.js! Many spoke of best practices and optimizations with regards to structure and the use of immutable data structures.

React.js is rapidly being adopted and used by major players in the industry. NetFlix, Codecademy, Thinkmill, Bolster, Instructure, Inc and many more are using React, React + Flux or React and a twist on the idea of Flux in their projects and products to improve overall quality of code.

React v0.13.0-beta.1 was released with ES6 Class support using

1	jsx --harmony

. The release also adds support for CoffeeScript, TypeScript and other languages that compile to JavaScript as in ES6 they “are just plain old JavaScript classes”.

1	shouldComponentUpdate()

with immutable data structures was mentioned throughout the conference as the primary optimiaztion technique to speed up your already fast React.js apps.

It was clear from discussions after the React.js Conf 2015 - react-router increases your productivity talk with @mjackson and @ryanflorence that react-router has a lot of new fans. The talk clarified how using react-router is part of the application design process.

Flux

Flux, the project/pattern/concept/idea, is not going away and it is being implemented in various ways, neither of them are “wrong”.

Confusion around Flux being replaced by the forthcoming Relay was squashed in side conversations and a Q&A with the Facebook team on the last day.

Pete Hunt shared a great talk on using Flux full stack (React.js Conf 2015 - Full Stack Flux) that he is using with his new company.

Immutable data

Immutability is here to stay in JavaScript and can drastically improve the reliability, efficiency and simplicity of your JavaScript data collections. Immutable aims to have you “Developing with immutable data encourages you to think differently about how data flows through your application.”

Lee Byron gave a remarkable talk on “Immutable Data and React” and showed how to incorporate Immutable into a Flux Store by adding

1	OrderedMap

and

1
Map

. An ES5 gist of the ES6 example he gave in the presentation is here:

React Native

A completely game changing move by Facebook to enable JavaScript developers to write native iOS and Android applications with React.js.

Introduced in two keynotes, one the first day of the conference which left us waiting for more (React.js Conf 2015 Keynote - Introducing React Native) and the other the second day with a demo of the functionality and a look at a little bit of code (React.js Conf 2015 Keynote 2 - A Deep Dive into React Native). Attendees were given access to a Beta version of React Native with a few sample apps to being playing with and submitting patches. A day after the conference we already have minor demos coming online.

The statement was made by Christopher Chedeau (vjeux) that roughly 3 weeks before React.js Conf that they were unsure if they’d have a working version of React Native to release. I’m glad they were able to and that we were given access.

It may be best summed up in these tweets from @ryanflorence and @jlongster:

React Native gives you a web development workflow, no builds! Check out my 30 second video https://t.co/DfkVri1pF0
— Ryan Florence (@ryanflorence) January 31, 2015

I'm an iOS dev now, thanks React Native https://t.co/OmgZURVK4j pic.twitter.com/TvOHsngNgy
— Ryan Florence (@ryanflorence) January 31, 2015

Lots of questions about react native assume it's like other "JS for mobile apps" tools. Its literally native. Maybe think of it like swift?
— Ryan Florence (@ryanflorence) January 31, 2015

Oh man. Game UIs just got incredibly easy with React Native. Cmd+R refreshes the UI too. pic.twitter.com/b80b3xlK4F
— James “Jimmy” Long (@jlongster) January 31, 2015

The Future - Relay and GraphQL

My impression of Relay is that it is not meant to replace Flux, but to provide a window into how Facebook is iterating on using React with large applications. Enabling a React Component to retrieve it’s own data is not only more efficient, as they’ve found, but it is much better encapsulation. I have the impression that Flux is still used as is to help maintain application flow client side. Relay and GraphQL due to be open sourced sometime in the near future.

Facebook's Relay is for data exactly what our router is for views. Match a path, then map/reduce a hierarchy.
— Ryan Florence (@ryanflorence) January 31, 2015

There is also an Unofficial Relay FAQ with more details.

Jest

Surprisingly there was no mention of Jest at the conference and none of the talks mentioned their testing infrastruture in relation to React and Flux.

Videos

Videos from the conference are being posted in this Youtube playlist

In Closing

Christopher Chedeau (vjeux) and team did an AMAZING JOB of organizing the entire conference! All visitors were given access to many of the Facebook team and they were very receptive to feedback from users of React and Flux. It was clear that the excitement was still there for the entire Facebook team and they were eager to share everything they’d been working on.

React and Flux talk at NashJS

Wed, 14 Jan 2015 00:00:00 +0000

This evening I gave a talk at our NashJS meetup about my experience working with React and Flux. The video, slides and resources are below.

Video

The direct link to the talk on Youtube NashJS / Kevin Old / React.js + Flux

Slides

My slides are available here as a PDF or via SpeakerDeck

Resources

React

Flux

Thinking in React

Egghead.io React Fundamentals

Egghead.io Flux Architecture

“New” Dispatcher Example

Removing User Interface Complexity, or Why React is Awesome

Moving from Backbone to React

From Backbone Views To React

React Optimized List Demo

Async requests with React.js and Flux, revisited

Awesome React

Browserify

Reactify

The Treadmill Desk You Already Own

Wed, 13 Aug 2014 00:00:00 +0000

I like the concept of standing desks but hated the cost of them. I’ve assmbled one over the years to allow me the option to stand if I wanted. Turns out I love standing.

With treadmill desks getting attention these days, I’ve had the idea in the back of my mind for a few months. Today I had an epiphany in that I thought I already owned everything necessary to assemble my own treadmill desk.

Experiment

This is an experiment to build a treadmill desk for writing. Just writing. Emails. Journals. Blog posts. Coding could follow.

It’s an experiment to see if I can easily transform my ordinary treadmill into a station where I could view a screen (iPad in this case) and type.

Treadmill

It’s an ordinary treadmill with arms on it. That’s the key I think in that they are not too high or low.

Shelf

I used a shelf from my bookcase and it turned out to be the perfect fit.

Keyboard

I’m using the wireless Apple Keyboard and on the surface of the shelf was a bit low for me. So I thought, “I think this could work, maybe with a book or something else on top of it. It would need to be stable and wide enough to rest my wrists.”

It turns out that the box for the MacBook Pro seems to be just the right height to add to the shelf

“Computer”

I have to admit that my treadmill doesn’t have a shelf or platform for me to place my MacBook Pro on, nor the shelf without a great deal of added height and lack of ergonomics.

I usually prop my iPad up on my treadmill and watch screencasts or movies and it just made sense to use it.

I’ve limited my expectations to using writing most or all of my emails, blogs, etc. on it so as to embrace the limitations.

And there you have it, a treadmill desk I already owned.

I now have the “technology” of a treadmill desk and hope to use it regularly.

My Git Workflow

Wed, 17 Apr 2013 00:00:00 +0000

TLDR;

Keep 1 master shippable
Develop on a branch
Rebase only on a branch other than master
Merge development branch back to master

Use

1
git fetch

and

1
git merge origin master

over

1
git pull

Do a dry run before pushing to master: 1 git push --dry-run origin master

Details

Develop on a branch

- On master: `git co -b new_branch`
- (will be switched to new_branch)
- Develop, commit, rebase as needed

Staying up to date

As new changes are committed to master, get them from the server and bring those into the branch before merging back into master.

- Switch to master `git co master`
(note, the next 3 steps (with the exception of the 2nd) are the same as "git pull")
- `git fetch`
- review newly downloaded changes `git log origin/master`
- merge into master `git merge origin/master`

Getting changes onto the branch

To get the new change into new_branch:

- Switch to new_branch `git co new_branch`
- `git rebase master`

A breakdown of what rebase does:

The commits I’ve made to 1 new_branch are “lifted” or “stashed” off of the branch
A 1 git merge master is performed
My “lifted” commits are then reapplied

*Note:* If there are conflicts, I am prompted to fix them at this point, on the branch

Work is complete

When I am ready to merge all work done on

1	new_branch

back into master I simply do:

- From new_branch: git co master 
- On master: git merge new_branch

Measure twice, cut once

At this point, before pushing code to origin, I do a “dry run” to verify I have the latest changes from master after my last fetch

1	git push --dry-run origin master

Then if all is clean:

1	git push origin master

Git backup branches

Fri, 06 Jul 2012 00:00:00 +0000

I always work on branches with Git making small micro commits, then rebase master onto the branch. I keep master shippable and only rebase from

master

to a

1
topic/feature branch

. I like for my commits to be kept at the top of the topic/feature branch (squashing them if possible).

I’ve recently adopted passing

1	--ignore-date

flag to rebase:

1	$(branchA) git rebase master --ignore-date

As a git alias:

1	rid = rebase master --ignore-date

This is great and automatic, but what if something goes wrong?

Make a backup

There are many ways to manage this, and I often push to

origin

branches for an offsite “backup” of my branch. I wanted a way to have a local backup branch.

Here is a git alias to create a branch with a prefix of

BAK_

1	bak = !git branch `git br \| grep '' \| sed -e 's/ /BAK_/'`

Before rebasing, I make a backup copy of the branch in it’s exact state. If the branch is corrupt, I can delete the it and rename the backup to the original.

My quest to restore productivity to stalled personal projects

Wed, 06 May 2009 00:00:00 +0000

I've recently discovered a few key items that have lead to stalled personal projects and steps I can take to get back to productivity. Personal projects they are just that, personal. I could ask other developers/designers to be apart of these projects and would probably get a few to contribute, but there's something about accomplishing a goal on my own that I am chasing. How far can I push my talents and what end result can come of it. I think this view also leads to a fear of the end result not being "good enough". I've started several personal projects over the years and most remain unfinished. What's worse is that most are 90% complete. What's keeping me from finishing them? The "excuses" range from "the last 10% is the hardest to finish" to being unwilling to commit to graphics and styling. And procrastination. I stumbled upon a "blog post":time with a quote that might help me get a jump start on finishing some of these. bq. People feel good when they accomplish tasks. I know that. I'm giddy with joy when I accomplish even the smallest tasks with projects I work on professionally and personally. I can't wait to share what I've learned and created with family and friends. h3. Get organized * Define simple and clear goals of what the end result should be. All of the projects I've accomplished in my professional career have mostly been with the aid of working with a graphics designer. They initially provide mockups and a voice to converse with when certain design elements are unclear or I feel could be improved. Their mockups provided the roadmap from which to work. Mockups are *visual goals*. * Divide tasks into unbelievably simple tasks. Beside each task write an estimate on how long it will take to complete. It seems silly, but a few days/weeks/months down the road when reviewing your task list you'll read the description and the time estimate and think "I've got X minutes. I can check that off." * Use some form of GTD. It really works. h3. Get productive * Do something. Anything. Related to your project. * Get fired up. Grab a cup of your favorite beverage, get in a productive environment, crank the tunes and sing along. Whatever it is, just get _in the zone_. * Once in the zone, pick a task that interests you. It doesn't have to be next on the list, but it *must* interest you. * Give it 10 minutes and if you're not *feeling it* - Stop. Pick another task. * If you're still not feeling it, don't panic. Step back and relax. Choose something that you *know you can accomplish in a short amount of time*. This is important. Back to "the post":time, the feeling of accomplishment gives you encouragement to continue. * Do not get bogged down in meaning less pieces of code. An example would be database versioning. Sure it's cool, but playing with "DBIx::Class::Schema::Versioned":http://search.cpan.org/~ribasushi/DBIx-Class-0.08102/lib/DBIx/Class/Schema/Versioned.pm for hours and hours and wondering why it just wouldn't "work". I then discovered at the bottom of the POD that it doesn't fully work with "SQLite":http://www.sqlite.org. Great. I'd been motivated to once again work on my project and I picked the *wrong* tasks to work on. Instantly killed my *productive mood*. These ideas are nothing new or groundbreaking and there are certainly others throughout the years that have written on this subject. This was written to myself as my quest to restore productivity to personal projects is ongoing. [time]http://startup.partnerup.com/2009/04/14/time-management-tips-get-things-done-and-boost-your-productivity/

Better git conflict resolution between binaries with --theirs and --ours

Tue, 24 Feb 2009 00:00:00 +0000

Whichever framework I use ("Catalyst":http://www.catalystframework.org, "Django":http://www.djangoproject.com, etc.) for personal projects, I always develop with a local "SQLite":sqlite database. From time to time they can get out of sync between branches. While working on a project recently, I ran into a "Git":git conflict between a "SQLite":sqlite database on @master@ and an older copy on a development branch. After checking out the development branch, I ran the merge:

 $ git checkout dev_branch
 $ git merge master

"Git":git notified me that I had a conflicting "SQLite":sqlite file. I posed the question on the "Git":git irc channel and was told (thanks doener) to use the @--theirs@ flag for @git checkout@.

 $ git checkout --theirs filename(s)

This says that the file(s) being merged in take precedence over the file(s) in place in the branch, thus running this will overwrite the file(s) on the branch. @--ours@ is the opposite in that the file(s) on the branch take precedence in this merge. More information can be found in the "git-checkout docs":http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html. I was then able to complete the merge:

 $ git add umerged_file(s)
 $ git commit

I'm not sure which version of "Git":git this was made available in, but having just upgraded for this feature it is available in the latest stable version (currently "1.6.1.3":http://www.kernel.org/pub/software/scm/git/git-1.6.1.3.tar.bz2). In the old version I was running (1.6.0.2) @"git reset -- file; git checkout MERGE_HEAD -- file"@ would have done the same. [git]http://www.git-scm.org [sqlite]http://www.sqlite.org