Re: [python-committers] Do people prefer pushing feature repos or one massive patch?
I'm in the other camp. The way I see it, a squash of history or massive patch file loses history. It loses details about the thought process of the implementer. It masks mistakes and obscures motivations. It also masks decisions made in the merge operation, further hiding potential problems. On the other hand, a feature repo (or any separate series of commits), while retaining the history as it happened and thus the fidelity of the development, can always be mechanically reduced to a squashed patch (for review or other considerations, and in fact, the Python bug tracker will produce these squashed patches from feature repos automatically even if they're hosted in another system). Rollback is trivially easy; reverting a merge is as easy as reverting a squashed commit. It has the added benefit that any individual commit can be backed out automatically (in a squashed patch, that's not possible). In other words, it's straightforward and easy to go from the latter model to the former, and generally impossible to reverse the operation. In my opinion, it boils down to whether the group wants to restrict the options available for review. I would recommend that a contributor provide (or maintain) a feature repo if convenient. -Original Message- From: python-committers [mailto:python-committers-bounces+jaraco=jaraco@python.org] On Behalf Of Nick Coghlan Sent: Thursday, 02 April, 2015 01:35 To: python-committers Subject: Re: [python-committers] Do people prefer pushing feature repos or one massive patch? On 2 April 2015 at 04:09, Ethan Furman wrote: > I like one massive patch, myself. :) Aye, I'm also in the "squash for the clean history" approach. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Do people prefer pushing feature repos or one massive patch?
On Apr 02, 2015, at 12:06 PM, Jason R. Coombs wrote: >The way I see it, a squash of history or massive patch file loses history. It >loses details about the thought process of the implementer. It masks mistakes >and obscures motivations. It also masks decisions made in the merge >operation, further hiding potential problems. In general I agree. Coming from bzr, it's very rare that merges get rebased first, but bzr has a strong "mainline-of-development" view that tends to make squash-before-merge unnecessary. diffs, bisects, logs, etc generally follow first-parents by default so you don't see all the subcommits, unless you want to, which sometimes you do. git doesn't really follow this tradition (although some commands have an option to follow first parents). Not sure about hg. Cheers, -Barry ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] changing the python version on the 2.7 branch
On 04/02/2015 07:38 AM, Nick Coghlan wrote: > On 2 April 2015 at 05:05, Matthias Klose wrote: >> We'll have the 2.7.10 release in the coming months. This will be the first >> release with a two digit subminor version number, so please could we prepare >> for >> that early? Feature tests in python are unfortunately way too often based on >> version comparisons. Suggesting to push the following patch to the 2.7 >> branch. >> >> The patch also changes PY_RELEASE_LEVEL to "beta" quality. Currently this >> is a >> value which is not touched on the branches. > > I think this is a good idea, but I'd suggest using "2.7.10b0" as the > interim version string, rather than "2.7.10-". now checked, using the "2.7.10b0" string. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Do people prefer pushing feature repos or one massive patch?
Where I come from we always squash. More detailed history is preserved in the code review tool (which keeps a snapshot every time you bounce it back to the reviewer). Looking at my own sub-commits when I'm working on a complex feature or bug fix, they are often checkpoints with no particular significance except that the code is syntactically correct, and a common reason for doing a sub-commit is when I've got to attend to something else (e.g. a meeting). On Thu, Apr 2, 2015 at 6:31 AM, Barry Warsaw wrote: > On Apr 02, 2015, at 12:06 PM, Jason R. Coombs wrote: > > >The way I see it, a squash of history or massive patch file loses > history. It > >loses details about the thought process of the implementer. It masks > mistakes > >and obscures motivations. It also masks decisions made in the merge > >operation, further hiding potential problems. > > In general I agree. Coming from bzr, it's very rare that merges get > rebased > first, but bzr has a strong "mainline-of-development" view that tends to > make > squash-before-merge unnecessary. diffs, bisects, logs, etc generally > follow > first-parents by default so you don't see all the subcommits, unless you > want > to, which sometimes you do. > > git doesn't really follow this tradition (although some commands have an > option to follow first parents). Not sure about hg. > > Cheers, > -Barry > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > -- --Guido van Rossum (python.org/~guido) ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Do people prefer pushing feature repos or one massive patch?
On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum wrote: > Where I come from we always squash. More detailed history is preserved in > the code review tool (which keeps a snapshot every time you bounce it back > to the reviewer). Looking at my own sub-commits when I'm working on a > complex feature or bug fix, they are often checkpoints with no particular > significance except that the code is syntactically correct, and a common > reason for doing a sub-commit is when I've got to attend to something else > (e.g. a meeting). I think a lot depends on the personal style of the committer. I don't do checkpoint commits, but only (try to do) commits where everything works and the tests pass, and the commit is reviewable as a single unit. I don't think there's a right or wrong way to do this, I think it depends on how the person doing it thinks and organizes their work best. I don't see a lot of value in preserving the history of someone who uses the checkpoint-commit style, but I do see potential value in preserving the history of someone who uses the atomic-commit style. Perhaps we should leave it up to the committer, based on that guideline? (Given our other preferences, I think a rebased commit would be the way to go if history is preserved.) But, if we feel a need to pick just one, I'd pick squashed. --David ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Do people prefer pushing feature repos or one massive patch?
On 2 April 2015 at 18:15, R. David Murray wrote: > On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum wrote: >> Where I come from we always squash. More detailed history is preserved in >> the code review tool (which keeps a snapshot every time you bounce it back >> to the reviewer). Looking at my own sub-commits when I'm working on a >> complex feature or bug fix, they are often checkpoints with no particular >> significance except that the code is syntactically correct, and a common >> reason for doing a sub-commit is when I've got to attend to something else >> (e.g. a meeting). > > I think a lot depends on the personal style of the committer. I don't > do checkpoint commits, but only (try to do) commits where everything > works and the tests pass, and the commit is reviewable as a single unit. > I don't think there's a right or wrong way to do this, I think it > depends on how the person doing it thinks and organizes their work best. > I don't see a lot of value in preserving the history of someone who uses > the checkpoint-commit style, but I do see potential value in preserving > the history of someone who uses the atomic-commit style. Perhaps we > should leave it up to the committer, based on that guideline? (Given > our other preferences, I think a rebased commit would be the way to go > if history is preserved.) > > But, if we feel a need to pick just one, I'd pick squashed. I tend to develop patches using Mercurial Queues, so I naturally produce squashed commits. On the other hand, I very frequently do checkpoint-style commits (sometimes even partially-completed work that doesn't pass tests) because I move between 2 PCs, and keeping work in progress just in the working directory isn't an option in that case. Generally, I prefer squashed commits in any case. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
