All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.