From: 胡哲宁 <adlternative@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: ZheNing Hu via GitGitGadget <gitgitgadget@gmail.com>,
Git List <git@vger.kernel.org>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v4 3/3] ls-files: add --deduplicate option
Date: Mon, 18 Jan 2021 14:05:53 +0800 [thread overview]
Message-ID: <CAOLTT8QnhNqnJCgiqOZnd9cjxicAuk2Js1GKdHEJD_XK15UU+Q@mail.gmail.com> (raw)
In-Reply-To: <CAOLTT8Syp2ZeTXW-m+e=dn2W773nScB_kwZLS3MjLTcFQ_bctw@mail.gmail.com>
Hi,Junio!
Here I am thinking about the role of this "--deduplicate" is to
suppress duplicate filenames rather than duplicate entries. Do you
think I should modify this sentence?
> > OPT_BOOL(0,"deduplicate",&skipping_duplicates,N_("suppress duplicate entries")),
胡哲宁 <adlternative@gmail.com> 于2021年1月18日周一 下午12:09写道:
>
> Junio C Hamano <gitster@pobox.com> 于2021年1月18日周一 上午7:34写道:
> >
> > "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >
> > > diff --git a/t/t3012-ls-files-dedup.sh b/t/t3012-ls-files-dedup.sh
> > > new file mode 100755
> > > index 00000000000..75877255c2c
> > > --- /dev/null
> > > +++ b/t/t3012-ls-files-dedup.sh
> > > @@ -0,0 +1,57 @@
> > > +#!/bin/sh
> > > +
> > > +test_description='git ls-files --deduplicate test'
> > > +
> > > +. ./test-lib.sh
> >
> > We should already have a ls-files test so that we can add a handful
> > new tests to it, instead of dedicating a whole new test script.
> >
> Fine,It might be easier for me to write a test file myself for the time being.
> But I will learn slowly.
> > Also, don't do everything in a single 'setup'. There are various
> > scenarios you want to make sure ls-files to work (grep for ls-files
> > in the following you added---I count 4 of them), and when a future
> > developer touches the code, he or she may break one but not other
> > three. The purpose you write tests is to protect your new feature
> > from such a developer *AND* help such a developer to debug and fix
> > his or her changes. For that, it would be a lot more sensible to
> > have one set-up that is common, and then four separate tests.
> >
> > > +test_expect_success 'setup' '
> > > + >a.txt &&
> > > + >b.txt &&
> > > + >delete.txt &&
> > > + git add a.txt b.txt delete.txt &&
> > > + git commit -m master:1 &&
> >
> > Needless use of the word "master". Observe what is going on in the
> > project around you and avoid stepping other peoples' toes. One of
> > the ongoing effort is to grep for the phrase master in t/ directory
> > and examine what happens when the default initial branch name
> > becomes something other than 'master', so adding a needless hit like
> > this is most unwelcome.
> >
> Well, I will try my best to use less "master".
> > > + echo a >a.txt &&
> > > + echo b >b.txt &&
> > > + echo delete >delete.txt &&
> > > + git add a.txt b.txt delete.txt &&
> > > + git commit -m master:2 &&
> >
> > > + git checkout HEAD~ &&
> > > + git switch -c dev &&
> >
> > Needless mixture of checkout/switch. If you switch branches using
> > "git checkout", for example, consistently do so, i.e.
> >
> > git checkout -b dev HEAD~1
> >
> > It's not like these new tests are to test checkout and switch; your
> > mission is to protect "ls-files --dedup" feature here.
> >
> > > + test_when_finished "git switch master" &&
> > > + echo change >a.txt &&
> > > + git add a.txt &&
> > > + git commit -m dev:1 &&
> >
> > I'd consider all of the above to be 'setup' that is common for
> > subsequent tests. It may make sense to actually do everything
> > on the initial branch, i.e. after creating two commits, do
> >
> I understand it now...setup is for serve as a basis for other tests.
> > git tag tip &&
> > git reset --hard HEAD^ &&
> > echo change >a.txt &&
> > git commit -a -m side &&
> > git tag side
> >
> > You are always on the initial branch without ever switching, so
> > there is no need for the when_finished stuff.
> >
> > Then the first of your test is to show the index with conflicts.
> >
> > > + test_must_fail git merge master &&
> >
> > This will become "git merge tip" instead of 'master'.
> >
> use tag instead of use branch name...
> > > + git ls-files --deduplicate >actual &&
> > > + cat >expect <<-\EOF &&
> > > + a.txt
> > > + b.txt
> > > + delete.txt
> > > + EOF
> > > + test_cmp expect actual &&
> >
> > And up to this point is the first test after 'setup'.
> >
> > The next test should begin with:
> >
> > git reset --hard side &&
> > test_must_fail git merge tip &&
> >
> > so that even when the first test is skipped, or left unmerged,
> > you'll begin with a known state.
> >
> Well,I understand now that the a test_success should allow other
> programmers to skip this test,so that we should reset to a known
> state at the beginning of each test.
> > > + rm delete.txt &&
> > > + git ls-files -d -m --deduplicate >actual &&
> > > + cat >expect <<-\EOF &&
> > > + a.txt
> > > + delete.txt
> > > + EOF
> > > + test_cmp expect actual &&
> > > + git ls-files -d -m -t --deduplicate >actual &&
> > > + cat >expect <<-\EOF &&
> > > + C a.txt
> > > + C a.txt
> > > + C a.txt
> > > + R delete.txt
> > > + C delete.txt
> > > + EOF
> > > + test_cmp expect actual &&
> > > + git ls-files -d -m -c --deduplicate >actual &&
> > > + cat >expect <<-\EOF &&
> > > + a.txt
> > > + b.txt
> > > + delete.txt
> > > + EOF
> > > + test_cmp expect actual &&
> >
> > These three can be kept in the same test_expect_success, as they are
> > exercising read-only operation on the same state but with different
> > display options.
> >
> indeed so.
> > But in this case, the preparation is not too tedious (just a failed
> > merge plus a deletion), so you probably would prefer to split it
> > into 3 independent tests---that may make it more helpful to future
> > developers.
> >
> Thanks:)
> > > + git merge --abort
> > > +'
> > > +test_done
next prev parent reply other threads:[~2021-01-18 6:06 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 8:53 [PATCH] builtin/ls-files.c:add git ls-file --dedup option 阿德烈 via GitGitGadget
2021-01-07 6:10 ` Eric Sunshine
2021-01-07 6:40 ` Junio C Hamano
2021-01-08 14:36 ` [PATCH v2 0/2] " 阿德烈 via GitGitGadget
2021-01-08 14:36 ` [PATCH v2 1/2] " ZheNing Hu via GitGitGadget
2021-01-08 14:36 ` [PATCH v2 2/2] builtin:ls-files.c:add " ZheNing Hu via GitGitGadget
2021-01-14 6:38 ` Eric Sunshine
2021-01-14 8:17 ` 胡哲宁
2021-01-14 12:22 ` [PATCH v3] ls-files.c: add " 阿德烈 via GitGitGadget
2021-01-15 0:59 ` Junio C Hamano
2021-01-17 3:45 ` 胡哲宁
2021-01-17 4:37 ` Junio C Hamano
2021-01-16 7:13 ` Eric Sunshine
2021-01-17 3:49 ` 胡哲宁
2021-01-17 5:11 ` Eric Sunshine
2021-01-17 23:04 ` Junio C Hamano
2021-01-18 14:59 ` Eric Sunshine
2021-01-17 4:02 ` [PATCH v4 0/3] builtin/ls-files.c:add git ls-file " 阿德烈 via GitGitGadget
2021-01-17 4:02 ` [PATCH v4 1/3] ls_files.c: bugfix for --deleted and --modified ZheNing Hu via GitGitGadget
2021-01-17 6:22 ` Junio C Hamano
2021-01-17 4:02 ` [PATCH v4 2/3] ls_files.c: consolidate two for loops into one ZheNing Hu via GitGitGadget
2021-01-17 4:02 ` [PATCH v4 3/3] ls-files: add --deduplicate option ZheNing Hu via GitGitGadget
2021-01-17 6:25 ` Junio C Hamano
2021-01-17 23:34 ` Junio C Hamano
2021-01-18 4:09 ` 胡哲宁
2021-01-18 6:05 ` 胡哲宁 [this message]
2021-01-18 21:31 ` Junio C Hamano
2021-01-19 2:56 ` 胡哲宁
2021-01-19 6:30 ` [PATCH v5 0/3] builtin/ls-files.c:add git ls-file --dedup option 阿德烈 via GitGitGadget
2021-01-19 6:30 ` [PATCH v5 1/3] ls_files.c: bugfix for --deleted and --modified ZheNing Hu via GitGitGadget
2021-01-20 20:26 ` Junio C Hamano
2021-01-21 10:02 ` 胡哲宁
2021-01-19 6:30 ` [PATCH v5 2/3] ls_files.c: consolidate two for loops into one ZheNing Hu via GitGitGadget
2021-01-20 20:27 ` Junio C Hamano
2021-01-21 11:05 ` 胡哲宁
2021-01-19 6:30 ` [PATCH v5 3/3] ls-files.c: add --deduplicate option ZheNing Hu via GitGitGadget
2021-01-20 21:26 ` Junio C Hamano
2021-01-21 11:00 ` 胡哲宁
2021-01-21 20:45 ` Junio C Hamano
2021-01-22 9:50 ` 胡哲宁
2021-01-22 16:04 ` Johannes Schindelin
2021-01-22 18:02 ` Junio C Hamano
2021-03-19 13:54 ` GitGitGadget and `next`, was " Johannes Schindelin
2021-03-19 18:11 ` Junio C Hamano
2021-01-23 8:20 ` 胡哲宁
2021-01-22 15:46 ` [PATCH v6] " ZheNing Hu
2021-01-22 20:52 ` Junio C Hamano
2021-01-23 8:27 ` 胡哲宁
2021-01-23 10:20 ` [PATCH v6 0/3] builtin/ls-files.c:add git ls-file --dedup option 阿德烈 via GitGitGadget
2021-01-23 10:20 ` [PATCH v6 1/3] ls_files.c: bugfix for --deleted and --modified ZheNing Hu via GitGitGadget
2021-01-23 17:55 ` Junio C Hamano
2021-01-23 10:20 ` [PATCH v6 2/3] ls_files.c: consolidate two for loops into one ZheNing Hu via GitGitGadget
2021-01-23 19:50 ` Junio C Hamano
2021-01-23 10:20 ` [PATCH v6 3/3] ls-files.c: add --deduplicate option ZheNing Hu via GitGitGadget
2021-01-23 19:51 ` Junio C Hamano
2021-01-23 19:53 ` [PATCH v7 1/3] ls_files.c: bugfix for --deleted and --modified Junio C Hamano
2021-01-23 19:53 ` [PATCH v7 2/3] ls_files.c: consolidate two for loops into one Junio C Hamano
2021-01-23 19:53 ` [PATCH v7 3/3] ls-files.c: add --deduplicate option Junio C Hamano
2021-01-24 10:54 ` [PATCH v7 0/3] builtin/ls-files.c:add git ls-file --dedup option 阿德烈 via GitGitGadget
2021-01-24 10:54 ` [PATCH v7 1/3] ls_files.c: bugfix for --deleted and --modified ZheNing Hu via GitGitGadget
2021-01-24 22:04 ` Junio C Hamano
2021-01-25 6:05 ` 胡哲宁
2021-01-25 19:05 ` Junio C Hamano
2021-01-24 10:54 ` [PATCH v7 2/3] ls_files.c: consolidate two for loops into one ZheNing Hu via GitGitGadget
2021-01-24 10:54 ` [PATCH v7 3/3] ls-files.c: add --deduplicate option ZheNing Hu via GitGitGadget
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=CAOLTT8QnhNqnJCgiqOZnd9cjxicAuk2Js1GKdHEJD_XK15UU+Q@mail.gmail.com \
--to=adlternative@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=sunshine@sunshineco.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).