On Fri, Dec 12, 2014 at 2:15 PM, Andrew Stitcher <[email protected]> wrote: > > On Thu, 2014-12-11 at 17:11 -0500, Darryl L. Pierce wrote: > > On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: > > > Rebasing and pushing is not a good option IMO. We have been using pull > requests from GitHub and pushing them through Apache. It's working very > well for us. > > > > > > Committing directly to Apachea may get you these issues. > > > > > > We can provide you guys more information on how we are doing on > activemq6 if you are interested. > > > > Additionally, while working on a task branch, to resynch with master do > > a rebase: > > > > $ rebase -i master > > > > rather than merging master down onto your task branch. I saw a *lot* of > > that while examining the merge commits. Rebasing is by far one of the > > most awesome features of git. > > I agree and disagree with this simplistic position. > > If (and only if) your task branch is yours and yours alone and no one > has ever relied on it then you can safely rebase it. Actually I find > that rebasing is a lot more useful to get my commits in a logical > sequence of smaller working commits (by using rebase -i). > > On the other hand merging topic branches into master is also perfectly > sensible to finish off work on a topic branch especially a long lived > one. > > A long lived topic branch will necessarily have some level of merging > from master to keep it up to date. > > On the other hand I agree that merging from master just before merging > to master is irritating and pointless.
So what was the right thing to do here? I have to admit I struggled a bit with the git portion of getting the whole thing landed. The changes were (mostly) isolated to a subdirectory, yet whatever git incantations I seemed to come up with forced me to painstakingly hand merge lots of conflicts over and over again. What I ended up doing was mostly stumbled into in an attempt to avoid all that grunge. --Rafael
