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 <> 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 <>
> 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<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.
> >
> >
> > 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 -
> >
> > 8437b07563
> >
> > Ant
> >

Reply via email to