1,572 karma · joined May 31, 2011
var item *Item = item
It creates a locally scoped variable that shadows the existing one.No, gp is right. There is no snapshot of changes. Each unique version of a file is an object in the object store. That does mean each commit would only introduce new objects for files that have changed (these are already added to the object store when you use `git add`) .
But the pack files like the article explains (which are created regularly during gc/maintenance runs) is why the repo size can often be smaller then the working tree.
> Not only is each object compressed individually, they can also be compressed against each other to take advantage of common data.
With rendering, you use something that is aware of yaml, and you feed it data and it outputs valid yaml.
Example from the man page:
git for-each-repo --config=maintenance.repo maintenance run
[0]:https://gitirc.eu/git-for-each-repo.htmlThere is also '-merge', which will cause git to not attempt to merge the contents, but just ask you to pick a side.
The challenge however is then verifying the contents of these files in things like merge requests.
awful.key({ }, "Print", function () awful.spawn("flameshot gui") end,
{description = "Make a screenshot (relies on flameshot)", group = "clipboard"})But when you create a new commit, that commit object is stored as a loose object, with any new file blobs and tree objects. This represents a complete snapshot of your working tree.
But git does not need to make a complete copy of the working tree on each commit. Because objects are referred to by the hash of their contents (with a git specific header), git only needs to store each version of a file once.
my_command() {
command my_command "$@" --do-it
}Firefox recently learned --ssb (after you enable that in about:config), but it's use is much more limited, geared towards kiosks. Things like right mouse button and extensions are disabled, and you cannot open external links.
if(var == true) {
}
It's more verbose than necessary, but not wrong.The "width=device-width" is the cause.
The reason you use blame is to find the exact commit that changed a specific line, and hope to find the rational / decisions that lead up to this change, assuming people are disciplined enough to document that in their commit messages. If not, maybe you could even ask Josh if they still remember why they changed things a certain way.
Many developers commit append-only until their feature works, which means there are a lot of noise commits in between, which they don't (know how to) clean up. Rather than having all this noise, projects opt to squash the commits instead.
Someone proposed splitting this up the other day, but even that would come at the cost of performance and an increase of complexity.