Re: Another git question

[Ethan A M. <sf...@us...>]

On Friday, November 17, 2017 2:38:58 PM PST Tait wrote:
> > ...
> > 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.

Thanks for the pointer.  I will look into that next.

> 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.

That would be a drastically different work flow.

> 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.

Under the model we have been using, most of the changes to the
development branch never appear in the current stable branch. 
Instead at some point we create a new stable branch and essentially
freeze it except for bugfixes.  OK that's a bit of an overstatement. 
Some relatively self-contained features can be added to the current
stable branch, but normally only after they've been in the
development branch for a while to shake out problems.
That's the part I'm trying to figure out right now. 

Are you thinking there is (or could be) a "master" branch that is
different from "development"?  What would that gain us?

> 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. 

There is no separate "master".  Should there be?

> 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.

This is all new to me, but I think that the merge you describe is in
a sense the  opposite of what I want to do.
I don't want to take (cherry-pick?) commits from a separate branch
and merge them into what will be the main trunk going forward. 
Instead I want to copy a few commits that are already part of the
main trunk and graft them back onto an old branch that will never
be merged.  Am I describing this correctly?

The man page for git-cherry-pick does not show any examples
of this, or at least I don't recognize how the examples it does show
would apply to this case.

> The cherry-pick might conflict, especially with the ChangeLog.
> Git will add the usual conflict markers, but it should be easy
> to resolve,  

Hmm. What I've seen so far is that if it fails I don't get conflict
markers.  I get error messages like "index match failed" and a
dump of the original patch.  But I've tried enough things at this
point that they blur together in my mind. 

> 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.)

I know how to edit + add  + commit + re-edit + commit --amend
to fix up the conflicts. 
I was kind of hoping there were git tricks to make it easier. 

	Ethan