Szukam poradnika dla początkujących, którzy chcieliby włączyć się w rozwój otwartego oprogramowania.
Przydałoby się, żeby obejmował zarówno stronę techniczną (obsługa gita, klonowanie repo, wysyłanie zmian itd.) jak i etykietę: co wypada, a na co trzeba uważać, żeby nie podpaść devom.
"In 2020, the community discovered that GitHub has a for-profit software services contract with the USA Immigration and Customs Enforcement (ICE). Activists, including some GitHub employees, have been calling on GitHub for two years to cancel that contract. GitHub's primary reply has been that their parent company, Microsoft, has sold Microsoft Word for years to ICE without any public complaints"
➥ @conservancy
「 While GitHub pretends to be pro-FOSS (like SourceForge before them), their entire hosting site is, itself, proprietary and/or trade-secret software. We appreciate that GitHub allows some of its employees to sometimes contribute FOSS to upstream projects, but our community has been burned so many times before by companies that claim to support FOSS, while actively convincing the community to rely on their proprietary software 」
— @conservancy #Github#Git#Opensource
「 GitHub does not even offer any self-hosting FOSS option. Their entire codebase is secret. For example, while we have our complaints about GitLab's business model of parallel “Community” and “Enterprise” editions, at least GitLab's Community Edition provides basic functionality for self-hosting and is 100% FOSS. Meanwhile, there are non-profit FOSS hosting sites such as CodeBerg, who develop their platform publicly as FOSS 」
— @conservancy #Github#Git#Opensource
「 Copilot is a for-profit product — developed and marketed by Microsoft and their GitHub subsidiary — that uses Artificial Intelligence (AI) techniques to automatically generate code interactively for developers. The AI model was trained (according to GitHub's own statements) exclusively with projects that were hosted on GitHub, including many licensed under copyleft licenses. Most of those projects are not in the “public domain”, they are licensed under FOSS licenses 」 #Github#Git#Opensource
「 Their only defense of these actions was a tweet by their former CEO, in which he falsely claims that unsettled law on this topic is actually settled. In addition to the legal issues, the ethical implications of GitHub's choice to use copylefted code in the service of creating proprietary software are grave 」
— @conservancy #Github#Git#opensource#CoPilot
「 Collective action requires the privileged developers among us to lead by example; that's why we're not merely asking you leave GitHub, but we're spearheading an effort to help everyone give up GitHub over the long term. You can help protect newcomers from the intrinsic power imbalance created by GitHub by setting the agenda for your FOSS project and hosting your project elsewhere 」
— @conservancy #Github#Git#Opensource
fun fact: #git used #curl before curl used git but both git's use of curl and curl's use of git have improved curl ... and I like to think that git's use of curl helps to make it a solid product.
I'm almost out of #emacs packages that are plug-and-play. So today I'm rehashing an old twitter thread about #Magit, THE porcelain for #git.
First, let me talk about my impression of git pre and post magit:
Pre-Magit, I wasn't happy/good at using git.
Post-Magit, I believe all git commands are clunky & unwieldy (especially in comparison to Magit).
The closest that my friends have come to making git better is with copious autocomplete setups (I think it was tmux, fzf, and a few other things). But I still say that magit is probably the lower bound on how nice it can be.
Eg: stage+commit in a wip branch, switch to main, pull from remote, merge wip to main, push to remote is:
S, c c, b b ⏎, F p, b b ⏎, m m ⏎, P p.
Done, in just 16 key strokes. At most there will be a couple of keystrokes extra before each enter if there are multiple branches to select from (but that would be true of any tool).
Not only do the keystrokes feel like the lower bound, the default choices are extremely sane.
Finally, it is not just the minimal keystrokes, it is also the extent of information that magit exposes and the amount of control it provides. Until I started using magit, I didn't know that beyond the usual amend to an earlier commit, you could also expand it (add changes, same msg) and reword it (change msg, no changes). Further, magit also exposes fixup and squash right in the commit submenu (see screenshot). In git, I would have no way of knowing what to do.
Magit is the git porcelain that makes using git feel like doing magic.
My understanding of #Mercurial is that it is very comparable with #Git feature-wise. I only use Git because I discovered it first. It just so happens that it seems to have become the de-facto standard version control system these days.
For those who use Mercurial instead: why? Does it offer something that Git does not, or is it simply personal preference/familiarity?
Was ist denn der beste Git-Hoster der nicht Github heisst? Ich würde gerne mal testweise über den Tellerrand gucken.
Gitlab selber hosten ist raus, hab ich gerade wieder gemacht und für unlustig befunden.
Vertragspartner (und Server) sollten in Europa sein
CI/CD wäre fein, aber kein KO-Kriterium.
Stabile, langweilige, mittelständische Betreiberfirma wäre großartig.
Is it unusual for a #GitHub repository owner to accept PRs, but only by copy-paste-and-rewriting them so that the #git history doesn't show any contribution credit from anyone else? they've made modifications to be sure, but clearly by referencing my code.
I feel like I've been plagiarized, but is there some good reason this is done and I should calm down?
It's just nice have your work acknowledged in the git record, right?
I’ve gone from using the git command-line exclusively to almost exclusively using Sublime Merge.
I basically just keep it open on its own monitor as a real-time dashboard of all my changes. That, and the ease with which you can stage hunks and lines, has improved the quality of my commits and also gives me greater peace of mind.
(Downside: it’s a commercial app and Linux support exists but isn’t first class. e.g., doesn’t automatically respond to light/dark mode changes.)
Concerning my toot from a few days ago concerning more "well-bounded" #dvcs patch workflows, I just discovered #pijul, which seeks to make applying changes commutative (ie the order doesn't matter) based on "theory of patches", "merge correctness", "partial clones" and "first-class conflicts":
"In Pijul, independent changes can be applied in any order without changing the result or the version's identifier. This makes Pijul significantly simpler than workflows using git rebase or hg transplant. Pijul has a branch-like feature called "channels", but these are not as important as in other systems. For example, so-called feature branches are often just changes in Pijul. Keeping your history clean is the default."