Commiting changes onto more than one branch

[Mike Jarmy <mjarmy@gmail.com>]

Hi,

At my day job, I'm doing the groundwork for recommending that we
switch to a DVCS from a proprietary centralized VCS.  I find git's
branching ability very compelling, and I think we would use it
extensively.  I work on a very large project (many thousands of files)
that has been around for many years, and has had several different
releases.  Right now, each release has its own top level directory,
but I'd like to change that so we use branches instead, out of one
great big git repository.  My plan is to set up the repository such
that the initial state at switchover will have a branch for the
current state of each of our releases.  Lets say that the branches for
each release are called v1, v2, etc.

My question is this:  How do I manage a checkin for a bugfix that
affects, say, only branches v3, v4, and v5?

Suppose that I checkout the v3 branch, and fix the bug by editing
several different files.  (Lets assume for now that the files in
question have not diverged between any of the 3 branches, even though
tons of other files have changed).  How do I commit the bugfix into
all of v3, v4 and v5?  Clearly, merging the branches together would be
bad.  So I think what I should do is perform 3 different commits, but
I'm not quite sure how to juggle the git index (or stash or whatever)
to accomplish this.  This may be a really obvious question, but I'm a
confused git newbie.

Also, even though I may need to do 3 commits, it would be nice if the
commits were related together in some way, since in a sense they
represent only one action (namely, fixing the bug).  Is there a way to
do that, so that its clear in gitk that it was really one unified
thing?  The very worst thing about our current VCS is that it has no
concept of a 'commit', only individual file histories.  Git would fix
that for us, but it would be nirvana if we could group commits for a
given bugfix across branches somehow, while not merging the branches
together.

One last question -- lets make the problem slightly more complicated
by specify that some of the edited files changed between, say, v4 and
v5.  I know how to handle a simple merge conflict in git, but is there
anything different about my multi-branched, grouped-together case
here?  The answer to this question may be obvious once I understand
how to do the simpler, unconflicting checkin.

Thanks,
Mike Jarmy