git pull --rebase=preserve is always rebasing something, even on up-to-date branch

git pull --rebase=preserve is always rebasing something, even on up-to-date branch

[Mikhail Matrosov]

Please try the following:

mmatrosov@Mikhail-PC:~/test$ git init --bare server
Initialized empty Git repository in /home/mmatrosov/test/server/
mmatrosov@Mikhail-PC:~/test$ git clone server local
Cloning into 'local'...
warning: You appear to have cloned an empty repository.
done.
mmatrosov@Mikhail-PC:~/test$ cd local
mmatrosov@Mikhail-PC:~/test/local$ echo a > a && git add . && git commit -m A
[master (root-commit) a34c21f] A
 1 file changed, 1 insertion(+)
 create mode 100644 a
mmatrosov@Mikhail-PC:~/test/local$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 205 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/mmatrosov/test/server
 * [new branch]      master -> master
mmatrosov@Mikhail-PC:~/test/local$ git pull
Already up-to-date.
mmatrosov@Mikhail-PC:~/test/local$ git pull --rebase=preserve
Rebasing (1/1)
Successfully rebased and updated refs/heads/master.

As you can see, running bare "git pull" just tells me everything is up
to date. However, running "git pull --rebase=preserve" triggers
rebasing of something. It wont be a problem if it didn't take
significant time (especially on Windows). Why this rebase happens? It
is completely redundant and slows down the pull operation. Looks like
a bug to me.

Note that it is important to me, because I want to set "git config
--global pull.rebase preserve". But because of this issue, pulling on
an up-to-date repository takes a lot of time. Which is very
frustrating.

Tested with:
* git version 2.19.0.windows.1 in Windows 10 Version 1803
* git version 2.7.4 in Ubuntu 16.04.3 LTS (inside WSL)

-----
Best regards, Mikhail Matrosov

Re: git pull --rebase=preserve is always rebasing something, even on up-to-date branch

[Johannes Schindelin]

Hi Mikhail,

On Mon, 17 Sep 2018, Mikhail Matrosov wrote:

> Please try the following:
> 
> mmatrosov@Mikhail-PC:~/test$ git init --bare server
> Initialized empty Git repository in /home/mmatrosov/test/server/
> mmatrosov@Mikhail-PC:~/test$ git clone server local
> Cloning into 'local'...
> warning: You appear to have cloned an empty repository.
> done.
> mmatrosov@Mikhail-PC:~/test$ cd local
> mmatrosov@Mikhail-PC:~/test/local$ echo a > a && git add . && git commit -m A
> [master (root-commit) a34c21f] A
>  1 file changed, 1 insertion(+)
>  create mode 100644 a
> mmatrosov@Mikhail-PC:~/test/local$ git push
> Counting objects: 3, done.
> Writing objects: 100% (3/3), 205 bytes | 0 bytes/s, done.
> Total 3 (delta 0), reused 0 (delta 0)
> To /home/mmatrosov/test/server
>  * [new branch]      master -> master
> mmatrosov@Mikhail-PC:~/test/local$ git pull
> Already up-to-date.
> mmatrosov@Mikhail-PC:~/test/local$ git pull --rebase=preserve
> Rebasing (1/1)
> Successfully rebased and updated refs/heads/master.
> 
> As you can see, running bare "git pull" just tells me everything is up
> to date. However, running "git pull --rebase=preserve" triggers
> rebasing of something.

This is most likely a `noop` command.

> It wont be a problem if it didn't take significant time (especially on
> Windows). Why this rebase happens? It is completely redundant and slows
> down the pull operation. Looks like a bug to me.

It is an implementation detail, and if you want to work on fixing it,
please let me know about your availability and C skill level.

> 
> Note that it is important to me, because I want to set "git config
> --global pull.rebase preserve".

Please note that `preserve` is on its way to deprecation, superseded by
`pull.rebase = merges`. Which may, or may not, share the performance
penalty you reported. Probably not, though.

Ciao,
Johannes

> But because of this issue, pulling on an up-to-date repository takes a
> lot of time. Which is very frustrating.
> 
> Tested with:
> * git version 2.19.0.windows.1 in Windows 10 Version 1803
> * git version 2.7.4 in Ubuntu 16.04.3 LTS (inside WSL)
> 
> -----
> Best regards, Mikhail Matrosov
>