@jrf_nl I have the same technique! I make the messy commits on a branch called sandbox-something and then git merge --squash to either main or a feature branch if it's just one step of many. #git
BitMover's closed-source product, BitKeeper, was used for source control for the #Linux kernel. Larry McVoy, CEO of BitMover, was upset because someone tried to figure out how the BitKeeper worked and he pulled the BitKeeper licenses from Linux developers.
Needing distributed source control, Linus Torvalds created #git in a couple of months.
BitMover is gone and BitKeeper is now open-source, gathering dust, in a git repository.
Opinion: people who staunchly prefer working with Gerrit, and consider anything else inferior, really love working with git-review. And if git-review were not Gerrit specific they would be just as happy with, say, GitLab.
The process that the git-review/Gerrit combo automates/enforces (one commit per change, automatically generated topic branches, change IDs with cross-project uniqueness) could also work just fine by hooking up git-review with the GitLab API.
If you’re working on Kitten¹ from source, please clone a fresh copy.
I just rewrote history to reduce the repository size (correctly this time, including all references from branches, tags, etc.).
The good news is that – contrary to what the Codeberg interface is currently showing the size to be (176MB) – the repository is only about 5MB now so it should only take a couple of seconds to clone.
Trying and learning different bug tracking and project management tools for the last few weeks (bugzilla, debbugs, track, redmine, gitlab, taiga, plane, forgejo, phabricator, gitea, sourcehut and a couple more) I have to admit that the most convinient, visually pleasant and functional enough is GitHub Projects :/
Adding a “Git config options” table to Retcon, for seeing current values.
When an option isn't set, the app tries to be helpful and shows the actual resolved value.
@ph0lk3r und @jrt haben die Entstehung der #xz-Backdoor nochmals mit dem nötigen Abstand beleuchtet und ziehen einige Lehren daraus.
Insbesondere empfehlen sie die möglichst durchgängige Verwendung von signierten #git-Commits, ein Punkt der bei mir ⬆️⬆️⬆️ fehlte.
Ich setze die auch an einigen Stellen durchgängig ein, aber bisher nur an Stellen, wo keine Rebases oder Squashes nötig sind. Ich vermute, die verlieren die Signaturen, beim Rebase auch, wenn man es selbst macht? https://research.hisolutions.com/2024/04/xz-backdoor-eine-aufarbeitung/
#opensource#game introduces players to #Git allowing "them to immediately see the results of their actions through a visualization of the internal structures of Git repositories".
Sounds awesome or like hell on earth. Either way, cool.
Two days ago I switched my OpenPGP card-based #git signing setup away from gpg to an experimental new Rust alternative.
I did not realize how much of a quality of life improvement that would be. Very excited that pin entry popups are (almost entirely) a thing of the past for me, now.
How to coordinate a docs release with a product release
You also need to define Git best practices for your team about how to manage those, such as:
Whether to use release branches, or merge pull requests frequently but publishing infrequently.
Whether to use Git rebase or Git merge to maintain Git history in a given branch.
Whether and how to use feature branches and pull requests.
Whether to squash merge pull requests to main.
Even if you manage to define best practices that your team is committed to following, there isn’t a way to force your documentation contributors to adhere to all of these best practices. Due to the lack of enforcement of these best practices, you can easily end up in a situation where writers follow slightly different practices based on what their tools make easy to do."
Anybody else using #Gerrit for code reviews?
Most other #Git servers have a repo browser and render markdown. That'd be really helpful for any non-developers, because we try to keep our documentation in Git, but it's a tough ask for any non-developer to learn how to check out a Git repo, just to read the docs.
Is there anything like that out there? I did a quick search for 3rd party tools and plugins, but couldn't find anything. Readonly mirror to e.g. Forgejo would be the last resort.
I'm about to start using #Git for the first time, to make the development of my new #11ty site a bit easier. Learning both #Nunjucks and modern #CSS leads to a lot of manual rollbacks I hope will become easier.
I've read a lot about Git, but one question lingers still: I’m building my site based on #Eleventy Base Blog, in a repo I cloned using #Github Desktop.
How do I disconnect (or whatever the technical term is) from the original Github repo and turns it into a private of my own?