Bore da pawb

That article on rebasing is one of the reasons I don't use it for feature branches->master. I've definitely had the broken commit somewhere in a chain of many and also broken commits in messing up resolving conflicts. Arguably most of this could have been avoided if the org I was working for had either not used long living feature branches, committed to by many dev's, but in that particular culture it was the only sensible option.

Aloha

mogge 😼

my fix yesterday didn't fix the problem... so back to the drawing table.

thoughts and prayers @thomas

morning

thank you @otfrom

squash ftw

morning morning

The comments in that article were interesting too.

Always mixed opinions based on coloured lenses

idk I feel like rebase is something I reach for when I've messed up, but for day-to-day it's making a simple tool (git) unnecessarily complicated

same reason why I don't like using protocols in clj unless there's some serious interop going on

I guess my background is languages/humanities so I privilege being fluent/thinking in my lang and tools and if the vocab (feature set) expands beyond a point it's like one of those foreign languages with loads of tenses we don't have in english 😂

Leigh anois go curamach na treoracha agus na ceisteanna a ghabhann le Cuid A. Minigh an tuiseal ginideach...

Thanks for giving me a cold sweat flashback to my Irish exams dude

is irish a case-based language then @conor.p.farrell ?

in the aliens' language from arrival you can rewrite your branch history

Yes, you need to understand the genitive case, etc. etc. which is a right pain

I wish I could speak it better, but it's not taught very well in school

i did russian for a while, which is also case-based... i don't think cases were very well taught there either - i certainly only have a vague understanding of how to apply them now

The rebase article above is a bit of a strawman in my opinion — though I think unintentionally. Firstly there are many ways to do git… there are pros and cons to the different approaches… etc. Ultimately consider the options for your team, and do whatever works best for your team. Now the caveat is out of the way I agree with the wider point of the article. That is most teams with the rebase workflow have a silly desire to create an artificially linear history. This is IMHO completely misguided, mainly for the reasons the article states. However I think a better workflow is that feature branches should be rebased and tidied into a logical sequence, rebased ontop of upstream, and finally merged with --no-ff, i.e. I want linear sensible commits, but I want to see the boundaries of each feature, without “sync merges” blurring things. The problem with this approach is that most people do rebase wrong. So that dependencies on future commits are accidentally introduced & bisect etc becomes useless. The solution is simple which is that you need a rule for every commit to compile and pass the test suite (also every commit should be a single logical change). This is what you need to enforce for bisect to be truly useful, anyway… rebase is not to blame for not enforcing this. Essentially developers before pushing should run rebase -i and exec all the tests on each commit. The problem with the rule is that it requires a team with a lot of discipline; but it pays dividends when resolving conflicts, as you know all sides of the conflict work. If you don’t know this things become very difficult. The reason the article is a bit of a strawman is because they attack rebasing for breaking bisect; but bisect will be broken anyway without the discipline of enforcing (e.g. with ci) a rule that each commit works.

Also they accuse rebase of making merges more confusing — but rebases often (though not always) make merges easier; as you get to resolve the conflicts piecemeal rather than all at once.

I think ideally what you want to avoid is having visible “sync merges” in your history. You can do that two ways with the rebase strategy, or with git merge together with git rerere.

At the end of the day it’s a trade off between quality and unnecessary process/waste. If your team are struggling a lot with conflicts, then adopting the above strategy spreads the work across the team; rather than forcing it all into a stressful merge process. It does require a lot of discipline and git fu though, so it’s certainly not suitable for all teams.

does anyone here have any experience with react? (just plain JS, no what so ever, unfortunately)

I am rather stuck on a problem at the moment

not with plain JS, but you could try me

or try #reagent / #react-native / #re-frame ?

I expect someone in one of those would have some JS experience of React

good idea... thank you @peterwestmacott

what's your problem @thomas?

(i've mostly used react via reagent, but i have been using it for a good while and have occasionally had to descend down to the js levels)

has anybody here used apache flink?

@mccraigmccraig something seems to update my state... but I don't know what/where/when

@alex.lynham not properly, just kicked the tyres

@jasonbell that's more than me! what were you using it for?

Mainly to see if there was any features that would replace what I was doing in Kafka.

it's come across my desk in a 'shopping basket' list of tech and I'm trying to work out if that's because the person who put it there 100% knows something I don't, or if they were just writing down a bunch of things they saw on thoughtworks tech radar or whatever

Like I say, literally kicked the tyres. Some good stuff on Safari

(and I don't mean that in a mean way)

safari?

@alex.lynham yes the O'Reilly learning/book/vid platform

I think MapR were giving out some Flink things for free, Ellen Friedman had written them

ohhhh

sorry

I'm with you now

https://mapr.com/introduction-to-apache-flink/

some impressive performance stats I've seen, but performance isn't an issue we have

thanks for the link 🙂

@thomas ah, i've never used component-state - it's not really necessary with reagent

I know... this just confirms why and reagent/re-frame are so much better IMHO than react and JS.

redux does a similar thing to re-frame doesn't it ?

single-source-of-truth, reduce events onto that state with handler fns

I think it does... but not sure

word

re-frame is just an even more opinionated version

hee hee. thx the @keithmantell for making a #brompton channel

i'm not sure about cycling on roads @otfrom... it seems a bit unnatural

@mccraigmccraig I mix it up by riding through the park and on the cycle superhighway too

it is all deeply, deeply unnatural, but that is just the mechanically enhanced world we live in

brompton photo won't be there for long