From: Christopher Tiwald <christiwald@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Clemens Buchacher <drizzd@aon.at>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
git@vger.kernel.org, peff@peff.net
Subject: Re: [PATCH] push: Provide situational hints for non-fast-forward errors
Date: Fri, 16 Mar 2012 13:20:13 -0400 [thread overview]
Message-ID: <20120316172013.GA8119@gmail.com> (raw)
In-Reply-To: <7v3998kb0x.fsf@alter.siamese.dyndns.org>
On Fri, Mar 16, 2012 at 05:03:58AM -0700, Junio C Hamano wrote:
> > We should not give advise_use_upstream if the user specified git push
> > --all. The advice_checkout_pull_push would make more sense in that case.
>
> Yeah, "default_matching_used" variable should be looked at somewhere
> around that, but I *think* the approach Christpher and Peff took (and I
> agree with them) is to help solving the immediate problem the user has and
> can address.
Yeah, this was how I interpretted Peff's original suggestion. It seemed
like a nice compromise between advice that was inapplicable and advice
that was too complex ("There are 3 different non-ff errors in your push.
Here are the four resolution processes required to fix them...").
Thanks for the additional patching. The language / logic changes make
sense. One quick, slightly-off-topic question: I'd like
to take another crack at the patch's commit message, to implement
some of your language suggestions and clean it up further. Is it
reasonable for me to wait a few days for additional comments or
updates, squash together these fixups into a single v2 patch (assuming
one patch is a logical unit for it), then resubmit?
Just wanted to clarify the workflow,
--
Christopher Tiwald
next prev parent reply other threads:[~2012-03-16 17:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-13 23:22 [PATCH] push: Provide situational hints for non-fast-forward errors Christopher Tiwald
2012-03-14 4:27 ` Junio C Hamano
2012-03-14 12:14 ` Zbigniew Jędrzejewski-Szmek
2012-03-14 13:00 ` Matthieu Moy
2012-03-14 14:27 ` Zbigniew Jędrzejewski-Szmek
2012-03-14 16:40 ` Christopher Tiwald
2012-03-15 8:54 ` Clemens Buchacher
2012-03-15 18:06 ` Junio C Hamano
2012-03-16 8:19 ` Matthieu Moy
2012-03-14 14:48 ` Christopher Tiwald
2012-03-14 14:53 ` Christopher Tiwald
2012-03-14 9:06 ` Matthieu Moy
2012-03-14 15:52 ` Christopher Tiwald
2012-03-14 17:26 ` Junio C Hamano
2012-03-16 5:36 ` Junio C Hamano
2012-03-16 9:10 ` Clemens Buchacher
2012-03-16 12:03 ` Junio C Hamano
2012-03-16 17:20 ` Christopher Tiwald [this message]
2012-03-16 18:07 ` Junio C Hamano
2012-03-16 22:00 ` Junio C Hamano
2012-03-16 21:41 ` Clemens Buchacher
2012-03-16 21:53 ` Junio C Hamano
2012-03-16 22:01 ` Clemens Buchacher
2012-03-16 22:10 ` Junio C Hamano
2012-03-17 17:10 ` [fixup PATCH] " Zbigniew Jędrzejewski-Szmek
2012-03-17 18:46 ` Christopher Tiwald
2012-03-17 19:42 ` Zbigniew Jędrzejewski-Szmek
2012-03-19 0:15 ` Junio C Hamano
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=20120316172013.GA8119@gmail.com \
--to=christiwald@gmail.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=drizzd@aon.at \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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.