| Message ID | 20200913193140.66906-2-alipman88@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | git branch: allow combining merged and no-merged filters | expand |
On Sun, Sep 13, 2020 at 3:32 PM Aaron Lipman <alipman88@gmail.com> wrote: > Add tests covering the behavior of passing multiple contains/no-contains > filters to git branch, e.g.: > --- > diff --git a/t/t3201-branch-contains.sh b/t/t3201-branch-contains.sh > @@ -200,15 +200,51 @@ test_expect_success 'branch --merged with --verbose' ' > +# The next series of tests covers multiple filter combinations > +test_expect_success 'set up repo for multiple filter combination tests' ' > + git checkout master && > + git branch | grep -v master | xargs git branch -D && > + git checkout -b feature_a master && > + >feature_a && > + git add feature_a && > + git commit -m "add feature a" && > + git checkout -b feature_b master && > + >feature_b && > + git add feature_b && > + git commit -m "add feature b" > +' A few comments: I didn't examine it too closely, so this may be a silly question, but is there a reason to start from scratch (by deleting all the branches) rather than simply using or extending the existing branches like the other tests do? If it really does make sense to start from scratch (ignoring the existing branches), then an alternative would be to create a new repository and run the tests in that repository instead. Whether or not doing so makes sense in this case is a judgment call. For instance: test_create_repo features ( cd features ...setup stuff... ) It's a bit concerning to see output from porcelain git-branch being fed to 'grep' and 'xargs'. More typically, you would instead rely upon the (stable) output of a plumbing command. For instance: git for-each-ref --format="%(refname:short)" refs/heads/ | ... In new test code, normally avoid having a Git command upstream of a pipe since its exit code will be lost. Thus, you might instead write: git for-each-ref ... >heads && grep -v master heads | xargs git branch -D &&
Eric Sunshine <sunshine@sunshineco.com> writes: > A few comments: > > I didn't examine it too closely, so this may be a silly question, but > is there a reason to start from scratch (by deleting all the branches) > rather than simply using or extending the existing branches like the > other tests do? > > If it really does make sense to start from scratch (ignoring the > existing branches), then an alternative would be to create a new > repository and run the tests in that repository instead. Whether or > not doing so makes sense in this case is a judgment call. For > instance: > > test_create_repo features > ( > cd features > ...setup stuff... > ) Good comments; I agree with both. > It's a bit concerning to see output from porcelain git-branch being > fed to 'grep' and 'xargs'. More typically, you would instead rely upon > the (stable) output of a plumbing command. For instance: > > git for-each-ref --format="%(refname:short)" refs/heads/ | ... > > In new test code, normally avoid having a Git command upstream of a > pipe since its exit code will be lost. Thus, you might instead write: > > git for-each-ref ... >heads && > grep -v master heads | xargs git branch -D && Again, good recommendation. Thank you always for helpful reviews.
diff --git a/t/t3201-branch-contains.sh b/t/t3201-branch-contains.sh index 40251c9f8f..cd205b5560 100755 --- a/t/t3201-branch-contains.sh +++ b/t/t3201-branch-contains.sh @@ -200,15 +200,51 @@ test_expect_success 'branch --merged with --verbose' ' test_i18ncmp expect actual ' -test_expect_success 'branch --contains combined with --no-contains' ' - git branch --contains zzz --no-contains topic >actual && +# The next series of tests covers multiple filter combinations +test_expect_success 'set up repo for multiple filter combination tests' ' + git checkout master && + git branch | grep -v master | xargs git branch -D && + git checkout -b feature_a master && + >feature_a && + git add feature_a && + git commit -m "add feature a" && + git checkout -b feature_b master && + >feature_b && + git add feature_b && + git commit -m "add feature b" +' + +test_expect_success 'multiple branch --contains' ' + git checkout -b next master && + git merge feature_a && + git branch --contains feature_a --contains feature_b >actual && + cat >expect <<-\EOF && + feature_a + feature_b + * next + EOF + test_cmp expect actual +' + +test_expect_success 'multiple branch --no-contains' ' + git branch --no-contains feature_a --no-contains feature_b >actual && cat >expect <<-\EOF && master - side - zzz EOF test_cmp expect actual +' +test_expect_success 'branch --contains combined with --no-contains' ' + git checkout master && + git merge feature_a && + git checkout next && + git merge feature_b && + git branch --contains feature_a --no-contains feature_b >actual && + cat >expect <<-\EOF && + feature_a + master + EOF + test_cmp expect actual ' test_done
Add tests covering the behavior of passing multiple contains/no-contains filters to git branch, e.g.: $ git branch --contains feature_a --contains feature_b $ git branch --no-contains feature_a --no-contains feature_b When passed more than one contains (or no-contains) filter, the tips of the branches returned must be reachable from any of the contains commits and from none of the no-contains commits. This logic is useful to describe prior to enabling multiple merged/no-merged filters, so that future tests will demonstrate consistent behavior between merged/no-merged and contains/no-contains filters. Signed-off-by: Aaron Lipman <alipman88@gmail.com> --- t/t3201-branch-contains.sh | 44 ++++++++++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 4 deletions(-)