# Default behavior of git pull

4 messages from 2021-05-31 to 2021-07-14. Participants: Mathias Kunter, Bagas Sanjaya, Felipe Contreras.
Thread: https://gitlist.dev/t/55809

## Mathias Kunter, 2021-05-31 09:18

Subject: Default behavior of git pull
Message-ID: <7a97ac78-f405-2dca-2998-f03637cc8255@gmail.com>
URL: https://gitlist.dev/e/7a97ac78-f405-2dca-2998-f03637cc8255%40gmail.com

```
Wouldn't it make sense if "git pull" would by default also pull the 
branch with the same name from the remote, in case no upstream is 
configured?

If I can push to a remote with a simple "git push", then I'd also expect 
to be able to pull from that same remote with a simple "git pull".

Does anything speak against this?

Example:

   git clone $url
   git checkout -b fix-1
   # do commits
   git push           # push to origin/fix-1 (works)
   git push origin    # push to origin/fix-1 (works)
   # other people push to origin/fix-1
   git pull           # pull from origin/fix-1 (fails)
   git pull origin    # pull from origin/fix-1 (fails)

```

## Bagas Sanjaya, 2021-05-31 11:27

Subject: Re: Default behavior of git pull
Message-ID: <92682abb-3062-4613-399d-a3279afb8f0b@gmail.com>
URL: https://gitlist.dev/e/92682abb-3062-4613-399d-a3279afb8f0b%40gmail.com
In-Reply-To: <7a97ac78-f405-2dca-2998-f03637cc8255@gmail.com>

```
Hi Mathias,

On 31/05/21 16.18, Mathias Kunter wrote:
> Wouldn't it make sense if "git pull" would by default also pull the 
> branch with the same name from the remote, in case no upstream is 
> configured?
> 
> If I can push to a remote with a simple "git push", then I'd also expect 
> to be able to pull from that same remote with a simple "git pull".
> 
> Does anything speak against this?
> 
> Example:
> 
>    git clone $url
>    git checkout -b fix-1
>    # do commits
>    git push           # push to origin/fix-1 (works)
>    git push origin    # push to origin/fix-1 (works)
>    # other people push to origin/fix-1
>    git pull           # pull from origin/fix-1 (fails)
>    git pull origin    # pull from origin/fix-1 (fails)

IME, I did git fetch first before I did git pull, unless I have repos 
that I didn't intentionally want to contribute to (just collecting 
them). When I choose to work, I always create a branch, then submit 
PR/patches from that against mainline.

Since you do centralized workflow like above, I advise you to integrate 
from remote with git fetch + git merge.

And you asked whether plain git pull can work. It is yes, provided that 
you don't do any local work on remote-tracking branches (such as 
mainline or hotfixes).

-- 
An old man doll... just what I always wanted! - Clara

```

## Mathias Kunter, 2021-05-31 13:03

Subject: Re: Default behavior of git pull
Message-ID: <a5dfd06c-b3cf-2d30-2e57-d0706b75a908@gmail.com>
URL: https://gitlist.dev/e/a5dfd06c-b3cf-2d30-2e57-d0706b75a908%40gmail.com
In-Reply-To: <92682abb-3062-4613-399d-a3279afb8f0b@gmail.com>

```
Hi Bagas,

thanks for your reply.

> Since you do centralized workflow like above, I advise you to integrate
> from remote with git fetch + git merge.

I'm aware of this. However, if I know that I didn't commit any changes 
to the local branch since I last pushed it (as in the given example), 
then it should be possible to use a simple "git pull" IMHO.

It seems unnecessarily complex to me that users would have to use "git 
pull origin fix-1" in this situation, when a simple "git pull" could 
also work.


Am 31.05.21 um 13:27 schrieb Bagas Sanjaya:
> Hi Mathias,
> 
> On 31/05/21 16.18, Mathias Kunter wrote:
>> Wouldn't it make sense if "git pull" would by default also pull the 
>> branch with the same name from the remote, in case no upstream is 
>> configured?
>>
>> If I can push to a remote with a simple "git push", then I'd also 
>> expect to be able to pull from that same remote with a simple "git pull".
>>
>> Does anything speak against this?
>>
>> Example:
>>
>>    git clone $url
>>    git checkout -b fix-1
>>    # do commits
>>    git push           # push to origin/fix-1 (works)
>>    git push origin    # push to origin/fix-1 (works)
>>    # other people push to origin/fix-1
>>    git pull           # pull from origin/fix-1 (fails)
>>    git pull origin    # pull from origin/fix-1 (fails)
> 
> IME, I did git fetch first before I did git pull, unless I have repos 
> that I didn't intentionally want to contribute to (just collecting 
> them). When I choose to work, I always create a branch, then submit 
> PR/patches from that against mainline.
> 
> Since you do centralized workflow like above, I advise you to integrate 
> from remote with git fetch + git merge.
> 
> And you asked whether plain git pull can work. It is yes, provided that 
> you don't do any local work on remote-tracking branches (such as 
> mainline or hotfixes).
> 

```

## Felipe Contreras, 2021-07-14 15:31

Subject: RE: Default behavior of git pull
Message-ID: <60ef0352705ca_261120866@natae.notmuch>
URL: https://gitlist.dev/e/60ef0352705ca_261120866%40natae.notmuch
In-Reply-To: <7a97ac78-f405-2dca-2998-f03637cc8255@gmail.com>

```
Hi Mathias,

I hadn't seen this mail.

Mathias Kunter wrote:
> Wouldn't it make sense if "git pull" would by default also pull the 
> branch with the same name from the remote, in case no upstream is 
> configured?

I agree.

In fact, back in 2014 I wrote a builtin called `git update` to fix all
the problems with `git pull`. That command worked exactly as you
suggest.

I recently sent a new proposal for `git update` [1] asking for feedback on
how different arguments should be handled. Nobody has suggested
anything.

For the next iteration I will implement what you suggested, in my
opinion it makes sense.

Cheers.

[1] https://lore.kernel.org/git/20210705123209.1808663-1-felipe.contreras@gmail.com/

-- 
Felipe Contreras

```