Re: Re* git pull --rebase should use fast forward merge if possible

2016-12-01 Thread Stefan Beller
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

Re: Re* git pull --rebase should use fast forward merge if possible

2016-12-01 Thread Junio C Hamano
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 && >>

Re: Re* git pull --rebase should use fast forward merge if possible

2016-12-01 Thread Stefan Beller
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

Re* git pull --rebase should use fast forward merge if possible

2016-12-01 Thread Junio C Hamano
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

Re: git pull --rebase should use fast forward merge if possible

2016-06-29 Thread Junio C Hamano
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

Re: git pull --rebase should use fast forward merge if possible

2016-06-29 Thread Stefan Beller
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

Re: git pull --rebase should use fast forward merge if possible

2016-06-29 Thread Junio C Hamano
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

Re: git pull --rebase should use fast forward merge if possible

2016-06-29 Thread Junio C Hamano
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

git pull --rebase should use fast forward merge if possible

2016-06-29 Thread neuling
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