![](/static/790fef6/assets/icons/icon-96x96.png)
![](https://lemm.ee/api/v3/image_proxy?url=https%3A%2F%2Fprogramming.dev%2Fpictrs%2Fimage%2F028151d2-3692-416d-a8eb-9d3d4cc18b41.png)
I see you’re using your wife as a test user for yourself. Smart.
I see you’re using your wife as a test user for yourself. Smart.
How did it change how I think about version control? Not much? The goals are still the same. It only does many things better than previous centralized tools.
When DVCS came up and became popular, I used Git and Bzr.
At work, we used subversion. In one project, we had one SVN repository in our office and the customer had one in their office. A colleage had created a sync util. We regularly synced all history into an external hard drive, drove to the customer, and merged it there. Required a thorough and checklist process, potentially conflict resolution, and changelog generating for the big merge commit. Then drive back to the office, and merge back there.
Of course sometimes you used remote desktop to hotfix changes in their code base. Meaning you’d now have the change in two places as different commits.
Anyway, I’ve never found Git difficult. I used it, learned and understood it, and it’s consistent. I know enough “internals”/technical details to understand and use it well and without confusion.
Exclusive: Google-backed software developer GitLab explores sale
Wth is that headline?
GitLab is a software developer?
GitLab, which has a market value of about $8 billion, is working with investment bankers on a sale process that has attracted interest from peers, including cloud monitoring firm Datadog, opens new tab, the sources said.
I’m surprised. They’ve always had visions, and paid plans, and pushed a specific vision of their product.
Aphantasia is the inability to visualize.
Interesting.
For some things I definitely spatially lay out elements to put them into relation. I also visualize UI when thinking about it.
When I think of code hierarchies and relations, I wonder if it always ends up spatially or if sometimes I skip/omit that visualization, and if and what difference that makes. 🤔 I guess when it’s complex enough, I skip the obvious intuition and visualize to find understanding.
Can’t or don’t want to?
I got into a project starting out with translations. Then community support. Then wrote a web interface to the desktop/server application. Then got into the project itself.
Many projects have a contributing document or page with pointers. In general, being part of the community, providing information or support, improving documentation, or the bug tracker (reproduction, labeling, discussing/guiding), translating.
What can be done and what makes sense varies a lot depending on project size and popularity too.
I was tempted to disagree, but the Patreon subscription paywalls is a very good point. Are we doing less free work for the public good (or at least accessible to the public), or is it a prevalent niche that’s very visible, without influence on those that volunteer work like before?
The thought I had before that was that maybe the creative output changed. People build in Minecraft and VRChat, in hosted platforms. This may be different to before, where mods were separate things and communities.
I still see a lot of voluntary open work. But I’m not confident in assessing it’s prevalence or shift.
Depends on how “separate” the plugins are.
Single config file eases configuration of a service you consider one, and extend with plugins.
If the plugins reach a certain size, or are so distinct or separate, it may be preferable have separate configs.
Julia was my scripting and util programming language of choice for a while. But it couldn’t keep me. I’m not too confident in the reasons anymore, it’s been quite a while ago. I think the dynamic, unsafe aspect was a part of it, but also how it felt overall, or with code structuring?
Maybe I’ve been pulled away by better alternatives. (Using C# also for smaller util projects.) Recently, I’ve been using Nushell for scripting, which is new syntax to learn, but I’ve been enjoying functionality-wise.
It’s upcoming, and the time distance is increasing. They still have time.
Can you search for the search?
Gitlab will most likely use it as a big selling point once all the work has been done by externals with little to no cost to Gitlab.
I don’t think so. It’d/'ll be a nice feature, and be listed as such. But it’s not one of their primary selling points or marketing targets. Federation will be niche. Most useful in the FOSS space that pays little anyway.
I host/manage it in my workplace. Only for groups, repositories, and merge requests with reviews. It’s super bloated for such a [simple] use case. Every time I upgrade I especially see how loaded it is.
Their promotion is targeting a full-featureset devops and delivery pipeline with stats tracking and managed target environment.
Back then it was the better alternative to Phabricator, which we used before. We (I) may have chosen something different today.
I’m surprised and disappointed they didn’t mention Windows.
They publish macOS and now Linux releases. The issue tracker has many/multiple Windows tickets and a windows label. So it seems it’s not published as a release yet, but potentially usable as self-compiled, with efforts to reach stability. I assume anyway. There’s no obvious, clear indication or documentation that I can find (docs, readme tickets, project, milestone).
Slogan: “Code at the speed of thought”
How does it speed up my typing? /s
“We value your privacy”
yeah, no, very obviously you don’t
I promise I won’t go more into the tech bits meant for developers 😅
Checks if they’re still on/coming from programming.dev
You’re saying wrong solution but point to the right solution in the same standard?
- Description: Zapier uses two custom HTTP header fields named X- API-Deprecation-Date and X-API-Deprecation-Info
Is your issue with the field name only? Why do you say wrong solution then?
It makes sense to include so it’s obvious in the readable HTTP request response. We use readable URLs and header names for the same purpose: So it is inspectable and understandable from that text format. You may leave deprecation information out, but then you’re missing part of the resource description that you’re addressing with the URL/URI.
Given a defined header it also allows you to add tooling and automation. There’s no need for manual reading.
Quite elaborate but also very interesting read on git and version control history.
I strongly and broadly disagree, both with the premise and the argumentation they do.
But first off, and because it’s significant to the argumentation; Why is their entire argumentation in line-based diffs, but when I go to their homepage I see screenshots of inline diffs?
Inline-marking of differences are incredibly powerful. Programming language aware diffing should make use of understanding to support the highlighting, with the option to ignore different levels of irrelevance at the users choice.
I don’t want anything hidden. I want to default to every difference shown, but put side by side as much as possible, with different levels of highlighting of the differences according to their relevance and significance.
I want to default to every difference shown, but have alternative options to ignore things. I want to have the option to ignore whitespace changes, and potentially additional options to ignore more (this is the opportunity semantic understanding could bring, in addition to the line and change matching).
TortoiseGitMerge allows me to choose between
I default to the first, but regularly switch to the second and third, when indents change. They are irrelevant when assessing the logical changes. But whitespace is still significant in laying out code. It’s both significant, but for different reasons, and as different layers and layers of assessment.
All that being said, we don’t use an enforced automatic formatter.
But also, we use whitespace, line breaks, and other syntax consciously. Readability takes precedence over consistency. I hate hard character limits on lines. Sometimes the vertical structure is much more significant to readability than an arbitrary (and often narrow) line character limit.
One example:
Do you write
or do you write
or do you write
I dislike the second because its semantic structure not very obvious and somewhat error prone. For simple early returns like this, I prefer the first. But in cases where it’s not a simple and short return, the third can be preferable despite being only one statement.
Automated formatters often can’t do one or the other alternatively, and sometimes don’t allow ignoring one rule.