Merging instead of rebasing

[Jason Moore]

FYI: We had a discussion at SymPy on how to synchronize with master and decided that we no longer want to allow or encourage rebasing after a pull request is made to the main SymPy repo.

The main reason is that we stall too many new contributors by forcing them to do too much git kung fu. But there are additional important reasons too:

- Once a pull request is "public" the history should not change because other people may have pull it.
- Rebasing with merge conflicts is much more difficult

- Reviewers are no longer able to see commit by commit changes in a review process.

- Github does not manage the diffs in a PR review if a rebase happens.

The development docs have been updated:

https://github.com/sympy/sympy/wiki/Development-workflow#synchronization-with-master-sympysympy

If you want to rebase then you should do it before you make a pull request, either locally or on your fork's branch.

Jason
moorepants.info
+01 530-601-9791

[Joachim Durchholz]

Am 12.07.2015 um 00:17 schrieb Jason Moore:
> The development docs have been updated:
>
> https://github.com/sympy/sympy/wiki/Development-workflow#synchronization-with-master-sympysympy

Where do I find the img/ subdirectory?
img/dev-guide-apitoken.png needs removing (the API token section in
Account Settings does not exist on GitHub anymore).

[Joachim Durchholz]

Am 12.07.2015 um 00:17 schrieb Jason Moore:

> FYI: We had a discussion at SymPy on how to synchronize with master and
> decided that we no longer want to allow or encourage rebasing after a pull
> request is made to the main SymPy repo.

I think that's overstated.

I see some reasons against merging:

A) A history with merges is harder to read. You need to track multiple
parallel developments, and that's particularly hard if merge conflicts
were resolved (because some of the code you see didn't get into master,
at least not in the form it's committed initially).

B) The results from `git bisect` become harder to read if a bug stems
from the combination of two changes that were made in parallel branches:
the bisect will point at the merge commit, but the actual problem
happened in some earlier commit.
The more parallel branches in existence, the more prominent this will
become.

> The main reason is that we stall too many new contributors by forcing them
> to do too much git kung fu.

This problem can be mitigated via interactive rebasing, but I agree it's
an extra hoop to jump through and cannot be asked of everyone.

> But there are additional important reasons too:
>
> - Once a pull request is "public" the history should not change because
> other people may have pull it.

Does anybody ever pull from a pull request?
I can see that happening when collaborating on a fix, but it's not
something affecting newbies.

> - Rebasing with merge conflicts is much more difficult

Only if you try to rebase everything in a single go. You may end up
resolving the same conflict over and over for each commit, and that can
get confusing very quickly, and it's also annoying and a lot of needless
work.

However, there is a process that's actually quite easy:
1) `git rebase --interactive` first; this is a rebase *within your
working branch*.
I also squash commits that were a continuation of previous work. I.e. if
I have a sequence of 1.code - 2.reformat - 3.code - 4.bugfix -
5.reformat - 6.code - 7.bugfix - 8.reformat, I like to rearrange this to
1.code - 3.code - 4. bugfix - 6.code - 7.bugfix - 5.reformat -
7.reformat, and then I squash this into two commits, one with 13467 for
the coding and 57 for reformatting.
If this still is confusing, this can be broken down into a series of
primitive steps: (a) swap two commits, leaving all others alone, (b)
merge two adjacent commits, leaving all others alone; repeat until the
history is rewritten in a way that's easy to read and review.
2) `git fetch master && git rebase master`. This will expose the merge
conflicts, but now it's far less commits, and it's also giving you much
less pain because most conflicts will apply just in one commit.

> - Reviewers are no longer able to see commit by commit changes in a review
> process.

Only if you squash everything into a single commit.
Reordering and squashing commits makes sense if some work jumped between
multiple things, such as reformatting, fixing docstrings, and actual
code changes (and if the code changes touched multiple loosely-related
points, it may make sense to keep these in separate commits anyway).

> - Github does not manage the diffs in a PR review if a rebase happens.

You mean the "click here to see outdated diffs" thing?
Sure, part of the discussion are removed one more click, which means
that people won't know to look there and usually won't find them.
However, if a discussion is relevant for posteriority, it should have
been merged into the commit in some way, either into the commit comment
or in a code comment or docstring. After all, people who're looking at
`git annotate` or `git log` aren't going to see these discussions either.

> If you want to rebase then you should do it before you make a pull request,
> either locally or on your fork's branch.

Oh, now I see what's the concern - indeed, rebasing on the main repo is
bad, very bad, and a real no-go. But that's a non-issue!

For pull requests, they're on separate branches, and people don't work
on the PR branch of anybody else (unless they explicitly have agreed to
cooperate in that way, in which case the work branch should indeed not
be rebased anymore unless all downstream collaborators agree).

Newbies don't even have the permissions to modify the main repo.

The one point where I see strong language against rebasing justified is
when merging into master on the main repo. This is merge, and merge
only, and should be written in bold letters into the project maintenance
guidelines.
For people who contribute pull requests, I do not think that applies.

YMMV, but I'd be interested to hear why.

Regards,
Jo

[Jason Moore]

Joachim,

Thanks for the start of the bike shedding, you are becoming a master at it.

You can always do what you want on your own pull request if your reviewers are fine with your synchronization strategy, but we want to make the default behavior be centered on merging. This means that reviewers should not ask for or encourage rebasing on an open pull request and thus we should encourage merging. It's not that big of deal and we do not see any negative aspects from disallowing rebasing that outweighs the benefits it gains.

If you actually have very specific proof that the cost from this guideline outweighs the benefits then we can discuss. But this has been SymPy's underlying guideline for sometime now. Rebasing has crept back into people's minds lately for some reason, so this simply clarifies an existing guideline which many of the main devs reached consensus on at the SciPy BoF session.

Jason
moorepants.info
+01 530-601-9791

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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/55A22B0B.20405%40durchholz.org.

For more options, visit https://groups.google.com/d/optout.

[Joachim Durchholz]

Am 12.07.2015 um 16:36 schrieb Jason Moore:
> Joachim,
>
> Thanks for the start of the bike shedding, you are becoming a master at it.

Thanks.
If that's what you think, I'll simply shut up.

Jo

[Jason Moore]

Jo,

That is what I think, but I'm not asking you to shut up. Rather, I'd like for you to raise legitimate concerns instead of picking apart every single thing I wrote in the first email. Those kinds of responses are tiresome and are not focused on being productive. I'm happy to chat about this more if you want.

Jason
moorepants.info
+01 530-601-9791

Jo

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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/55A2B412.2060409%40durchholz.org.

[Joachim Durchholz]

Am 12.07.2015 um 23:17 schrieb Jason Moore:
> That is what I think, but I'm not asking you to shut up.
> Rather, I'd like for you to raise legitimate concerns

Well, you're telling me I'm a "master of bikeshedding", which is a
serious insult.
Plus you're dismissing arguments on an issue like git workflow that's
neither as simple nor as unimportant as shed color.

I'm done arguing against that stance.

> instead of picking apart every single
> thing I wrote in the first email.

That was just to give feedback where I stand on each point.

Remember I wasn't in the discussion, so I had to condense all the points
I'd have raised into a single post.

> Those kinds of responses are tiresome and
> are not focused on being productive.

I think you're applying that conclusion to the wrong response.

> I'm happy to chat about this more if you want.

This isn't the first time we disagreed about relevant points without
resolution, so I'm sceptical that talking is going to help at all.

I'm not too comfortable with chat in general. Right now, I'm also
mightily pissed off, and chat wouldn't filter that as well as mail does,
so chat could be really destructive.

Jo

[Matthew Brett]

Completely from the peanut gallery but

A humble plea to use the term 'bike-shedding' only in the situation
where everyone in the discussion gladly agrees that the discussion is
on an unimportant peripheral point.

[Jason Moore]

Jo,

I apologize for insulting you. What I originally said was not polite or thoughtful and as Matthew mentions, in this case I may have misused the word bike-shedding. I have no intention of insulting you but I find that the majority of your responses to emails/pr/issues are in essence nitpicks or bikesheds. I feel exhausted reading most of them and at this point I try to avoid reading your responses at all. This last response to my email, which was simply a reminder of a current "policy", irked me enough to finally say something more explicitly.

I am happy to have a conversation in whatever medium you want about this once you are willing to. I do think we can come up with something worthwhile, as we are both reasonable people.

​

[Joachim Durchholz]

Am 13.07.2015 um 16:39 schrieb Jason Moore:
> I apologize for insulting you.

Okay.

> I have no intention of insulting you but I find that
> the majority of your responses to emails/pr/issues are in essence nitpicks
> or bikesheds.

Yeah... it's all things that one of the project leads or another has
insisted on in the past.
Personally, I'm happy with whatever the bikeshed color is, but if the
majority said "yellow" then I'm telling newbies to do yellow. Except it
doesn't help if one project lead steps in and insist on light brown,
because that's how he perceived that color (and sometimes a project
leads insists on green, because he doesn't remember, or cares more about
personal pet peeves, or both).
Things are getting even worse if somebody tries to clean up PEP8 stuff,
at which point somebody else steps in and declared that it's bad for the
git log. So I take home that the git log is important (which I can agree
with), and now I see a policy for merging which is bad for the git
log... really, this all is driving me mad.

Oh, and all of this bikeshedding and sidetracking discussion while I'm
waiting for the really interesting stuff to even get discussed, let
alone merged.
So there's that source of frustration for me - my nitpicking and
bikeshedding is just a mirror of what I get from the project, and trying
to make it (mostly) unnecessary to do PEP8 cleanup but now *you* are
dissatisfied.

Plus, there are things about SymPy that are harder to fix and more
difficult to reach a consensus about than PEP8 or even git workflow, but
if we cannot get the project itself to stick with these simple things, I
have little hope that the complicated stuff will ever get done in a
sustainable fashion. We already have lots of orphaned code (I
wholeheartedly agree to the push for module maintainers, though maybe
"coordinator" would be a better term - as rightfully said, it's not
important that the person in charge knows everything, knowing whom to
ping in case of trouble is more important).

> I feel exhausted reading most of them and at this point I try
> to avoid reading your responses at all. This last response to my email,
> which was simply a reminder of a current "policy", irked me enough to
> finally say something more explicitly.

Well, the announcement irked me because
a) it got some facts wrong,
b) it presented a conclusion that I consider less than ideal,
c) it hinted at a discussion with no way to check the discussion and see
how the consensus was reached, iow it was a decree "from above", and
hence not open to revision and soon going to be gospel to be followed by
the letter instead of guidelines where people have a chance to know when
it's appropriate to follow them and when not,
d) it's very strong language that massively overstates the policy.

Not in order of relevance, I think (b) was least relevant to me.

> I am happy to have a conversation in whatever medium you want about this
> once you are willing to. I do think we can come up with something
> worthwhile, as we are both reasonable people.

I have started questioning whether SymPy is worthwhile for me.
Partly for reasons in the project (the above is an overly long
exposition - sorry for that! - of a large part of them), partly for
reasons on my side (other projects, dissatisfaction with Python as a
language, that kind of stuff).

[Jason Moore]

> Yeah... it's all things that one of the project leads or another has insisted on in the past.

Note that rebasing vs merging has been insisted on in the past by our project lead, e.g. https://groups.google.com/forum/#!topic/sympy/MnlVfmYYMio

My email simply reminded us of that and strengthened the wording so that it is clear.

> my nitpicking and bikeshedding is just a mirror of what I get from the project

If that is what we do, the maybe following the project's lead isn't good. Why not be the force that helps reduce the time wasted over less important details instead of the opposite? Maybe you could focus your energy on purging and rerouting frivolous conversations instead of fueling them to grow larger and longer.

> Oh, and all of this bikeshedding and sidetracking discussion while I'm waiting for the really interesting stuff to even get discussed

We are all thinking the same thing, yet we must disagree on the sources of these discussions.

Our mission is to make the best open source full featured CAS...under some constraints:

1. Most, if not all, of our developers are volunteers.

2. We reach consensus on decisions among core devs (ideally all devs and users), with a fall back to the BDFL model when decisions stall.

3. and more..

For #1 we have to all be extremely considerate of others time. Everything thing you request from another person should consider their time. If you can help minimize the time they have to invest by giving your time or other resources, then you should do that. Each and every email, comment, and request you send takes time from a volunteer that they'd likely prefer to have for themselves.

For #1 we also have to be very considerate of motivation and moral. We don't get monetary rewards or many other traditional compensations for our time. We can offer reputation, friendship, networking, altruism, community, etc. These may or may not be valuable to contributors. Most volunteers will not put up with much BS for the rewards we can offer. So we need to always think about how to maximize the benefits we can give, minimize the BS, and whether this can retain motivation for the time and energy each contributor provides.

We also need to maximize our number of volunteers for the reason that "many hands make light work". We pride ourselves on having more contributors that provide substantial contributions at any given time than many other scipy projects. We'd love for this to increase more but this makes #2 more difficult. This also requires that we lower the barrier to entry as much as possible, without compromising the general project quality.

For #2, I want to remind everyone that consensus doesn't mean that you have to 100% agree with every decision that is made. It also doesn't mean that you should bog down or halt decisions that you don't 100% agree with. We always have to keep in mind that consensus is for the group's needs, not the individual's. A participant in a consensus based decision should start with thoughts like: "What outcome will best serve the group?", "Will this decision deter or slow us from furthering our mission, given the constraints?",  "What is the minimum I can personally accept and deal with so that we can move this decision forward (not backward!)?", "What is the essence of this discussion, i.e. the most important thing that needs to be decided?", "Is this decision essential to furthering our mission?". If we all keep these things in mind, then the trivial discussions will start to disappear and we will collectively focus on moving forward with minimal overhead. We should all practice at identifying things that are causing decisions to stall/halt and pointing them out so that we can get over the humps quickly and efficiently.

When I think about this merging vs rebasing issue, the essence is that we want to minimize the barrier to entry given that we currently use Git/Github. Merging is by far a lower barrier than rebasing and we've had numerous PRs stall over this, much confusion in PRs, and loss of new contributors due to it. Is instituting merging worth some of us having to view a less than perfect git history and a having a little more overhead on git bisecting, for example? In my eyes, and I believe everyone at the SciPy BoF, the issues you bring up are extremely minor when compared to the problem we will solve by strengthening this guideline. A perfect git history and easier git bisecting are not essential to our mission, but increasing and retaining contributors is.

Jason
moorepants.info
+01 530-601-9791

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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/55A3E779.5000305%40durchholz.org.

[Aaron Meurer]

I've probably made my position clear before on this, but to restate it: I hate rebasing. You should never do it, and you should absolutely never tell others to do it. 

I may write a blog post at some point in more depth about this, but here's a "short" version of some of the issues with rebasing:

- Greatly increases the complexity of git for new users.

- You can create commits that don't do what they say they do.

- You can lose data.

- Rebasing requires you to force push, which gives you bad habits (particularly, the bad habit of force pushing).

- 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).

- 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.

- Merge conflicts are more difficult to deal with when rebasing. 

- 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. 

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.

- 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. 

Regarding bikeshedding, this maybe should be a separate discussion (which I fear will itself be bikeshedded, but oh well). But we should make an effort to cut down on it. 

In fairness, though, if you post a controversial topic to the mailing list, you are inviting discussion on it. 

Aaron Meurer

[Matthew Brett]

Hi,

On Mon, Jul 13, 2015 at 7:10 PM, Aaron Meurer <asme...@gmail.com> wrote:
> I've probably made my position clear before on this, but to restate it: I
> hate rebasing. You should never do it, and you should absolutely never tell
> others to do it.

Was there some point where y'all agreed on this as project policy?

We do rebases all the time on PRs over at numpy and scipy.

Cheers,

Matthew

[Jason Moore]

Yes, we've had it in wiki for a while and I quoted a previous email that stated it.

I'd say we are different that numpy and scipy in that sense. This is may be one of the reasons we have more contributors with > ~10 commits than those projects have.

Jason
moorepants.info
+01 530-601-9791

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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/CAH6Pt5oyz50UdkEcUV6h0nFEVGoFSnARY5M8Wqr4SHwUvzyZnQ%40mail.gmail.com.

[Jason Moore]

Also, to restate this: this rule doesn't prevent you from rebasing **your** PR if the reviewers are fine with you doing that.

We simply want to have the norm be merging and we want to stop having people asking our contributors (especially new ones) to rebase.

Jason
moorepants.info
+01 530-601-9791

[Matthew Brett]

On Mon, Jul 13, 2015 at 7:40 PM, Jason Moore <moore...@gmail.com> wrote:
> Yes, we've had it in wiki for a while and I quoted a previous email that
> stated it.

Yes, sorry not to be clear - I was really wondering out loud whether
this was something that was debated fully at the time, I was not at
all questioning whether it was good policy or even if it was standard
sympy policy.

> I'd say we are different that numpy and scipy in that sense. This is may be
> one of the reasons we have more contributors with > ~10 commits than those
> projects have.

It might be - but there are so many differences between these
projects, it's hard to be sure.

Cheers,

Matthew

[Jason Moore]

This has been debated in a variety of emails, issues, pull requests, chats, and in person over the years. It'd take some time to collect all of those instances for concise review. There is no one authoritative thread that reached consensus that I know of. The email from Aaron that I quoted earlier is the first time it was written down and there were no complaints on that thread at that time. Thus, it's been the underlying written guideline now for > 2 years. I'm not sure what has caused it but we've recently had a resurgence from reviewers requiring contributors to rebase their PRs (and also to split PRs).

And yes, there are many differences in the projects, and my proposal is speculation, although we do have some data on contributor comparison among the main SciPy projects. This issue was brought up at the SymPy BoF at SciPy because one of the complaints we got during the BoF was from a user that gave up because he was requested to rebase and he ended up in a git hole. He hasn't contributed since.

Jason
moorepants.info
+01 530-601-9791

Cheers,

Matthew

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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/CAH6Pt5rt1oSX%2BNasgN79OyQK%3Dc41M8M9NdbsOBURTgvMnEo-kw%40mail.gmail.com.

[Matthew Brett]

On Mon, Jul 13, 2015 at 8:04 PM, Jason Moore <moore...@gmail.com> wrote:
> This has been debated in a variety of emails, issues, pull requests, chats,
> and in person over the years. It'd take some time to collect all of those
> instances for concise review. There is no one authoritative thread that
> reached consensus that I know of. The email from Aaron that I quoted earlier
> is the first time it was written down and there were no complaints on that
> thread at that time. Thus, it's been the underlying written guideline now
> for > 2 years.

I realize that this stuff above probably took a little while to
compile, but that seems to me to be a good summary, that you can point
people to, if they disagree, so that they can do the work needed to
make arguments that haven't already been discussed fully.

> I'm not sure what has caused it but we've recently had a
> resurgence from reviewers requiring contributors to rebase their PRs (and
> also to split PRs).

It's such standard practice in other projects that I know of, it's not
surprising to me that it keeps coming back.

> And yes, there are many differences in the projects, and my proposal is
> speculation, although we do have some data on contributor comparison among
> the main SciPy projects. This issue was brought up at the SymPy BoF at SciPy
> because one of the complaints we got during the BoF was from a user that
> gave up because he was requested to rebase and he ended up in a git hole. He
> hasn't contributed since.

Yes, I'm sure that does happen from time to time.

Cheers,

Matthew

[Joachim Durchholz]

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.

[Jason Moore]

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

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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.

[Joachim Durchholz]

Am 13.07.2015 um 23:58 schrieb Jason Moore:
> 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.

That's a cheap shot. Complaining I write too much, then complaining I'm
not giving substance - plus, summarily ignoring the actual arguments.
That's not trying to be helpful, that's trying to make me shut up.

I didn't think it could happen, but now I'm really mad at you.

Jo

[Jason Moore]

Jo,

I'm sorry you think these are cheap shots. That is certainly not the intention. I'm not trying to make you shut up, but I am trying to point out that this thread is not helpful to solving the problems we are trying to solve. I don't mind you writing too much if it is about something that will help us move forward. And yes you are giving substance that may be very useful to another conversation, but it isn't for this one. Your responses are diverting us away from the main issue so that we dwell on very minor details about git. I'm not interested in arguing over the fine details of git rebasing and merging. I want to discuss a comprehensive solution that minimizes the git kung fu overhead for sympy contributors. If you have a suggestion for that, please make it. Otherwise, let's close this thread and see how it goes with a strengthened merging policy. If it sucks we can always change it back later.

If you want to speak over a google hangout maybe we can avoid the email misunderstandings.

Jason
moorepants.info
+01 530-601-9791

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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/55A4E535.9040201%40durchholz.org.

[Joachim Durchholz]

Am 14.07.2015 um 16:05 schrieb Jason Moore:
> I want to discuss a comprehensive solution that
> minimizes the git kung fu overhead for sympy contributors. If you have a
> suggestion for that, please make it.

I did, but that got ignored.

[Jason Moore]

It wasn't ignored, I just don't see it. All I see are detailed agreements or counters to each point that has been mentioned to be negative about rebasing.

Here is my two sentence solution:

Rebasing has enough substantial negative effects on contributions that we'd like to avoid encouraging it and using it in SymPy development. The few benefits that rebasing offers are not worth the cost of the loss contributions.

Can you write a two sentence solution to solving the loss of contributions due to git kung fu issues? I'm happy to read it if so.

Jason
moorepants.info
+01 530-601-9791

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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/55A51C13.2070900%40durchholz.org.

[Joachim Durchholz]

Am 14.07.2015 um 16:39 schrieb Jason Moore:
> It wasn't ignored, I just don't see it. All I see are detailed agreements
> or counters to each point that has been mentioned to be negative about
> rebasing.

Indeed, I misrepresented that a bit.
I can't hope to discuss solution details if we don't even agree on the
analysis. Even less if the solution isn't 100% complete yet.

> Here is my two sentence solution:
>
> Rebasing has enough substantial negative effects on contributions that we'd
> like to avoid encouraging it and using it in SymPy development. The few
> benefits that rebasing offers are not worth the cost of the loss
> contributions.
>
> Can you write a two sentence solution to solving the loss of contributions
> due to git kung fu issues? I'm happy to read it if so.

1) I think the negative effects can be nullified by giving people a
tried-and-true, undoable git workflow ("I think" is what I meant with
"incomplete" above).
2) Rebasing is the only way to clean up a PR that has undergone several
rounds of review.

My two-sentence position on the current official policy:

A) Rebasing is indeed a more advanced use of git, so it should never be
requested, and recommended only with a reference to the explanation of
the workflow.
B) The current official policy is too strict, the justifications are
either bogus or can be avoided.

[Matthew Brett]

Maybe there is a way of making clear that this is guideline rather
than a rule, something like:

"Rebasing is sometimes useful, but, please check with your PR
reviewers before doing a rebase, for the reasons given below. Your
reviewers will also be careful about rebasing; our policy is that all
current reviewers of a particular PR should agree that a rebase is
necessary before suggesting you do one. In particular, if you are
trying to update with the main Sympy codebase, we much prefer you
merge rather than rebase."

? I've certainly done PRs where I had a set of changes that I had to
rewrite completely on the basis of comments, so that the full history
would have been useless and distracting, and an interactive rebase was
obviously the best way to clean that up. It seems like a good idea to
allow for that possibility, which I think is the main case Jo is
worrying about.

Cheers,

Matthew

[Joachim Durchholz]

Am 14.07.2015 um 18:10 schrieb Matthew Brett:
> ? I've certainly done PRs where I had a set of changes that I had to
> rewrite completely on the basis of comments, so that the full history
> would have been useless and distracting, and an interactive rebase was
> obviously the best way to clean that up. It seems like a good idea to
> allow for that possibility, which I think is the main case Jo is
> worrying about.

You're right on spot with that.