From: Jeff King <peff@peff.net>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] push: give early feedback
Date: Mon, 24 Jun 2013 15:39:24 -0400 [thread overview]
Message-ID: <20130624193924.GA27344@sigill.intra.peff.net> (raw)
In-Reply-To: <CALkWK0mEWkXpsaUtMLc4r6vufDdSSdsX_PARwmObCSPW1mgAmQ@mail.gmail.com>
On Tue, Jun 25, 2013 at 12:54:17AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Leaving aside the transport API for a minute, you are always going to
> > have this lack-of-information versus time problem. A refspec like ":"
> > says nothing particularly useful, but it can only be expanded once
> > contact is made with the other side (which is what takes time).
>
> Right, and ':' is special in that aspect; it does not warrant slowing
> down the expansion of refs/heads/*, for instance. Besides, I suspect
> ':' can be resolved much faster than using push --dry-run.
I think ":" (or "push.default=matching") is the only thing that needs to
actually contact the other side to decide which refs _might_ be pushed.
But to know which refs would _actually_ be pushed (and which ones would
be fast-forwards), you need to know where the remote refs are, which
involves contacting the other side.
In both cases, you could potentially fake it with remote-tracking refs,
if they are available (after all, that is what "git status" is reporting
with its ahead/behind counts, so there is certainly precedent). But it
is important to note that what you see in the preview is not necessarily
what is about to happen in the push, as we get new information on the
remote tips during the push.
> > Yes. I do not have any interest in such an interactive push, but the
> > point is that a potential first step to any confirmation scheme, no
> > matter what you want it to look like, is a hook. You don't seem to want
> > a confirmation scheme, though, due to the wait (and I cannot blame you,
> > as I would not want it either; but then I would not want the extra
> > refspec message you propose, either).
>
> I'm trying to figure out how to determine what a push will do without
> actually pushing (or --dry-run, which is almost as expensive). You
> might like to put that information in your prompt instead of stdout,
> but do you agree that the information is worth getting?
To me personally, no, it is not interesting. But that does not mean it
is not interesting to others. I didn't mean to dissuade you from
pursuing the topic, but rather only to qualify the my statements with "I
am probably not the user you are targeting with this feature".
-Peff
prev parent reply other threads:[~2013-06-24 19:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 17:41 [PATCH] push: give early feedback Ramkumar Ramachandra
2013-06-24 18:04 ` Fredrik Gustafsson
2013-06-24 18:24 ` Junio C Hamano
2013-06-24 18:28 ` Jeff King
2013-06-24 18:42 ` Ramkumar Ramachandra
2013-06-24 18:55 ` Jeff King
2013-06-24 19:24 ` Ramkumar Ramachandra
2013-06-24 19:39 ` Jeff King [this message]
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=20130624193924.GA27344@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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 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).