# git push vs. slow connection times - local commit resolution is too late 4 messages from 2011-07-14 to 2011-07-17. Participants: Eric Blake, Phil Hord, Andreas Schwab. Thread: https://gitlist.dev/t/27815 ## Eric Blake, 2011-07-14 13:22 Subject: git push vs. slow connection times - local commit resolution is too late Message-ID: <4E1EEDAA.1000204@redhat.com> URL: https://gitlist.dev/e/4E1EEDAA.1000204%40redhat.com ``` I've been bitten several times by this bug now, so I'll report it in the hopes that someone knows what to do to patch it. Scenario - I have a remote repository that takes on the order of 10 seconds to connect to, for any operation like 'git push'. I know that there is a lag, so I intentionally have two terminals open, both visiting the same directory, one for interaction with the remote, and the other for acting on the local repository, with the hope that I can do useful work in the second terminal rather than idly waiting on the lag in the first terminal. In the middle of rebasing a patch series, where I want to incrementally push the patches that I have gotten through so far, I used the following steps: On the remote-interaction terminal, I push the current state of my tree: git push remote HEAD:master On the local-interaction terminal, I move on to the next patch: git rebase --continue then, to my horror, I find out that the commit I'm working on locally has already been pushed! Why? Because 'git push remote HEAD:master' does not determine which commit 'HEAD' refers to until _after_ it has established a connection to remote, but the stupid 10-second lag was long enough that my actions in my second terminal have changed HEAD in the meantime. I would really love it if 'git push' would resolve all local references _prior_ to trying to connect to the remote server, rather than waiting until after the connection. That way, my remote-interaction terminal can truly be a type-it-and-forget-it terminal, where the push action I requested reflects the state of the tree at the time I requested it, rather than picking up changes made later in another terminal. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org ``` ## Phil Hord, 2011-07-16 04:38 Subject: Re: git push vs. slow connection times - local commit resolution is too late Message-ID: <4E2115D5.4010002@cisco.com> URL: https://gitlist.dev/e/4E2115D5.4010002%40cisco.com In-Reply-To: <4E1EEDAA.1000204@redhat.com> ``` On 07/14/2011 09:22 AM, Eric Blake wrote: > I've been bitten several times by this bug now, so I'll report it in the > hopes that someone knows what to do to patch it. > > Scenario - I have a remote repository that takes on the order of 10 > seconds to connect to, for any operation like 'git push'. I know that > there is a lag, so I intentionally have two terminals open, both > visiting the same directory, one for interaction with the remote, and > the other for acting on the local repository, with the hope that I can > do useful work in the second terminal rather than idly waiting on the > lag in the first terminal. > > In the middle of rebasing a patch series, where I want to incrementally > push the patches that I have gotten through so far, I used the following > steps: > > On the remote-interaction terminal, I push the current state of my tree: > git push remote HEAD:master > > On the local-interaction terminal, I move on to the next patch: > git rebase --continue > > then, to my horror, I find out that the commit I'm working on locally > has already been pushed! Why? Because 'git push remote HEAD:master' > does not determine which commit 'HEAD' refers to until _after_ it has > established a connection to remote, but the stupid 10-second lag was > long enough that my actions in my second terminal have changed HEAD in > the meantime. > > I would really love it if 'git push' would resolve all local references > _prior_ to trying to connect to the remote server, rather than waiting > until after the connection. That way, my remote-interaction terminal > can truly be a type-it-and-forget-it terminal, where the push action I > requested reflects the state of the tree at the time I requested it, > rather than picking up changes made later in another terminal. I agree with your suggestion. But as a quick fix, can you do this? git push remote $(cat .git/HEAD):master Damned inconvenient, though. Phil ``` ## Andreas Schwab, 2011-07-16 12:52 Subject: Re: git push vs. slow connection times - local commit resolution is too late Message-ID: URL: https://gitlist.dev/e/m2oc0uz8uh.fsf%40igel.home In-Reply-To: <4E2115D5.4010002@cisco.com> ``` Phil Hord writes: > I agree with your suggestion. But as a quick fix, can you do this? > git push remote $(cat .git/HEAD):master You mean $(git rev-parse HEAD), don't you? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ``` ## Phil Hord, 2011-07-17 19:46 Subject: Re: git push vs. slow connection times - local commit resolution is too late Message-ID: <4E233C14.6080309@cisco.com> URL: https://gitlist.dev/e/4E233C14.6080309%40cisco.com In-Reply-To: ``` Andreas Schwab helpfully chimed in > Phil Hord writes: > > > I agree with your suggestion. But as a quick fix, can you do this? > > git push remote $(cat .git/HEAD):master > > You mean $(git rev-parse HEAD), don't you? Yes, I do. :-) But I don't use it enough to remember it, and the man pages are not cross-referenced well enough for me. So I shrugged. Thanks for helping me out. Phil ```