Re: How to handle patch series conflicts
On Monday, October 8, 2018 10:51:09 PM MST Junio C Hamano wrote: > The scripts themselves having the same name that is no more specific > tha just "commit" does not bother _me_ personally too much. If I > were doing it, unless you are an obsessive type that wants to see > spanking cleanness everywhere, I'd limit the changes to the minimum. > No I'm not an obsessive type. sps
Re: How to handle patch series conflicts
Stephen & Linda Smith writes: > Junio - I've been working this but would like your opinion on 7500, 7501 and > now 7510. > > I note that the the commit tests have intermixed functionality. An example > is > signoff tests that are in the three tests I mentioned. > > I've been tempted multiple times over the last week to just merge the tests > into a single script, but that doesn't seem right either. > > So would you prefer a single script? Would you prefer me to move tests > around? The scripts themselves having the same name that is no more specific tha just "commit" does not bother _me_ personally too much. If I were doing it, unless you are an obsessive type that wants to see spanking cleanness everywhere, I'd limit the changes to the minimum. If something tested in script X is tested in another script Y and it is trivial to see they are testing exactly the same thing, removing one copy from script Y would be good, and if the remaining changes in script Y becomes more focused with only such removals, that would even be better, as at that point we can rename "tY-commit.sh" to something more specific like "tY-commit-signature.sh".
Re: How to handle patch series conflicts
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote: > Stephen & Linda Smith writes: > > Junio - > > > > On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote: > >> > t7500-commit.sh > >> > t7501-commit.sh > >> > t7502-commit.sh > >> > t7509-commit.sh > >> > >> These seem to have organically grown and it is very likely that ones > >> later introduced were added more from laziness. Junio - I've been working this but would like your opinion on 7500, 7501 and now 7510. I note that the the commit tests have intermixed functionality. An example is signoff tests that are in the three tests I mentioned. I've been tempted multiple times over the last week to just merge the tests into a single script, but that doesn't seem right either. So would you prefer a single script? Would you prefer me to move tests around? sps
Re: How to handle patch series conflicts
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote: > I think that one that is not even in 'pu' hasn't been looked at for > a long time; it is probably a good idea to discard and replace, if > you have something working. I submitted a working patch set yesterday. [1] https://public-inbox.org/git/20180906005329.11277-1-isch...@cox.net/T/ #m3ed5a15721318f71064dbe7225be9242c3960e1c sps
Re: How to handle patch series conflicts
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote: > I think that one that is not even in 'pu' hasn't been looked at for > a long time; it is probably a good idea to discard and replace, if > you have something working. I submitted [1] over the weekend. I will add a spelling error patch and then submit version 3 hopefully before the end of the day. I am working on the test rename, but will wait to submit until after the wt-status.c patches cook and then go to mainline. Rationale: I haven't yet gone through the commit scripts to decided on the best proposed names. [1] https://public-inbox.org/git/20180901235256.4260-1-isch...@cox.net/
Re: How to handle patch series conflicts
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote: > I think that one that is not even in 'pu' hasn't been looked at for > a long time; it is probably a good idea to discard and replace, if > you have something working. I submitted [1] over the weekend. I will add a spelling error patch and then submit version 3 hopefully before the end of the day. I am working on the test rename, but will wait to submit until after the wt-status.c patches cook and then go to mainline. Rationale: I haven't yet gone through the commit scripts to decided on the best proposed names. [1] https://public-inbox.org/git/20180901235256.4260-1-isch...@cox.net/
Re: How to handle patch series conflicts
Stephen & Linda Smith writes: > Junio - > > On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote: >> > t7500-commit.sh >> > t7501-commit.sh >> > t7502-commit.sh >> > t7509-commit.sh >> >> These seem to have organically grown and it is very likely that ones >> later introduced were added more from laziness. > > How does the project prefer to handle patches that conflict. Renaming t7501- > commit.sh will conflict with a patch set that I submitted over the weekend > [1]. Should I treat them as totally separate? How about not doing the rename before the more important changes solidify? Alternatively, doing the rename as a preparatory clean-up and building the more important changes on top is also possible. > On Tuesday, September 4, 2018 3:36:11 PM MST Junio C Hamano wrote: >> * sl/commit-dry-run-with-short-output-fix (2018-07-30) 4 commits >> . commit: fix exit code when doing a dry run >> . wt-status: teach wt_status_collect about merges in progress >> . wt-status: rename commitable to committable >> . t7501: add coverage for flags which imply dry runs > > I noted that this patch set is similar to the one that I just submitted. Are > you thinking of not using mine (in which case I will drop it)? If not I will > add a patch to fix the committable spelling[2] and re-roll. I think that one that is not even in 'pu' hasn't been looked at for a long time; it is probably a good idea to discard and replace, if you have something working.
Re: How to handle patch series conflicts
On Wed, Sep 5, 2018 at 10:25 AM Stephen & Linda Smith wrote: > > Junio - > > On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote: > > > t7500-commit.sh > > > t7501-commit.sh > > > t7502-commit.sh > > > t7509-commit.sh > > > > These seem to have organically grown and it is very likely that ones > > later introduced were added more from laziness. > > How does the project prefer to handle patches that conflict. Renaming t7501- > commit.sh will conflict with a patch set that I submitted over the weekend > [1]. Should I treat them as totally separate? When doing a rename, this should merge fine without much complication, so I'd think it is fine to treat them separately. That way they can be merged to next/master independently.
How to handle patch series conflicts
Junio - On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote: > > t7500-commit.sh > > t7501-commit.sh > > t7502-commit.sh > > t7509-commit.sh > > These seem to have organically grown and it is very likely that ones > later introduced were added more from laziness. How does the project prefer to handle patches that conflict. Renaming t7501- commit.sh will conflict with a patch set that I submitted over the weekend [1]. Should I treat them as totally separate? On Tuesday, September 4, 2018 3:36:11 PM MST Junio C Hamano wrote: > * sl/commit-dry-run-with-short-output-fix (2018-07-30) 4 commits > . commit: fix exit code when doing a dry run > . wt-status: teach wt_status_collect about merges in progress > . wt-status: rename commitable to committable > . t7501: add coverage for flags which imply dry runs I noted that this patch set is similar to the one that I just submitted. Are you thinking of not using mine (in which case I will drop it)? If not I will add a patch to fix the committable spelling[2] and re-roll. [1] https://public-inbox.org/git/20180901235256.4260-1-isch...@cox.net/
