All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Max Kirillov <max@max630.net>
Cc: Kirill Smelkov <kirr@mns.spb.ru>, Jeff King <peff@peff.net>,
	git@vger.kernel.org
Subject: Re: [PATCH 1/4] Add test for showing discarded changes with diff --cc
Date: Thu, 02 Apr 2015 13:55:58 -0700	[thread overview]
Message-ID: <xmqqy4mai71d.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1428006853-21212-2-git-send-email-max@max630.net> (Max Kirillov's message of "Thu, 2 Apr 2015 23:34:10 +0300")

Max Kirillov <max@max630.net> writes:

> If a hunk has been changed in both branches and conflict resolution
> fully takes one of branches, discarding all changes that are in the
> other, then the merge is not shown in 3-way diff which git uses by
> default.
>
> The advice is to use flag --cc and and explicitly add the mergebase was
> given in $gmane/191557. It was discovered though that it does not always
> work. If the whole file has not changed at all compared to one of
> branches then no difference is shown for this file.
>
> This looks inconsistent and for particular scenario of viewing discarded
> changes is undesirable.
>
> Add the test which demonstrates the issue.
>
> Signed-off-by: Max Kirillov <max@max630.net>

Thanks.  I will not have time to review this properly at the moment
while preparing 2.4-rc1, and I do not want to spend time figuring
out if the parent culling you are chaning was done deliberately (in
which case this patch may be breaking things) or not.

So I'll give a preliminary nitpicks first ;-)

>> Subject: Re: [PATCH 1/4] Add test for showing discarded changes with diff --cc

Subject: t4059: test 'diff --cc' with a change from only few parents

or something?  "<area>: <what you did>" without capitalization of
the beginning of what you did and the full-stop at the end.

> ---
>  t/t4059-diff-merge-with-base.sh | 100 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 100 insertions(+)
>  create mode 100755 t/t4059-diff-merge-with-base.sh
>
> diff --git a/t/t4059-diff-merge-with-base.sh b/t/t4059-diff-merge-with-base.sh
> new file mode 100755
> index 0000000..e650a33
> --- /dev/null
> +++ b/t/t4059-diff-merge-with-base.sh
> @@ -0,0 +1,100 @@
> +#!/bin/sh
> +
> +test_description='Diff aware of merge base'
> +
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> +	mkdir short &&
> +	mkdir long &&
> +	for fn in win1 win2 merge delete base only1 only2; do
> +		test_seq 3 >short/$fn
> +		git add short/$fn &&
> +		test_seq 11 >long/$fn &&
> +		git add long/$fn
> +	done &&

Two nits:

 - Style: have "do" on its own line.  A good rule of thumb is that
   you shouldn't have to type ';' when you are writing a shell
   script, unless you are terminating a case arm with ';;'.

	for fn in ...
        do
        	...
	done

 - Correctness: aside from missing && after "test_seq 3", if the
   last step "git add long/$fn" failed in an earlier iteration, you
   would not notice any breakage.  Either

	(
                for fn in ...
                do
                        ... &&
                        ... &&
                        ... || exit $?
                done
	)

    or

	for fn in ...
        do
        	... &&
                ... &&
                ... || return $?
	done

    The latter is only valid in our test scripts, where the test
    framework gives you an artificial "caller" of the "subroutine"
    you are writing as the test body.

> +	test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" >long/base &&
> +	git add long/base &&
> + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e
> "s/^2/2change1/" >long/win1 &&
> +	git add long/win1 &&
> + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e
> "s/^2/2change2/" >long/win2 &&
> +	git add long/win2 &&
> + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e
> "s/^2/2merged/" >long/merge &&
> +	git add long/merge &&
> + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e
> "/^2/d" >long/delete &&
> +	git add long/delete &&
> + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e
> "s/^2/2change1/" >long/only1 &&
> +	git add long/only1 &&
> + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e
> "s/^2/2change2/" >long/only2 &&
> +	git add long/only2 &&

Patch is line-wrapped around here?

  reply	other threads:[~2015-04-02 20:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-02 20:34 [PATCH 0/4] diff --cc: relax path filtering Max Kirillov
2015-04-02 20:34 ` [PATCH 1/4] Add test for showing discarded changes with diff --cc Max Kirillov
2015-04-02 20:55   ` Junio C Hamano [this message]
2015-04-03 16:03     ` Max Kirillov
2015-04-02 20:34 ` [PATCH 2/4] combine-diff.c: refactor: extract insert_path() Max Kirillov
2015-04-02 20:34 ` [PATCH 3/4] diff --cc: relax too strict paths picking Max Kirillov
2015-04-02 20:59   ` Junio C Hamano
2015-04-02 20:34 ` [PATCH 4/4] t4059: rewrite to be adaptive to hunk filtering Max Kirillov
2015-04-02 21:13 ` [PATCH 0/4] diff --cc: relax path filtering Jeff King
2015-04-03 16:29   ` Max Kirillov
2015-04-03 15:58 ` [PATCH v2 " Max Kirillov
2015-04-03 15:58   ` [PATCH v2 1/4] t4059: test 'diff --cc' with a change from only few parents Max Kirillov
2015-04-11 20:04     ` Junio C Hamano
2015-04-11 21:07     ` Junio C Hamano
2015-04-11 21:20       ` Junio C Hamano
2015-04-12  5:43       ` Max Kirillov
2015-04-12  5:51         ` Junio C Hamano
2015-04-14  4:22           ` Max Kirillov
2015-04-14  4:09         ` [PATCH/RFC] combine-diff.c: make intersect_paths() behave like hunk filtering Max Kirillov
2015-04-03 15:58   ` [PATCH v2 2/4] combine-diff.c: refactor: extract insert_path() Max Kirillov
2015-04-11 20:14     ` Junio C Hamano
2015-04-03 15:58   ` [PATCH v2 3/4] diff --cc: relax too strict paths picking Max Kirillov
2015-04-03 15:58   ` [PATCH v2 4/4] t4059: rewrite to be adaptive to hunk filtering Max Kirillov
2015-04-12  5:48     ` Junio C Hamano
2015-04-14  4:18       ` Max Kirillov

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=xmqqy4mai71d.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kirr@mns.spb.ru \
    --cc=max@max630.net \
    --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.