Yup. Creature of habit and back in the day Tomaz preferred single commits.
On Thu, Oct 13, 2016 at 2:49 PM, anthony shaw
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
> wrote:
> > Just a
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
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
> wrote:
>
>> ok. Now I'm curious
Just a creature of habit and that was how I learned to squash.
On Thu, Oct 13, 2016 at 2:46 PM, anthony shaw
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, O
I always interactively rebase. Gives me more control, never fails me.
Empty rebase mostly means the changes are already applied through some
other means.
Best,
Allard
On Thu, Oct 13, 2016, 23:46 anthony shaw wrote:
> ok. Now I'm curious why you have to do an interactive rebase in the
> first
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
wrote:
> No, on rebase, your commit just disappeared!
>
> On Thu, Oct 13, 2016 at 2:41 PM,
No, on rebase, your commit just disappeared!
On Thu, Oct 13, 2016 at 2:41 PM, anthony shaw
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 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 wrote:
> Yup, I kicked the can down the road. My next merge for #901 had the same
> issue.
>
> On Thu, Oct 13, 2016 at
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 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 r
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 w
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
Hi Eric,
The downside is that we'll get the git commit history from the
original authors without the ("with xxx") signoff tag, but instead
that's replaced with a merge commit saying "merging GITHUB-123 by
blah", the merge commit has the parents of the original commits and as
long as we fetch the r
I agree that git-am can be a pain.
What I like about using it though, is that history is more forthcoming
about original author versus us showing up all the time.
"""
commit 065d1919d8cd1e651b92af6220b1408437b07563
Merge: 4897933 0d1a9d2
Author: Anthony Shaw
Date: Wed Oct 12 09:41:47 2016 +110
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 s
13 matches
Mail list logo
