Re: Another git question

[Tait <gnu...@t4...>]

> ...
> What I'm trying to do is convert my usual workflow into git-speak.
> New features are developed and tested against the development branch.
> If they pan out, I go back and apply them to the stable branch.
> ...
> Is there some totally different recommended way to replicate
> changes previously made to one branch and apply them to a 
> different branch?

You want to use merge as much as possible, but even when that
doesn't work, I think you'll find "cherry-pick" is a much easier
choice than format-patch/am.

What I'd try to do, were I you, is branch each new feature off
the development branch. The feature-branch can be developed and
thrown away or merged back into the development branch. At some
point the development branch looks okay, and it gets merged back
into master. Rinse, repeat.

Implied in this flow is that everything that ultimately survives
on the development branch wants to be part of master. I don't
know how true that is.

If you want to selectively choose commits to copy from the
development branch to master, then check out master (the
destination branch), open up gitk to identify the commits you
want, and "git cherry-pick <sha1>" to copy those commits from
where they are onto master. This is essentially a one-commit
"rebase" operation. It's less preferred than merge, because you
have two different SHA1 that reference the same changes in
different places now, and that's more potential for conflict in
a future merge, although git is pretty good about recognizing
it's the same thing. But in any case, it's much easier than the
round-trip to *.patch and back when you already have the source
data in the repository.

The cherry-pick might conflict, especially with the ChangeLog.
Git will add the usual conflict markers, but it should be easy
to resolve, then "git add" the ChangeLog and "git commit" will
be pre-populated with the author/commit information. (I think
there's a "cherry-pick --abort" to back up and pretend you were
never doing the cherry-pick in the first place.)