@grumpygamer haven't tried it myself yet, but I've heard a lot of good things about #Jujutsu - an SCM which imposes a much more accessible workflow onto #git which is used under the hood and thereby stays 100% backwards-compatible.
Ugg, I found a situation where I can't use jj.
This stinks because the situation i'm in is exactly where jj is needed (where I need to commit some work while someone else hasn't pushed their work up.
Nous sommes ravis de partager le replay de notre meetup avec notre invitée Maëlle Salmon @maelle qui a présenté le package {#saperlipopette} et a partagé son expertise sur #Git.
Replay : youtu.be/u6XqHOO8g6c
#RStatsFr #RStats #RLadies #Paris @chaimaboughanmi @mouna_belaid
Ich habe jetzt mein eigenes "GitHub" mit Forgejo auf der #Synology. Funktioniert bisher ganz gut!
Help me understand why #jujutsu #jj is worth using.
I am pretty happy using #git as is. My workflows are generally pretty simple, branch, commit, PR, squash, and merge.
My biggest pain points are when, rarely, a coworker will branch my branch and then I will have to handle the merge after I've rebased -i my branch.
I don't have any issues with git concepts or mental model. I rebase -i a lot, but rarely use the reflog. Only once did I lose any real work.
For some reason, this morning is the day I've (finally) decided to take some time to actually learn #git in a more systematic way than my current approach of googling as I go along and inevitably forgetting how I solved the last problem...
I enjoyed reading and answering the quiz questions of the W3 schools tutorial (https://www.w3schools.com/git/) and I'm grateful to the #Stackoverflow peeps who have asked the same silly questions that I've been asking myself and to the kind people who patiently answered them. Now I know that "origin" doesn't have a particular meaning, it's just an alias for a URL and that there is a system to the use of one or two dashes in git commands (okay, I could have admittedly worked that one out by myself but trial-and-error served me just fine for the past few years... ).
Ich hatte mal wieder Langeweile
Einerseits um ein wenig Python zu üben und andererseits weil ich immer wieder zu faul bin, mir die git repos zusammenzuklicken
https://codeberg.org/Tealk/git-ignore-helper
https://codeberg.org/Tealk/git-project-helper
Show HN: memEx, a personal knowledge base inspired by zettlekasten and org-mode
https://gitea.bubbletea.dev/shibao/memex
#ycombinator #git #self_hosted #gitea
TL;DR is there a way to use git to provide out-of-band *per-line* commentary on content changes? Perhaps using git-notes?
Imagine you have a plaintext document that needs review.
Broadly, a review could be "change line 42 from X to Y", which can be captured by "a git commit"; but could also include "if we change L42 from X to Y then what about effect Z?" - in other words: commentary.
Is there a #git-y way to store, transmit, & then display such per-line comments, *external* to the source doc?
git-buildpackage 0.9.38 is out. It's mostly bugfixes and QoL improvements in preparation for #Debian #Trixie. Details at https://salsa.debian.org/agx/git-buildpackage/-/blob/master/debian/changelog?ref_type=heads#L1
Thanks to everyone who contributed to this release!
Poll #git: are you using a mergetool?
I personally just use the builtin `conflictstyle = zdiff3`, and emacs recognize it well by default, but I'm curious.
If using a mergetool please tell which one, for how long, and how helpfull it feels :)
(Boost for reach maybe?)
@programming_discussions Fun fact: #git is tracked using #git.
I enjoyed this interview with Linus Torvalds about 20 years of #git
Implementing SQL JOIN Support in ChronDB via PostgreSQL Protocol
The game of creating databases using #git internals continues
this week was the time to implement inner/left/right join in the #postgresql protocol
I tried to explain a little about the architecture implemented to perform joins
https://www.moclojer.com/blog/implementing-sql-join-support-in-chrondb-via-postgresql-protocol/