From: Phil Hord <hordp@cisco.com>
To: Eric Blake <eblake@redhat.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: git push vs. slow connection times - local commit resolution is too late
Date: Sat, 16 Jul 2011 00:38:45 -0400 [thread overview]
Message-ID: <4E2115D5.4010002@cisco.com> (raw)
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
next prev parent reply other threads:[~2011-07-16 4:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-14 13:22 git push vs. slow connection times - local commit resolution is too late Eric Blake
2011-07-16 4:38 ` Phil Hord [this message]
2011-07-16 12:52 ` Andreas Schwab
2011-07-17 19:46 ` Phil Hord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E2115D5.4010002@cisco.com \
--to=hordp@cisco.com \
--cc=eblake@redhat.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.