1·
6 days agodeleted by creator
- 0 Posts
- 37 Comments
Joined 1 year ago
Cake day: June 11th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
libsass.so: cannot open shared object file: No such file or directory (LoadError)You’re missing the SASS library
If Markdown formatting is enough for you, I would look into using a static site generator, like Hugo or Jekyll.
If you want to keep your existing content as static files but same website skeleton and layout instead of copying and editing files you’ll copy one and create the layout template. Then content and new posts and pages can be generated from Markdown files. If you set up CI they won’t need to run Hugo or what you’re using, only push the Markdown files to your Git repository.
Whatever you want to do primarily depends on: Your formatting, styling, functionality, and interfacing needs for the editor, and what you’re willing to use or invest for setup.
Hugo runs from a single binary. The source layout is reasonable. With a single layout the folder structure doesn’t have to be complex.
I’m not very familiar with alternative [Markdown] static site generators.
You’re good to keep your skepticism. If you trust them, the ones creating the tutorial to have vetted to a degree, or that a very popular package like that is vetted to a reasonable degree, you’ll just go ahead with it. (Like most people do without questioning it.)
You’ll need considerable experience and insight to do good, reasonable risk assessment. Without that, you can either trust and hope in others, or skip the ecosystem and look for alternative technologies.
It’s also worth noting that your potential impact is considerable lower if you’re only doing local test and development work, not publishing or publicly serving anything. I’m not personally familiar if or to what degree running arbitrary local commands has been limited in the npm ecosystem by now.
I let them ripe for 10 years so I can then concentrate on older bugs.
2·2 months agoThey wrote they’re using
.as placeholder commit messages.I use
ffor such [f]ollowup/[f]ixup commits, andafor [a]dditional code/components/changesets. Both keys are trivial to enter. When cleaning it up after,fcommits are typically squashed into previous ones, andacommits get a description and/or serve as a base for squashing.I can see
.working well as well, but having a more obvious character (with vertical height/substance) seems preferable.
You don’t see the point of making use of shortcuts?
It’s just them with shortcuts, they didn’t see the point of m
😏
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.
Quite elaborate but also very interesting read on git and version control history.
I don’t get the title. Why is it “A Git story: Not so fun this time”? What is not so fun time referring to?
If working around it is an option, you could switch from https to ssh protocol.
I think the fundamental difference is that Git is a CLI tool. But that’s not how or where people use and want to use it. So obviously various interfaces are being created. It’s not alternative CLI that are created. It’s UIs and GUI interfaces. For a lack of a [more-than-barebone] official one.
Shells remain CLI. Distros are also technically/technologically driven.
Maybe the better analogy is that with vim and nano, we see many text editors and IDEs with GUIs.
There is no other CLI tool like Git. But
Shell or Bash has various alternative shells.
Vim has numerous plugins and alternatives/extensions.
Linux distributions are wide and varied, forking out.
I’m glad I was able to establish a very mindful and structured approach to Git history in my team and project.
deleted by creator
I’m not sure I understand what issue Linus et al. are trying to solve. If the full hash is used whenever a commit reference is saved somewhere, then why does it matter how core.abbrev is configured?
What are you referring to?
The article is about abbreviated forms, not full hashes. The Linus quote is specifically about abbreviation.
[Linus] He recommends kernel developers use 12 characters
For a large code base you can expect to further grow continuously for a long time, it makes sense to already use more than a minimum abbreviation so that you references remain unique, even if a decades time.
Configuring a wider and explicit abbreviation width that will remain constant is preferable because the displayed references are what you will copy and reference. It doesn’t make sense to work with shorter abbreviations locally, but wider abbreviations when communicating with others. It’d be a hassle to translate and risky to miss doing.
It’s a fundamentally visual problem
In what way do you mean git versioning is fundamentally visual?
Or do you mean understanding it or visualising it? The data and its relationships?
I’ve been using TortoiseGit since the beginning. Nothing ever came close for me.
I in the log view I have overview, filters, and all actions at hand.
Damn, that’s a long list. Looks like a lot of work to collect and prepare.
I was looking for more of an overview of it and selected them from the headlines:
DOM query