This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (1)
- # announcements (10)
- # aws (2)
- # beginners (134)
- # calva (25)
- # cider (29)
- # cljs-dev (43)
- # clojure (130)
- # clojure-dusseldorf (3)
- # clojure-italy (27)
- # clojure-nl (48)
- # clojure-spec (32)
- # clojure-uk (63)
- # clojurescript (75)
- # core-logic (5)
- # cursive (18)
- # datascript (2)
- # datomic (37)
- # emacs (5)
- # figwheel (13)
- # figwheel-main (55)
- # graphql (1)
- # java (7)
- # jobs (11)
- # jobs-discuss (19)
- # juxt (1)
- # leiningen (16)
- # luminus (10)
- # mount (3)
- # off-topic (40)
- # om (1)
- # onyx (1)
- # pedestal (7)
- # re-frame (40)
- # reagent (81)
- # ring (2)
- # shadow-cljs (32)
- # spacemacs (5)
- # testing (1)
- # tools-deps (48)
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.
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...
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
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'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)
@mccraigmccraig something seems to update my state... but I don't know what/where/when
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
I think MapR were giving out some Flink things for free, Ellen Friedman had written them
some impressive performance stats I've seen, but performance isn't an issue we have
@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.
@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