Ah ok, what I do usually is to rebase current master on top of my PR
branch, then merge to master for pushing the change.
- Henry
On Thu, Jan 15, 2015 at 12:26 PM, Aljoscha Krettek wrote:
> I meant rebasing the commits in a PR on top of the current master. So
> that you don't need a merge commit
I meant rebasing the commits in a PR on top of the current master. So
that you don't need a merge commit and the history looks linear.
On Thu, Jan 15, 2015 at 9:17 PM, Henry Saputra wrote:
> Ah, so you were rebasing against a PR branch?
>
> - Henry
>
> On Thu, Jan 15, 2015 at 10:42 AM, Aljoscha K
Ah, so you were rebasing against a PR branch?
- Henry
On Thu, Jan 15, 2015 at 10:42 AM, Aljoscha Krettek wrote:
> But you don't lose the original author information when rebasing.
>
> On Thu, Jan 15, 2015 at 7:28 PM, Ted Dunning wrote:
>> On Thu, Jan 15, 2015 at 10:18 AM, Henry Saputra
>> wrot
But you don't lose the original author information when rebasing.
On Thu, Jan 15, 2015 at 7:28 PM, Ted Dunning wrote:
> On Thu, Jan 15, 2015 at 10:18 AM, Henry Saputra
> wrote:
>
>> I do use Git rebase before pushing my own PRs.
>>
>> So, no one uses the script to merge PRs?
>>
>> I will send up
On Thu, Jan 15, 2015 at 10:18 AM, Henry Saputra
wrote:
> I do use Git rebase before pushing my own PRs.
>
> So, no one uses the script to merge PRs?
>
> I will send update to the script to fix it.
>
Manual rebase is a good standard of practice. I like looking in detail at
what I am doing.
I use the tools to merge other people PRS bc it is useful to maintain
original author info.
I do use Git rebase before pushing my own PRs.
So, no one uses the script to merge PRs?
I will send update to the script to fix it.
- Henry
On Thursday, January 15, 2015, Fabian Hueske wrote:
> Same h
Same here
On Jan 15, 2015 5:44 PM, "Alexander Alexandrov" <
alexander.s.alexand...@gmail.com> wrote:
> +1 for "git rebase"
>
> 2015-01-15 17:39 GMT+01:00 Aljoscha Krettek :
>
> > No, I always do a manual "git rebase". Makes for a cleaner history. And I
> > have more control over how things are mer
+1 for "git rebase"
2015-01-15 17:39 GMT+01:00 Aljoscha Krettek :
> No, I always do a manual "git rebase". Makes for a cleaner history. And I
> have more control over how things are merged and squashed.
> On Jan 15, 2015 5:27 PM, "Henry Saputra" wrote:
>
> > Oh, so you guys do not use the tools/
No, I always do a manual "git rebase". Makes for a cleaner history. And I
have more control over how things are merged and squashed.
On Jan 15, 2015 5:27 PM, "Henry Saputra" wrote:
> Oh, so you guys do not use the tools/merge_pull_request.sh script to merge
> PRs?
>
>
> - Henry
>
> On Thu, Jan 15
Oh, so you guys do not use the tools/merge_pull_request.sh script to merge PRs?
- Henry
On Thu, Jan 15, 2015 at 6:45 AM, Robert Metzger wrote:
> Hi,
> I think I remember something like this. I don't really use the tool.
> Since I'm using the zsh I always know in which branch I am, so its no big
Hi,
I think I remember something like this. I don't really use the tool.
Since I'm using the zsh I always know in which branch I am, so its no big
deal if the tool leaves me in a detached branch.
Maybe we can think about removing the tool from the repo .. I don't know
anybody using it.
On Thu, Ja
Hi All,
In the merge tool python, the command "git rev-parse HEAD" actually
returns you to detached HEAD state after merging PR.
Anyone else seen this behavior?
- Henry
12 matches
Mail list logo
