[kwlug-disc] Advanced(?) Git usage question

[Chris Frey]

On Thu, Apr 10, 2014 at 09:34:00AM -0400, Adam Glauser wrote:
> Your process is the one I would be inclined to use too. I do try to avoid
> cherry-picking though. This is probably because cherry-pick changes could
> cause annoying merge conflict problems in Bazaar. Is this less of a problem
> in Git?

You would probably get a better answer on the git mailing list.  But
git has a number of merge algorithms and strategies and options, which
seem to work fairly well.

If you try cherry-picking a commit that has already been merged or
cherry-picked, you'll get an error that the commit is empty, because
the change is already in the tree, and there's nothing to apply.

I think the same kind of logic happens during the merge as well.

I'm fairly conservative with merges because I'm the main programmer on
my projects rather than a puller of other people's commits.  So I
tend to use branches for private development of new features, rebasing
them often until done, to keep up with other changes in mainline,
and then the merge is simply a fast-forward.

If I were in Linus's role, merge would be a lot more important, as well
as wanting clearly segregated definitions of who works where and when,
in the tree.



> I'm mostly basing this on the article
> http://wiki.monotone.ca/DaggyFixes/#index2h1.
> They make what seem like good arguments for this approach.

It seems that the key sentence in that page is:

	"* unlike a development branch, you don't intend to ever merge
		a release branch back with mainline (where it would
		eventually pick up the fix)."

In this case, cherry-pick is the obvious choice.

There is also this paragraph which I find worth some discussion:

	"Although not drawn here, you can just as readily see that any
	other branches which diverged above B don't need a fix, because
	the bug was introduced later. If some of those were development
	branches that had propagated from mainline to them, and some
	of those propagates included B, then those branches would also
	need the fix. This knowledge is the benefit of identifying B as
	the source of the bug, which you might have needed to do anyway
	regardless of where the fix was applied. Making sure to apply
	the daggy fix at F2 means that you automatically get the same
	benefit for knowledge of what has also inherited the fix."

Personally, I like keeping track of things in one place, with the hope
that I can soon safely forget about them.  And for me, the main place
that I can forget about stuff is in master.

In other words, once it is in master, it should be stable, tested code
that is as good as I can make it.  And if I find a bug, I want the fix
in master as soon as possible, so I can also forget about it as soon as
possible, and consider it fixed and in the history of the project.

I may have up to a dozen different features in progress at a time,
each on different branches, and most of them diverging from master.
All of these track master in the sense that I rebase them regularly
until they are done.  A new feature never has a merge commit when
merged into master, since it will be merely a fast-forward.

Assuming this workflow for new features, we have two methods for managing
bugfixes:

	1) fix master, cherry-pick into release branches

	2) branch from bug commit, commit the fix, and merge into
		master and release branches

But never do we want to merge our bugfix into our development branches,
because we're rebasing anyway, and it would just make a maze of merges
that would be hard to follow later.

So I don't see a lot of difference between 1 and 2 above, as long as
the bugfix has a detailed commit message and references the commit
where the bug was found.  It would probably be easier to follow the
history in an english commit message than trying to remember the
right git command to view the branching links.

- Chris