Yup. Creature of habit and back in the day Tomaz preferred single commits. On Thu, Oct 13, 2016 at 2:49 PM, anthony shaw <anthony.p.s...@gmail.com> wrote:
> My question was more why do you need to rebase at all? Just to squash > the commits for the PR? > > On Fri, Oct 14, 2016 at 8:48 AM, Eric Johnson > <erjoh...@google.com.invalid> wrote: > > Just a creature of habit and that was how I learned to squash. > > > > On Thu, Oct 13, 2016 at 2:46 PM, anthony shaw <anthony.p.s...@gmail.com> > > wrote: > > > >> 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 > >> <erjoh...@google.com.invalid> wrote: > >> > 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 > >> >> >>> > > >> >> >>> > >> >> >> > >> >> >> > >> >> > >> >
