ok. Now I'm curious why you have to do an interactive rebase in the first place? That tool is kinda playing with fire unless you're working off a feature branch
On Fri, Oct 14, 2016 at 8:43 AM, Eric Johnson <[email protected]> wrote: > No, on rebase, your commit just disappeared! > > On Thu, Oct 13, 2016 at 2:41 PM, anthony shaw <[email protected]> > wrote: > >> "hard time merging"? let me guess, "patch does not apply"? This is my >> favourite error, so much so it's like a close family member. >> >> >> On Fri, Oct 14, 2016 at 2:42 AM, Eric Johnson <[email protected]> wrote: >> > Yup, I kicked the can down the road. My next merge for #901 had the same >> > issue. >> > >> > On Thu, Oct 13, 2016 at 8:19 AM, Eric Johnson <[email protected]> >> wrote: >> > >> >> Not sure if this related, but I had a hard time merging #856 in this >> >> morning. I was following my normal procedure using git-am, updating >> >> CHANGES.rst, then rebasing to squash into a single commit. Prior to >> rebase, >> >> I'd see 065d1919d8cd1e651b92af6220b1408437b07563 in my git-log. During >> >> rebase -i, I wouldn't see that commit in the list and if I proceeded >> with >> >> my squash, that commit would get dropped. >> >> >> >> So, I either made the problem worse by not rebasing and pushing two >> >> commits (one for #856 and one for updating changes), or I just kicked >> the >> >> can down the road. But maybe it'll be "fixed" for next committer? >> >> >> >> My git-foo isn't super strong and I'd welcome insight into how I >> could've >> >> cleaned it up with git commands. >> >> >> >> On Wed, Oct 12, 2016 at 9:53 AM, Tomaz Muraus <[email protected]> wrote: >> >> >> >>> I personally used all in the past (am, merge, apply-patch), depending >> on >> >>> the scenario of which one was easier to work with / apply (I a lot of >> >>> times >> >>> I also need to check out the original branch and do some merge foo so I >> >>> can >> >>> merge it cleanly into trunk). >> >>> >> >>> I do prefer am since it doesn't result in a merge commit which makes >> the >> >>> history look slightly nicer. >> >>> >> >>> Having said that, I'm fine with whatever approach is the easier to >> manage >> >>> for the person applying the patch as long as it meets this criteria: >> >>> >> >>> - Preserve original commit author (preserve original commits as the >> are) >> >>> - Commit(s) are signed off by the person applying the changes >> >>> - We can easily add "Closed #PRNUMBER" or similar message to the >> commit(s) >> >>> message >> >>> >> >>> Another option also is to try "git merge --no-commit" / "git merge >> >>> --squash", but we need to be careful with those so we don't rewrite >> >>> history >> >>> (apache git repo actually doesn't allow pushing that, but it can still >> be >> >>> annoying). >> >>> >> >>> On Tue, Oct 11, 2016 at 3:49 PM, anthony shaw < >> [email protected]> >> >>> wrote: >> >>> >> >>> > Hi, >> >>> > >> >>> > Our PR process (applies to committers but anyone else is welcome to >> >>> > weigh in) says to download the patch file from GitHub and apply the >> >>> > patch using the `git am` command. >> >>> > >> >>> > I find git am to be so fragile, typically I use the --3way flag to >> >>> > help it try and resolve conflicts but normally is just stumbles on >> the >> >>> > slightest issue. >> >>> > >> >>> > The new process I've been using is : >> >>> > >> >>> > git fetch https://github.com/<remote user>/libcloud >> >>> > <remote-branch>:github-<pr> >> >>> > git merge <github-pr> >> >>> > >> >>> > .. edit merge message to included Closes #PR >> >>> > >> >>> > Then push to apache trunk. >> >>> > >> >>> > An obvious advantage is that in GitHub the PRs show as merged. >> >>> > https://github.com/apache/libcloud/pull/899 >> >>> > >> >>> > The merge tool in git (instead of the patch) is so much more >> reliable. >> >>> > >> >>> > What do people think of this approach? Here is an example - >> >>> > https://github.com/apache/libcloud/commit/065d1919d8cd1e651b >> >>> 92af6220b140 >> >>> > 8437b07563 >> >>> > >> >>> > Ant >> >>> > >> >>> >> >> >> >> >>
