Perhaps even by starting threads to generate conversation around the topic in clojurians 😉

but yeah, I think I'll probably start whittling away at some new tooling

hmm, I don't supposed you have a gist of that process do you? If you dont off hand, I can do the googling myself :D

I don’t, just going off of https://reactjs.org/docs/web-components.html

for turbolinks, I bet there is already an example, even a lib out there for interop with React

yep, you're probably right. thanks again, man!

Check out http://logrocket.com. One of a spectrum of similar products

If you're already using Honeycomb -- https://docs.honeycomb.io/getting-data-in/javascript/browser-js/

Doh! I searched for honeycomb front end but didn’t get any relevant hits.

I've just started playing with Honeycomb myself (but not yet in Clojure). Also wanted to ensure you've seen https://github.com/conormcd/clj-honeycomb. I'd love to hear about your experience with the product, especially relative to the alternatives -- I mostly have experience only with Datadog

Since getting frontend data into Honeycomb requires rolling a bunch of stuff yourself, you may also consider this https://github.com/elastic/apm-agent-rum-js (or just using pieces of it if they're helpful). I haven't found any other free/open-source JS agents (I haven't yet done any of the above, but it's the plan 🙂)

I found etaoin very nice, not the full package, but makes it easy to wirte code that integrates with the browser.

https://github.com/igrishaev/etaoin

thats really cool! I end up with inter-dependent branches more than I like to admit, and I don’t seem to have a proper strategy to build a (new) feature on two different already-existing-but-not-yet-merged feature

You can start with a merge of those two. But your getting a lot of merge commits that way. I really would like to work a lot more with rebase, with everybody in it's own fork when you need to cooperate.

I think the article makes a good case for merge commits on master, I think I agree

yeah, at work we squash-merge, that keeps the commit log on staging clean, but makes it quite difficult finding where a change originated from. E.g. “this fairly large feature branch”.

I don't agree with squash merge, because a commit history on a branch can be curated to tell a story. That's what I do.

But some people just do wip, wip, wip, and that isn't a useful history.

I think we agree, I prefer ordinary merging as long as the commit log doesnt become wip …

we were typing the same

although I feel a bit offended by GHs tendency to show force pushes nowadays :’)

I prefer leaving all branch commits as-is, then passing —first-parent to git log

That way I get the clean high level view of the project history, but I can dig into a branch if I need a fine-grained look at a particular feature.

This also allows me to merge master into a feature branch to resolve merge commits ahead of time, without risking gnarly destruction of the commit delta.

Which, of course, as I start reading the linked article I see that’s mentioned :man-facepalming::skin-tone-2:

I rebase feature branches, and use rerere to prevent reconflicts

The thing that I find most hard to deal with is having features 1.1 and 1.2 not merged (because waiting on a review), and then trying to work on 2.1 which depends on both 1.1 and 1.2

I can rebase 2.1 on top of 1.1, but then I don’t have 1.2, or vice versa

I can maintain an integration branch with both 1.1 and 1.2, and base 2.1 on top of that, but then my diffs in GH are all messed up

What about creating 2.1 from the parent of 1.1 and 1.2, then merging them both into 2.1?

So long as you don’t rebase 1.1 or 1.2, you can merge any updates to them into 2.1 just fine

right, and if 1.1 and 1.2 get merged… wouldn’t you get like unneeded merge commits from 1.1 and 1.2 on the 2.1 branch that “contaminate” your history?

I guess that depends on what you mean by “unneeded”.

Same with “contaminated”.

The only time I’ve experienced “commit contamination” was when someone took one branch and tried to turn it into multiple branches, rebasing and cherry-picking commits that were almost exactly the same but not quite.

This made it exceedingly difficult to understand which commits were “the right ones”, since they had almost-but-not-quite the same content.

I personally like merge commits, especially when they’re subject is more informative than “merging foo into bar”. Ideally, the merge commit will encapsulate why you’re merging. So at the beginning of a branch, it might be to say which work you’re basing off off. At the end of a branch, the merge commit between your topic and master/prod branch contains all of the information about what the topic branch does, and why you built that functionality.

git log —first-parent, then, will only show these high-level commits, allowing you to gloss over the implementation details until you need them

This helps with the day to day work, and also keeps potentially important information around if you ever have to dig into the nitty gritty of how/why particular pieces of code came about

</rant>

The linked article above does mention dependencies

I need to play a little with it locally

yeah — I am dragging this on, I find it very interesting tho, because now that I am actually developing full time (a year and a half out of university) I am stumbling upon this branch-dependency issue more often

thanks for the input ^^!

I'll likely be doing a deep evaluation tomorrow, so I'll try and remember to report back

yes please!

It seems that git is smart enough to handle rebased branches as long as you merge other features with the --no-ff branch. When I didn't have a merge commit, git couldn't handle that.

I'm just writing up the repro now, it's a bit involved 🙂

# gitworkflow test

Attempts at documenting what happens when X happens.

## Setup

* `mkdir github`
* `cd github`
* `git init`
* `git commit --allow-empty -m 'Root commit'`
* `cd ../`
* `git clone github dmc`
* `git clone github mal`

## Scenario 1

What happens if you "depend" on a feature branch which is later rebased.

Steps to repro:

* cd `dmc`
* `git checkout -b featureA`
* `echo foo >> file && git add file && git commit -m 'wip: update file'`
* `echo bar >> file && git add file && git commit -m 'update file'`
* `git checkout -b featureB master`
* `git merge --no-ff featureA`
* `echo 'BBBB' >> file && git add file && git commit -m 'featureB'`
* `git checkout featureA`
* `git rebase -i HEAD~2` (fixup into the wip commit)
* `git checkout master`
* `git merge --no-ff featureA`

Actions:
* `git merge --no-ff featureB` => Success!

Reading through man gitworkflow seems to suggest you should never do a rebase on a branch which has downstream dependencies. Once a branch is on next, you must fix it with incremental patches, apparently 🙂

oh cool, so as long as you always have merge commits (also if it could have been fast forwarded), rebasing on a topic branch that depends on another topic branch is not an issue

Looks like it, yeah

We are now rolling this approach out to client work :)

I found developers here don't get this - in my case I am part of the Architect team 😄

In that case you can just tell them to use those right? Maybe help them a little with a poc? We are working together to plan the next steps. But with both the other developers and the architects being rather stuck on 'proven' technology I don't have high hopes.

oh man that's so true, we have a fully fledged MVP done here (no POC anymore, already done that) and still people don't "trust" us...oh well I am venting out now 😉