| Message ID | 20201020121152.21645-1-charvi077@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v4] t7201: put each command on a separate line | expand |
Charvi Mendiratta <charvi077@gmail.com> writes: > Modern practice is to avoid multiple commands per line, > and instead place each command on its own line. > > Signed-off-by: Charvi Mendiratta <charvi077@gmail.com> > --- This looks good, but I am wondering what happened between v3 and v4. As you've demonstrated through the microproject that you can now comfortably be involved in the review discussion, I am tempted to suggest that we declare victory at this point and move on, but I don't know what the plans are for the other 4 patches (I guess we won't miss them that much---the micros are meant to be practice targets). Thanks. > t/t7201-co.sh | 26 ++++++++++++++++++-------- > 1 file changed, 18 insertions(+), 8 deletions(-) > > diff --git a/t/t7201-co.sh b/t/t7201-co.sh > index 5898182fd2..b36a93056f 100755 > --- a/t/t7201-co.sh > +++ b/t/t7201-co.sh > @@ -157,7 +157,8 @@ test_expect_success 'checkout -m with merge conflict' ' > ' > > test_expect_success 'format of merge conflict from checkout -m' ' > - git checkout -f master && git clean -f && > + git checkout -f master && > + git clean -f && > > fill b d >two && > git checkout -m simple && > @@ -180,7 +181,9 @@ test_expect_success 'format of merge conflict from checkout -m' ' > ' > > test_expect_success 'checkout --merge --conflict=diff3 <branch>' ' > - git checkout -f master && git reset --hard && git clean -f && > + git checkout -f master && > + git reset --hard && > + git clean -f && > > fill b d >two && > git checkout --merge --conflict=diff3 simple && > @@ -205,7 +208,9 @@ test_expect_success 'checkout --merge --conflict=diff3 <branch>' ' > ' > > test_expect_success 'switch to another branch while carrying a deletion' ' > - git checkout -f master && git reset --hard && git clean -f && > + git checkout -f master && > + git reset --hard && > + git clean -f && > git rm two && > > test_must_fail git checkout simple 2>errs && > @@ -218,7 +223,8 @@ test_expect_success 'switch to another branch while carrying a deletion' ' > test_expect_success 'checkout to detach HEAD (with advice declined)' ' > git config advice.detachedHead false && > rev=$(git rev-parse --short renamer^) && > - git checkout -f renamer && git clean -f && > + git checkout -f renamer && > + git clean -f && > git checkout renamer^ 2>messages && > test_i18ngrep "HEAD is now at $rev" messages && > test_line_count = 1 messages && > @@ -237,7 +243,8 @@ test_expect_success 'checkout to detach HEAD (with advice declined)' ' > test_expect_success 'checkout to detach HEAD' ' > git config advice.detachedHead true && > rev=$(git rev-parse --short renamer^) && > - git checkout -f renamer && git clean -f && > + git checkout -f renamer && > + git clean -f && > GIT_TEST_GETTEXT_POISON=false git checkout renamer^ 2>messages && > grep "HEAD is now at $rev" messages && > test_line_count -gt 1 messages && > @@ -254,7 +261,8 @@ test_expect_success 'checkout to detach HEAD' ' > ' > > test_expect_success 'checkout to detach HEAD with branchname^' ' > - git checkout -f master && git clean -f && > + git checkout -f master && > + git clean -f && > git checkout renamer^ && > H=$(git rev-parse --verify HEAD) && > M=$(git show-ref -s --verify refs/heads/master) && > @@ -269,7 +277,8 @@ test_expect_success 'checkout to detach HEAD with branchname^' ' > ' > > test_expect_success 'checkout to detach HEAD with :/message' ' > - git checkout -f master && git clean -f && > + git checkout -f master && > + git clean -f && > git checkout ":/Initial" && > H=$(git rev-parse --verify HEAD) && > M=$(git show-ref -s --verify refs/heads/master) && > @@ -284,7 +293,8 @@ test_expect_success 'checkout to detach HEAD with :/message' ' > ' > > test_expect_success 'checkout to detach HEAD with HEAD^0' ' > - git checkout -f master && git clean -f && > + git checkout -f master && > + git clean -f && > git checkout HEAD^0 && > H=$(git rev-parse --verify HEAD) && > M=$(git show-ref -s --verify refs/heads/master) &&
On Tue, Oct 20, 2020 at 01:13:53PM -0700, Junio C Hamano wrote: > Charvi Mendiratta <charvi077@gmail.com> writes: > > > Modern practice is to avoid multiple commands per line, > > and instead place each command on its own line. > > > > Signed-off-by: Charvi Mendiratta <charvi077@gmail.com> > > --- > > This looks good, but I am wondering what happened between v3 and > v4. When I applied this locally, I used this patch as a replacement for the last patch of v3 [1]. That kept everything passing after each patch. > As you've demonstrated through the microproject that you can now > comfortably be involved in the review discussion, I am tempted to > suggest that we declare victory at this point and move on, but I > don't know what the plans are for the other 4 patches (I guess we > won't miss them that much---the micros are meant to be practice > targets). Yup, ditto. > Thanks. Thanks, Taylor [1]: https://lore.kernel.org/git/20201020114319.18245-6-charvi077@gmail.com/
Junio C Hamano <gitster@pobox.com> writes: > Charvi Mendiratta <charvi077@gmail.com> writes: > >> Modern practice is to avoid multiple commands per line, >> and instead place each command on its own line. >> >> Signed-off-by: Charvi Mendiratta <charvi077@gmail.com> >> --- > > This looks good, but I am wondering what happened between v3 and > v4. > > As you've demonstrated through the microproject that you can now > comfortably be involved in the review discussion, I am tempted to > suggest that we declare victory at this point and move on, but I > don't know what the plans are for the other 4 patches (I guess we > won't miss them that much---the micros are meant to be practice > targets). Actually I take it back. This does not look good as a standalone patch at all. It seems to depend on something in the 5-patch series. Please make sure that patches you send are usable by your recipients.
Taylor Blau <me@ttaylorr.com> writes: > On Tue, Oct 20, 2020 at 01:13:53PM -0700, Junio C Hamano wrote: >> Charvi Mendiratta <charvi077@gmail.com> writes: >> >> > Modern practice is to avoid multiple commands per line, >> > and instead place each command on its own line. >> > >> > Signed-off-by: Charvi Mendiratta <charvi077@gmail.com> >> > --- >> >> This looks good, but I am wondering what happened between v3 and >> v4. > > When I applied this locally, I used this patch as a replacement for the > last patch of v3 [1]. That kept everything passing after each patch. Oh, so this is a replacement for 5/5 and 1-4/5 of v4 are supposed to be identical to those from v3? The difference between [v3 5/5] and this one is a single typofix on the subject line, it seems, though. >> As you've demonstrated through the microproject that you can now >> comfortably be involved in the review discussion, I am tempted to >> suggest that we declare victory at this point and move on, but I >> don't know what the plans are for the other 4 patches (I guess we >> won't miss them that much---the micros are meant to be practice >> targets). > > Yup, ditto. As [v4] single patch won't apply standalone, we cannot quite declare the victory yet. Are [v3 1-5/5] (or [v3 1-4/5] + [v4]) good to the reviewers of the past rounds?
On Tue, Oct 20, 2020 at 01:25:33PM -0700, Junio C Hamano wrote: > Taylor Blau <me@ttaylorr.com> writes: > > When I applied this locally, I used this patch as a replacement for the > > last patch of v3 [1]. That kept everything passing after each patch. > > Oh, so this is a replacement for 5/5 and 1-4/5 of v4 are supposed to > be identical to those from v3? The difference between [v3 5/5] and > this one is a single typofix on the subject line, it seems, though. Yes, at least that's what I interpreted it as (and how I applied it when testing). I'd like to hear from the author to make sure. (As an aside to the author, I often fall into the trap of thinking that it will be easier to send a single replacement patch which will generate less email, but--as you can see--it is often more complicated for reviewers and the maintainer to decipher what's going on. It's often just easier to re-submit the entire series and include in your cover letter "this is unchanged from v(n-1) except for ..."). > >> As you've demonstrated through the microproject that you can now > >> comfortably be involved in the review discussion, I am tempted to > >> suggest that we declare victory at this point and move on, but I > >> don't know what the plans are for the other 4 patches (I guess we > >> won't miss them that much---the micros are meant to be practice > >> targets). > > > > Yup, ditto. > > As [v4] single patch won't apply standalone, we cannot quite declare > the victory yet. Are [v3 1-5/5] (or [v3 1-4/5] + [v4]) good to the > reviewers of the past rounds? For what it's worth, I'm happy with [v3 1-4/5] + [v4]. Thanks, Taylor
Taylor Blau <me@ttaylorr.com> writes: >> As [v4] single patch won't apply standalone, we cannot quite declare >> the victory yet. Are [v3 1-5/5] (or [v3 1-4/5] + [v4]) good to the >> reviewers of the past rounds? > > For what it's worth, I'm happy with [v3 1-4/5] + [v4]. Yeah, I'm happy with them, but this is an impression only from a quick skimming---I guess I'd just trust you and won't go back to the patches with fine toothed comb myself ;-). Thanks, all.
On Wed, 21 Oct 2020 at 02:00, Taylor Blau <me@ttaylorr.com> wrote: > > On Tue, Oct 20, 2020 at 01:25:33PM -0700, Junio C Hamano wrote: > > Taylor Blau <me@ttaylorr.com> writes: > > > When I applied this locally, I used this patch as a replacement for the > > > last patch of v3 [1]. That kept everything passing after each patch. > > > > Oh, so this is a replacement for 5/5 and 1-4/5 of v4 are supposed to > > be identical to those from v3? The difference between [v3 5/5] and > > this one is a single typofix on the subject line, it seems, though. > > Yes, at least that's what I interpreted it as (and how I applied it when > testing). I'd like to hear from the author to make sure. > I think I messed up the versions. Its correct that v4 patch was only replacement for 5/5 (5th patch) of v3, since I need to fix the typo error of subject line. Also, other 4 patches (1-4/5) of v3 need to be remain same in v4. > (As an aside to the author, I often fall into the trap of thinking that > it will be easier to send a single replacement patch which will generate > less email, but--as you can see--it is often more complicated for > reviewers and the maintainer to decipher what's going on. It's often > just easier to re-submit the entire series and include in your cover > letter "this is unchanged from v(n-1) except for ..."). > Yes I realized this, actually earlier I was doubtful about whether to include the previous version's correct patches in the new version or not. I might have confirmed this before sending. But now I will strictly follow this . Thanks a lot to Junio and Taylor for pointing this out. And in order to correct this, I will send the new patch series having (v3 1-4/5]+[v4]). Please correct me, if I missed out anything else. > > >> As you've demonstrated through the microproject that you can now > > >> comfortably be involved in the review discussion, I am tempted to > > >> suggest that we declare victory at this point and move on, but I > > >> don't know what the plans are for the other 4 patches (I guess we > > >> won't miss them that much---the micros are meant to be practice > > >> targets). > > > > > > Yup, ditto. > > > > As [v4] single patch won't apply standalone, we cannot quite declare > > the victory yet. Are [v3 1-5/5] (or [v3 1-4/5] + [v4]) good to the > > reviewers of the past rounds? > > For what it's worth, I'm happy with [v3 1-4/5] + [v4]. > > Thanks, > Taylor Thanks and Regards, Charvi
On Wed, 21 Oct 2020 at 01:49, Junio C Hamano <gitster@pobox.com> wrote: > > Junio C Hamano <gitster@pobox.com> writes: > > > Charvi Mendiratta <charvi077@gmail.com> writes: > > > >> Modern practice is to avoid multiple commands per line, > >> and instead place each command on its own line. > >> > >> Signed-off-by: Charvi Mendiratta <charvi077@gmail.com> > >> --- > > > > This looks good, but I am wondering what happened between v3 and > > v4. > > > > As you've demonstrated through the microproject that you can now > > comfortably be involved in the review discussion, I am tempted to > > suggest that we declare victory at this point and move on, but I > > don't know what the plans are for the other 4 patches (I guess we > > won't miss them that much---the micros are meant to be practice > > targets). > > Actually I take it back. This does not look good as a standalone > patch at all. It seems to depend on something in the 5-patch > series. > Yes, Thanks a lot Junio. I totally agree after applying it locally and getting stuck in am conflicts without using v3. > Please make sure that patches you send are usable by your > recipients. > I will take this as an important note. I have fixed it and sent the patch series after testing it locally . Thanks and Regards, Charvi
diff --git a/t/t7201-co.sh b/t/t7201-co.sh index 5898182fd2..b36a93056f 100755 --- a/t/t7201-co.sh +++ b/t/t7201-co.sh @@ -157,7 +157,8 @@ test_expect_success 'checkout -m with merge conflict' ' ' test_expect_success 'format of merge conflict from checkout -m' ' - git checkout -f master && git clean -f && + git checkout -f master && + git clean -f && fill b d >two && git checkout -m simple && @@ -180,7 +181,9 @@ test_expect_success 'format of merge conflict from checkout -m' ' ' test_expect_success 'checkout --merge --conflict=diff3 <branch>' ' - git checkout -f master && git reset --hard && git clean -f && + git checkout -f master && + git reset --hard && + git clean -f && fill b d >two && git checkout --merge --conflict=diff3 simple && @@ -205,7 +208,9 @@ test_expect_success 'checkout --merge --conflict=diff3 <branch>' ' ' test_expect_success 'switch to another branch while carrying a deletion' ' - git checkout -f master && git reset --hard && git clean -f && + git checkout -f master && + git reset --hard && + git clean -f && git rm two && test_must_fail git checkout simple 2>errs && @@ -218,7 +223,8 @@ test_expect_success 'switch to another branch while carrying a deletion' ' test_expect_success 'checkout to detach HEAD (with advice declined)' ' git config advice.detachedHead false && rev=$(git rev-parse --short renamer^) && - git checkout -f renamer && git clean -f && + git checkout -f renamer && + git clean -f && git checkout renamer^ 2>messages && test_i18ngrep "HEAD is now at $rev" messages && test_line_count = 1 messages && @@ -237,7 +243,8 @@ test_expect_success 'checkout to detach HEAD (with advice declined)' ' test_expect_success 'checkout to detach HEAD' ' git config advice.detachedHead true && rev=$(git rev-parse --short renamer^) && - git checkout -f renamer && git clean -f && + git checkout -f renamer && + git clean -f && GIT_TEST_GETTEXT_POISON=false git checkout renamer^ 2>messages && grep "HEAD is now at $rev" messages && test_line_count -gt 1 messages && @@ -254,7 +261,8 @@ test_expect_success 'checkout to detach HEAD' ' ' test_expect_success 'checkout to detach HEAD with branchname^' ' - git checkout -f master && git clean -f && + git checkout -f master && + git clean -f && git checkout renamer^ && H=$(git rev-parse --verify HEAD) && M=$(git show-ref -s --verify refs/heads/master) && @@ -269,7 +277,8 @@ test_expect_success 'checkout to detach HEAD with branchname^' ' ' test_expect_success 'checkout to detach HEAD with :/message' ' - git checkout -f master && git clean -f && + git checkout -f master && + git clean -f && git checkout ":/Initial" && H=$(git rev-parse --verify HEAD) && M=$(git show-ref -s --verify refs/heads/master) && @@ -284,7 +293,8 @@ test_expect_success 'checkout to detach HEAD with :/message' ' ' test_expect_success 'checkout to detach HEAD with HEAD^0' ' - git checkout -f master && git clean -f && + git checkout -f master && + git clean -f && git checkout HEAD^0 && H=$(git rev-parse --verify HEAD) && M=$(git show-ref -s --verify refs/heads/master) &&
Modern practice is to avoid multiple commands per line, and instead place each command on its own line. Signed-off-by: Charvi Mendiratta <charvi077@gmail.com> --- t/t7201-co.sh | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)