Fork me on GitHub
#off-topic
<
2018-12-04
>
flefik09:12:05

i'm very much pro a rebase+squash+merge workflow. it has two major benefits (and one minor): 1. 'clean' history. This is useful because each commit will essentially have 1 parent, which let's you easily use git bisect. It's also takes up a lot less mental space to think about one linear timeline than. 2. the squash is useful because 'the history of a PR' is not something that is actually useful once the code is in master. It is only useful at the point of review (and you can squash on merge nowadays in gitlab for example). After that it just makes things harder to reason about, and makes it harder to look at the tree and find commits that are releasable. In the ideal world every commit in your history is green and passes your tests, and is possible to deploy to. Can you do that if you have a bunch of WIP in your history? 3. I like to keep the merge commit in the history because I like the look of the tree. Functionally there's no difference between a rebased branch and a rebased then merged branch. The drawbacks: 1. force pushing can overwrite other commits. Using --force-with-lease instead of --force stops this from happening. Commits are never really lost in git. git reflog and they will still be there. 2. you lose history of your PR. I think that if the PR is so large that this is a genuine concern, then the PRs are probably too large? All in all I think that the benefits of a rebase workflow far outweighs the benefits of a merge workflow especially in a codebase with a lot of developers, and coupled with tools to help automatically rebase where possible (Github, gitlab etc)

👍 12
futuro21:12:56

Why not use merge commits to encapsulate the “release commits”, and —first-parent to stop showing feature branch commits?

futuro21:12:16

Then you get the linear history you want without throwing any data away.

flefik14:12:40

You're totally right, i just like the look of a tree with merges 🙂

dpsutton16:12:12

i thought i was in off topic earlier. rebl for $3 a month is amazing

dpsutton16:12:23

(for commercial use. of course personal and open source are free as before)

Alex Miller (Clojure team)16:12:48

we look forward to realizing the many ideas we have for it! :)

Alex Miller (Clojure team)16:12:20

also, there is #rebl if you want to chat there about it

eggsyntax16:12:59

re: "You may not use REBL for commercial use (e.g. at or for work) unless...You are an active, paying customer of Datomic (Cloud or On-Prem)" Just to be entirely clear: what if you're doing work for a company which is a paying Datomic customer, but you personally are not a paying customer? I'm guessing you're covered in that case, but seems worth clarifying.

dpsutton16:12:55

i read that as "you are a licensed datomic user"

Alex Miller (Clojure team)16:12:04

individual users aren’t licensed

Alex Miller (Clojure team)16:12:38

I think if your company is a paying Datomic customer, then you are a Datomic customer and entitled to use REBL

👍 4
jaihindhreddy-duplicate16:12:31

$3 a month is awesome! Instantly got it, although we don't do Clojure at work. Hey, maybe one day.

richiardiandrea16:12:47

That is great indeed! My first question to this, just to probe, is there a plan for Cljs and a attemptative timeline? I would be interested in contributing the 💰💰 and support the development even if I am not a Clojure user at the moment. Thanks for the very nice news!

Alex Miller (Clojure team)16:12:13

Please file a github issue!

👍 4
richiardiandrea16:12:15

Ah ah @jaihindh.reddy you did it without questioning nice 😁

😄 4
jaihindhreddy-duplicate16:12:34

The line b/w what's for work and what's not gets blurred sometimes, so `᷅\(ヅ)/ ᷄

😄 4
👍 4
vemv20:12:11

signed up. It's a no-brainer to give some direct support to Clojure core 🙂 same for Clojurists Together.

todo23:12:18

Is it just me, or does $50 sound really realy expensive for a 20' displayport -> hdmi, 3240x2160 60fps cable ?

todo23:12:09

I don't get why these cables are so much more expensive than 10 Gbit ethernet cables