Jo, You did it again. You can't see the forest for the trees, as is often said. Writing these nitpicking emails do not help anything. I doubt any of us care if you can come up with a counter for every reason we write for merging over rebasing. In some sense, it is irrelevant. Like I said, you can still rebase your own PRs. So what is the point of arguing this? The fact that you have to go into detail to explain these things is the very reason we want to avoid it. None of this helps us make it easier for PRs to get merged. None of this helps to make it easier for less git savvy contributors. And this guideline does not affect your ability to rebase your own PRs.
Also, to reiterate, this guideline has been in place (maybe since before you started contributing). We've only made the guideline more clear here. If you want to start a thread to get consensus on a new policy about how we handle synchronization to master, then you can. Finally, if you would like to share an alternative solution to making it simpler and easier for PRs to get merged then, by golly, please do so. You've now written two long emails that do not come even close to offering an alternative solution to the problems we are trying to solve. Jason moorepants.info +01 530-601-9791 On Mon, Jul 13, 2015 at 12:41 PM, Joachim Durchholz <j...@durchholz.org> wrote: > Am 13.07.2015 um 20:10 schrieb Aaron Meurer: > >> - Greatly increases the complexity of git for new users. >> > > Agreed. I would recommend it only for people who are willing to write it. > > - You can create commits that don't do what they say they do. >> > > Yes for non-interactive rebases. > For an interactive rebase, you can and should review the commit comment. > > - You can lose data >> < >> https://asmeurersympy.wordpress.com/2009/06/22/how-to-permanently-lose-data-with-git-and-then-retrieve-it-again/ >> > >> . >> - git rebase puts your repository in a rebase "mode", which, unless >> you have the right tools in your prompt, you may forget you are in >> (this is how I lost a lot of data using it). >> > > Yeah, I can feel that pain. > "git status" is your friend for that. I made a habit of doing that before > starting to work on anything, and before committing, pushing, or about any > other git command (well, not every single command, but you get the drift). > That has been working quite well for me. > > - Rebasing requires you to force push, which gives you bad habits >> (particularly, the bad habit of force pushing). >> > > True. > Not a real issue for pushing PRs. > I *think* if I had write access I'd use a separate directory for updates > to the master repo. I'd probably want to configure git so that it refuses > to force-push from that directory, so that any bad habit can't have a > consequence. > > - Rebased branches are more difficult to review on GitHub. Normally, you >> see new commits at the bottom of the discussion, but when the branch is >> rebased, all commits are new commits. If the rebase squashes commits, you >> have no hope of seeing only the new changes. >> > > The bottom discussion always survives. > I *think* I saw code lines discussions survive, too, in those cases where > a chunk of lines survived the rebase. I'm not sure about when exactly that > works and when it does not. > > Essentially, a rebase requires another round of review to check that all > the things discussed are still in there. Maybe there's a way to diff the > rebase result against the state of the last commit on GitHub (there > certainly is on a local git but that's going to be too much burden on the > reviewer). In general, the policy should be "do not change anything under a > rebase". > > - Merge conflicts are more difficult to deal with when rebasing. >> > > I thought so myself, until I changed my approach to rebasing within my > working branch first, merge commits until each piece of code isn't modified > by more than one commit, *then* rebase with master. > So far, the net result was just the kind of conflicts that I'd have gotten > with a merge. > > - Most fundamentally, rebasing *changes the revision log*. This completely >> negates the whole purpose of using a version control system, which is to >> *track* *the revision log*. >> > > If this were true, Linus wouldn't have allowed rebasing in git. > > I think the revision log is a means to an end. The end being the ability > to reproduce previous revisions, and keep a record of decisions. Cutting > out decisions that were dead ends, misunderstandings, and multiple > iterations on less important stuff (PEP8 comes to mind) is a good thing; we > do not need the interim versions, and there are no relevant decisions > worthy of logging. > > Furthermore, git handles "non-clean" history just fine: >> >> - Use git log --graph when viewing history. Or use a tool that shows the >> history as a graph like gitk or gitx. >> > > I'm not nervous about the branches themselves. > What I find hard to read is long-running branches at the merge point; I'm > getting all the changes all at once; if I don't understand them, I have to > go back on the side branch, mentally rewinding to the point in time when > the side branch forked off. In the end, when I understand what the side > branch did and why, I usually find I forgot what I was investigating, so I > have to mentally rewind again. > I find this hard enough for two branches. If more than two branches are > involved, I expect that to become virtually impossible. > > Rebasing rearranges things into a linear history. I never have to rewind; > if I find something uninteresting, I can mentally skip ahead. > > - git bisect does handle merge commits. It only doesn't know what to do >> when there is an ambiguity (that is, the bad change comes from the merge >> resolution itself), which is rare. >> > > The more you merge the more often it will happen. > A lot depends on how many long-running branches are in existence I think. > > -- > 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 sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/55A4145F.9000403%40durchholz.org. > > For more options, visit https://groups.google.com/d/optout. > -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1Aj0PGEsA%2BMGQToq-YKKcgy86n4YgwfkrM6080mWb1yGcw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
