elasticsearch-py VS git-imerge

FD: I have a friend who works at Elastic, though he doesn't really colour my opinions of things.

> Firstly, dick moves like this: https://github.com/elastic/elasticsearch-py/pull/1623

I understand that this is unpopular, but you can make a very strong argument that it's to prevent weird errors in the future. I'm also guilty of littering my code with Asserts to ensure the universe is working fine.

The alternative is to allow it to work and then you end up with weird issues like when you connect mysql client to mariadb server (and vice-versa): https://stackoverflow.com/questions/50169576/mysql-8-0-11-er...

> Secondly, I don't buy the argument from Elastic any more. Yes, the ethical thing to do when you're making money from someone's work is at least contribute back. At the same time though, they're making money from packaging it up and selling it _as a service_. That "as a service" part is where they're making the bucks.

That's just an opinion, yes they have a service, and yes it competes with Amazon. Is it cool for Amazon to take a body of work and sell it without supporting it? Are amazon actually supporting it? Is it the same as Elastic using Lucene? (not really because Elastic submits a the majority of fixes to Lucene, but, you get it).

it's kinda gray, I'm sure Amazon thinks they're the good guy, but it's hard for me to look at Elastic as the bad guy in all this.

Oh man, https://github.com/elastic/elasticsearch-py/issues/1734 is a disappointing read. I know ES wants to save their business, but alienating users isn't exactly the path to success.

Afaik, there's currently no official way to pause/stash a rebase/merge-in-progress. (There is git-imerge which supports incremental merges/rebases (basically split a big merge into smaller ones), but I never used it and think you'll need to use it from the start of a merge/rebase.)

Try git imerge.

If the merge is large in the number of commits involved git imerge may be useful to you. It breaks down one big merge into many smaller merges, essentially merging one new commit from each branch, one at a time. The advantage being that you only ever need to consider the conflict between two individual commits at a time.

The repo for it is https://github.com/mhagger/git-imerge and the blog post / instructions is at https://wilsonmar.github.io/git-imerge/

Similar ideas have been discussed before in Git, but I don't think anyone has acted on them much. Michael Haggerty's git-imerge tries to make conflicts shareable, but I think it was more of a side-effect of the original goal of optimizing rebase/merge and auto-reducing conflicts to their minimal representation. I'm very curious how conflicts are represented in Jujutsu so I can better understand this power. I'm curious about how conflicts in conflict-resolution commits are handled and other such magic.

That gist seems like a simplified version of https://github.com/mhagger/git-imerge, so check that out if you haven't. (I haven't looked at git-imerge in a long time, so I should read about it again myself.)