On Thu, Aug 26, 2021 at 3:09 PM Chris Smith <[email protected]> wrote: > > > many PRs need to make changes to the end of the same file. A simple fix is > > to make it so that the changes are not at the end > > Can't you just put a decorator line (or comment?) on the last line so > anyone's name would come before that?
I don't think that would fix it. Git can't automatically merge two changes in the exact same place in a file, the end or otherwise. If you think about it, say a file in master looks like A D E F and one person's branch adds a line A +B D E F and another person's branch adds another line A +C D E F then how can git merge the two changes together? Even if it assumes that both new lines should be there, what order should they go in, ABCDEF or ACBDEF? Git refuses the temptation to guess and makes the user specify how it should be done, in the form of a merge conflict resolution. Aaron Meurer > > /c > On Wednesday, August 25, 2021 at 4:26:49 AM UTC-5 Oscar wrote: >> >> On Wed, 25 Aug 2021 at 09:22, Aaron Meurer <[email protected]> wrote: >>> >>> On Tue, Aug 24, 2021 at 6:30 PM Oscar Benjamin >>> <[email protected]> wrote: >>> > >>> > On Wed, 25 Aug 2021 at 01:07, Aaron Meurer <[email protected]> wrote: >>> > > >>> > > Are you simulating having the PR run in a "merged with master" state >>> > > when running the authors script on CI? Maybe we should update the >>> > > script itself so that it can do this. >>> > >>> > It's not a simulation. When a PR is pushed GitHub actions will make a >>> > temporary commit that merges the PR into master and then all tests run >>> > on that commit. The problem I'm referring to is that usually if you >>> > suggest that a contributor should "merge with master" in their PR the >>> > merge is in the opposite direction (merge master into the PR rather >>> > than PR into master). For most purposes this doesn't make any >>> > difference because the final state of the changes to files is the >>> > same. However the authors script looks through the topological order >>> > of the commits and that is not the same in both situations. That's why >>> > currently a rebase is needed: before the PR can be merged the >>> > topological order needs to correspond to the chronological order in >>> > which PRs are merged (but before the PRs are merged the *eventual* >>> > chronological order is not actually known). >>> >>> Right, the point is that the script currently doesn't give the same >>> results in a branch vs. that branch after being merged into master (or >>> rebased on top of master). But I think we could modify it so that it >>> does do this. I don't know if there's a fancy git command we can do, >>> but I think the simplest way would be to clone the repo into a temp >>> directory and merge the branch into master before running the git log >>> --topo-sort. >>> >>> But even so, I don't think this will solve the merge conflict problem >>> which, unless I am mistaken, will happen just from multiple people >>> adding names to the bottom of the file. >> >> >> Yes, the merge conflict issue comes from insisting that many PRs need to >> make changes to the end of the same file. A simple fix is to make it so that >> the changes are not at the end e.g. by listing the names in alphabetical >> order. >> >> The bin/authors_update.py script has a load of code to carefully get the >> order right so presumably at some point someone thought that the ordering >> was important. It's possible that we could have the names temporarily stored >> in alphabetical order in a separate file that isn't included in the release. >> Then before release a script could collate the names and write them to the >> AUTHORS file in commit order. >> >> I wonder how other projects do this... >> >> >> Oscar >> > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/333e6bab-d872-4d89-bf1a-e4fa92637221n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JzHJxBbkBJdgLs7rM8SArvb2WSSEnqNtLWZOjDSs%2BRKw%40mail.gmail.com.
