* Default behavior of git pull @ 2021-05-31 9:18 Mathias Kunter 2021-05-31 11:27 ` Bagas Sanjaya 2021-07-14 15:31 ` Felipe Contreras 0 siblings, 2 replies; 4+ messages in thread From: Mathias Kunter @ 2021-05-31 9:18 UTC (permalink / raw) To: Git Mailing List 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) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Default behavior of git pull 2021-05-31 9:18 Default behavior of git pull Mathias Kunter @ 2021-05-31 11:27 ` Bagas Sanjaya 2021-05-31 13:03 ` Mathias Kunter 2021-07-14 15:31 ` Felipe Contreras 1 sibling, 1 reply; 4+ messages in thread From: Bagas Sanjaya @ 2021-05-31 11:27 UTC (permalink / raw) To: Mathias Kunter, Git Mailing List 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Default behavior of git pull 2021-05-31 11:27 ` Bagas Sanjaya @ 2021-05-31 13:03 ` Mathias Kunter 0 siblings, 0 replies; 4+ messages in thread From: Mathias Kunter @ 2021-05-31 13:03 UTC (permalink / raw) To: Bagas Sanjaya, Git Mailing List 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). > ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: Default behavior of git pull 2021-05-31 9:18 Default behavior of git pull Mathias Kunter 2021-05-31 11:27 ` Bagas Sanjaya @ 2021-07-14 15:31 ` Felipe Contreras 1 sibling, 0 replies; 4+ messages in thread From: Felipe Contreras @ 2021-07-14 15:31 UTC (permalink / raw) To: Mathias Kunter, Git Mailing List 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-07-14 15:31 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-31 9:18 Default behavior of git pull Mathias Kunter 2021-05-31 11:27 ` Bagas Sanjaya 2021-05-31 13:03 ` Mathias Kunter 2021-07-14 15:31 ` Felipe Contreras
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).