On Thu, Dec 1, 2016 at 10:50 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Thu, Dec 1, 2016 at 9:59 AM, Junio C Hamano wrote:
>>
>>> +test_expect_success '--rebase fast forward' '
>>> + git reset --hard before-rebase &&
>>> + git checkout -b ff &&
>>> + echo another
Stefan Beller writes:
> On Thu, Dec 1, 2016 at 9:59 AM, Junio C Hamano wrote:
>
>> +test_expect_success '--rebase fast forward' '
>> + git reset --hard before-rebase &&
>> + git checkout -b ff &&
>> + echo another modification >file &&
>> + git commit -m third file &&
>>
On Thu, Dec 1, 2016 at 9:59 AM, Junio C Hamano wrote:
> +test_expect_success '--rebase fast forward' '
> + git reset --hard before-rebase &&
> + git checkout -b ff &&
> + echo another modification >file &&
> + git commit -m third file &&
> +
> + git checkout to-rebas
Junio C Hamano writes:
> die_no_merge_candidates() would have triggered, I would imagine.
>
> Note that I won't be applying this without test updates and proper log
> message,
> so no need to worry about the style yet ;-)
This time with a bit of explanation in the log and a trivial test.
I am
On Wed, Jun 29, 2016 at 1:40 PM, Stefan Beller wrote:
>> + merge_head = lookup_commit_reference(merge_heads.sha1[0]);
>
> The crashes for merge_heads.nr == 0.
> (I did not inspect code further up if this is caught before, I think
> it would trigger if
> you and the remote are on an i
On Wed, Jun 29, 2016 at 10:23 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> Is it possible to change the behavior of "git pull
>>> --rebase=true|preserve|interactive" to use a fast forward merge if the
>>> remote branch is ahead and the local branch contains no new commits?
>>
>> Inter
Junio C Hamano writes:
>> Is it possible to change the behavior of "git pull
>> --rebase=true|preserve|interactive" to use a fast forward merge if the
>> remote branch is ahead and the local branch contains no new commits?
>
> Interesting. I do not think of a reason why we shouldn't.
>
> If w
neul...@dakosy.de writes:
> since I have added "pull.rebase=preserve" to my global configuration I
> wonder why "git pull" also trys to rebase if a fast forward merge is
> possible.
>
> A fast forward merge would speed up every pull if your local branch
> contains no new commits and the remote
Hi,
since I have added "pull.rebase=preserve" to my global configuration I
wonder why "git pull" also trys to rebase if a fast forward merge is
possible.
A fast forward merge would speed up every pull if your local branch
contains no new commits and the remote branch is ahead. The result wou
9 matches
Mail list logo