Re: Default behavior of git pull

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux