No, on rebase, your commit just disappeared! On Thu, Oct 13, 2016 at 2:41 PM, anthony shaw <anthony.p.s...@gmail.com> 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 <erjoh...@apache.org> 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 <erjoh...@apache.org> > 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 <to...@apache.org> 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 < > anthony.p.s...@gmail.com> > >>> 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 > >>> > > >>> > >> > >> >
