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
>> >> >>> >
>> >> >>>
>> >> >>
>> >> >>
>> >>
>>

Reply via email to