How to automatically split git commits to separate changes to a single file

Question

I'm prettyd comfortable with Git, an I've been using it for over a year now. Better yet, I've finally convinced a client to switch to it! However, I'm just plain stuck as to how to accomplish what I'm about to describe, or if it's even possible. Even it it can be done, I wonder if it could be setting us up for a messed-up, unmanageable repository.

I have set up two branches of the code-base. One is "master" and the other is "prod". The HEAD of prod is always the latest code to deploy to production, and master is the main development branch.

Here's the problem, though: The client is converting from CVS and most of the developers are still getting used to git. Their CVS workflow involved tagging versions of individual files for production, then updating the servers using the tag. Unfortunately, this has led to sloppy practices like committing unrelated changes together and then tagging the files after-the-fact, and keeping lots of junk files in their main working tree, etc... and the devs want to know how they can do the following:

In their local repos, they hack and commit to their hearts' delight, then at the end of the day, be able to run a command that takes a list of files whose commits over the day get merged with their local prod - and only those files - even if those commits combine changes to other files.

I know how to split commits with git rebase --interactive, but I have no clue how I would automate splitting commits at all, never mind the way I want to.

I do realize the simplest thing would be to just tell them to switch the their prod branches, checkout the files from their master branches into the working tree then commit to prod. My problem with that is losing the history of their commits over the day.

Has anyone else out there tackled this with a script or something, or do I have to just goad the devs into better behavior - and risk them completely rejecting Git?

---

Here's the solution I finally cooked up. It's a simple shell script that seems to do exactly what I want, even if it's not the most elegant solution. I've only tested a few scenarios, but the file's change history is preserved and if the commits from the dev branch are later merged in whole git seems to do it cleanly!

#!/bin/sh
set -e
dest_branch=$1
file=$2
current_branch=$(git branch | sed 's/^\* //;/^\s/d')
( 
    set -e 
    git format-patch --stdout --full-index -M -C -B --ignore-if-in-upstream $dest_branch -- $file
    git checkout $dest_branch 
) | git am
git checkout $current_branch

Answer 1

Those developers still have a very "file-centric" vision instead of a "repository-centric" approach (based on revision for SVN or commits for Git)!
They need to read "What are the basic VCS concepts every developer should know?" ;)
(it is originally about ClearCase but still relevant for CVS users confronted to a DVCS)

That said, one way to bridge the gap in the particular scenario would be to:

• at the end of the day of hacking, create a special branch from the current HEAD
• make a final modification for only the right files (the one for the prod)
  The modification could be for instance some kind of special keyword extension, just for the sake of marking them as "to be merged to prod".
• merge that special branch to their local prod: in one commit, only the right files are merged.

That way, the history for those files is preserved.