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

[Jonathan Poole]

I’ve adopted the git-flow branching model at home, and work.  With little hesitations now, we are growing to love it.  Merging and rebasing is fairly straightforward, but I don’t know what kind of code your writing that would not inherit the model successfully.


On Apr 15, 2014, at 7:28 PM, Chris Frey <cdfrey at foursquare.net> wrote:

> 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
> 
> 
> 
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org