All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Paul Tan <pyokagan@gmail.com>
Cc: git@vger.kernel.org, Stefan Beller <sbeller@google.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH v3 2/9] t5520: ensure origin refs are updated
Date: Wed, 13 May 2015 07:27:19 -0700	[thread overview]
Message-ID: <xmqqegmkbliw.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1431508136-15313-3-git-send-email-pyokagan@gmail.com> (Paul Tan's message of "Wed, 13 May 2015 17:08:49 +0800")

Paul Tan <pyokagan@gmail.com> writes:

> Should all of the tests before "setup for avoiding reapplying old
> patches" fail or be skipped, the repo "dst" will not have fetched the
> updated refs from origin. To be resilient against such failures, run
> "git fetch origin".
>
> Signed-off-by: Paul Tan <pyokagan@gmail.com>
> ---
> * Hmm, no reviews the last round?

It is not unusual when the change is trivially correct.

I do not think this hurts, but I do not think that this is vastly
better, either.  If you suspect that the previous one may fail but
you at the same time are so trusting that the one before that one
would succeed, yes, this will help in that case.  But if you suspect
the previous one may fail, the one before that may have also failed,
in which case this may not be sufficient (the result of fetching may
not match what this test expects to see).

It all depends on where our paranoia ends. The current code is very
much trusting all previous ones equally, and accepts "upon the first
error, all bets are off for the later ones". With this patch, it
becomes slightly less trusting.

If everything else were equal, I would say this change is a "Meh" to
me, but I think the change improves this test in a different way.

It begins with "Run 'git rebase --abort', just in case"; which is a
signal that it does consider that the previous one may have failed
and attempts to prepare for that possibility, while trusting the one
before that would have succeeded.  And under that assumption, what
it currently does is _not_ consistent; the previous "pull --rebase"
may have failed in the "rebase" phase, in which case "abort just in
case" is a good measure to go back to the clean state, but it may
have failed in the "fetch" phase, in which case "abort" does not
help.  And this patch is needed to fix that inconsistency.

If justified in that way in the log message, then I wouldn't have
said "I do not think that this is vastly better", I think.

>  t/t5520-pull.sh | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
> index 20ad373..14a9280 100755
> --- a/t/t5520-pull.sh
> +++ b/t/t5520-pull.sh
> @@ -339,6 +339,7 @@ test_expect_success 'git pull --rebase detects upstreamed changes' '
>  test_expect_success 'setup for avoiding reapplying old patches' '
>  	(cd dst &&
>  	 test_might_fail git rebase --abort &&
> +	 git fetch origin &&
>  	 git reset --hard origin/master
>  	) &&
>  	git clone --bare src src-replace.git &&

  reply	other threads:[~2015-05-13 14:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13  9:08 [PATCH v3 0/9] Improve git-pull test coverage Paul Tan
2015-05-13  9:08 ` [PATCH v3 1/9] t5520: fixup file contents comparisons Paul Tan
2015-05-13 14:01   ` Junio C Hamano
2015-05-13 14:42     ` Junio C Hamano
2015-05-14 17:29       ` Michael Blume
2015-05-14 17:44         ` Junio C Hamano
2015-05-15 11:41           ` Paul Tan
2015-05-15 18:37             ` Junio C Hamano
2015-05-15 19:22               ` Junio C Hamano
2015-05-16 13:49               ` Paul Tan
2015-05-16 18:57                 ` Junio C Hamano
2015-05-16 23:32                   ` Junio C Hamano
2015-05-17  7:47                   ` Paul Tan
2015-05-13  9:08 ` [PATCH v3 2/9] t5520: ensure origin refs are updated Paul Tan
2015-05-13 14:27   ` Junio C Hamano [this message]
2015-05-18 13:09     ` Paul Tan
2015-05-13  9:08 ` [PATCH v3 3/9] t5520: test no merge candidates cases Paul Tan
2015-05-13  9:08 ` [PATCH v3 4/9] t5520: test for failure if index has unresolved entries Paul Tan
2015-05-13  9:32   ` Matthieu Moy
2015-05-15  8:25   ` Paul Tan
2015-05-13  9:08 ` [PATCH v3 5/9] t5520: test work tree fast-forward when fetch updates head Paul Tan
2015-05-13  9:08 ` [PATCH v3 6/9] t5520: test --rebase with multiple branches Paul Tan
2015-05-13  9:08 ` [PATCH v3 7/9] t5520: test --rebase failure on unborn branch with index Paul Tan
2015-05-13  9:08 ` [PATCH v3 8/9] t5521: test --dry-run does not make any changes Paul Tan
2015-05-13  9:08 ` [PATCH v3 9/9] t5520: check reflog action in fast-forward merge Paul Tan

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=xmqqegmkbliw.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=newren@gmail.com \
    --cc=pyokagan@gmail.com \
    --cc=sbeller@google.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 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.