1 – 10 of 358805

  1. Git Object Model | Online Video Tutorial by thoughtbot

    Git’s command interface is generally considered somewhat confusing and

    inconsistent. Luckily, beneath the command interface is a wonderfully

    consistent and straightforward object model. By gaining an understanding of

    the object model, we can easily wrap our heads around even the most complex

    Git operation by thinking in terms of these objects.

    In this video, we’ll lay the foundation of the Git object model, describing

    exactly how Git stores and references our code.

    To help illustrate the points of our discussion, we’ll create

    a file with the classic hello world as the contents.

    $ echo ‘hello world’ >

    Git Repository

    To begin the discussion on the Git object model, we’ll need a Git repository.

    The "repository" is the hidden directory .git/ which contains all of the

    objects Git uses to track our revisions, such as branches, remotes, etc.

    Starting from an empty directory, we’ll run:

    $ git init

    and Git kindly creates the repository for us.

    Here are the contents of the .git/ directory immediately after running git


    $ tree .git


    ├── HEAD

    ├── config

    ├── description

    ├── hooks/

    ├── applypatch-msg.sample


    └── # … (other hooks)

    ├── info/

    └── exclude

    ├── objects/

    ├── info/

    └── pack/

    └── refs/

    ├── heads/

    └── tags/

    The .git directory contains a handful of files and subdirectories (ending with

    a /), even if nothing has been tracked yet. In this discussion, we’ll be

    focusing on the following paths:




    A "pointer" to the currently checked out object (more on this later).


    Where Git stores its representation of all files, directories, and commits.


    Where Git stores all branches, tags, remotes, etc.

    config, description, hooks/, and info/ contain metadata, and we can

    ignore them during this discussion.

    Adding Our First Object

    First, we’ll be focusing on the objects/ directory. It’s best to think about this

    directory as a mini file-based database where Git will store its

    representation of our files, directories, and commits.

    If we take a peek at the objects/ directory, we’ll see that it remains

    empty. Git does not run on its own in the background.

    If we run git status, we see that Git is aware there is a new file, but

    has not started tracking it. Thus, the file is not in the .git/objects

    directory yet.

    $ git add

    Now we’ll take another look, and see that we have our first Git object!

    $ tree -I "info|pack" .git/objects


    └── 3b

    └── 18e512dba79e4c8300dd08aeb37f8e728b8dad

    (The -I bit means ignore the provided pattern. Those files aren’t relevant

    to our discussion.)

    Here we can see a new directory and file. Every object in Git has a unique 40-character hex string as its name, and Git uses this name to store the file

    (this technique is called content-addressable storage). Git takes the

    first 2 characters of the object’s name and uses them as the directory,

    with the remaining 38 as the file name. We’ll ignore this subtlety going

    forward, as it is a performance optimization, but it is good to know for later on.


    This first object we’ve added to our Git repository is a "blob." Git uses

    blobs to track files, but you should note that a blob stores only the contents

    of our file, not the name. We can see this by asking Git to show us the contents

    of the first object it has stored using the cat-file command and the

    object’s name (note that we only need to provide the first eight or so characters

    from the name, not the whole name):

    $ git cat-file -p 3b18e512

    hello world

    Again, we see here that Git is only storing the contents of the file, namely

    hello world. Other information like the mode, permissions, and file name is

    stored elsewhere.

    Because Git only stores the contents of the file rather than the name or any metadata, it can tell when you are giving a different name to the same version of a file and therefore process it quickly. If we have two files with identical content but different names, the content has only been stored once!

    Hashing Overview

    When storing our file, Git uses a "blob" which only concerns itself with the

    contents of the file, ignoring our filename (for now). However, it does need

    a name, and we’ve seen that Git uses a seemingly random 40-character hex

    string as the name.

    It turns out this string is in fact not random at all, but is produced

    by taking the content that Git stores and running it through a "hash

    function," the SHA-1 hash function in this case. The hash

    function takes a string of any size as an input, and returns a 40-character

    hex string as the output.

    SHA-1 has a number of useful properties, but the most important to Git are:

    Determinism - The same input will always result in the same output.

    Defined range - All outputs are 40 char hex.

    Uniformity - Outputs are evenly distributed over the possible space,

    and a small change in input yields a huge change in output.

    The use of these hash values as the names for our objects makes operations

    like deep comparison of files and directories easy, as we’re only comparing the

    hash values. Going forward, we’ll refer to these names as a "hash."

    Object Storage Subtleties

    We’re close to fully understanding how Git stores our file, but if we try to

    replicate the hash function on the content "hello world," it doesn’t match

    with the 3b18e512… hash.

    $ echo ‘hello world’ | shasum



    This is because Git prepends a bit of metadata before the

    object contents, specifically the object type, length, and a separator

    character, and then passes the combined string through the hash function,

    available as shasum:

    $ echo -e ‘blob 12hello world’ | shasum



    Now we have a complete understanding of how Git names and stores our blob

    objects. Git uses a similar metadata structure for the other object types, but

    from here on we’ll only discuss the primary content of the Git objects,

    ignoring the metadata.

    This metadata has the benefit of allowing us (and Git!) to know the type of

    an object in isolation. Let’s check the object’s type with the -t, for

    "type", flag passed to cat-file:

    $ git cat-file -t 3b18e512



    It wouldn’t be very useful if we could only track the contents of files, and

    not even the file names or the structure. This is where "tree" objects come

    in. A "tree" in Git is an object (a file, really) which contains a list of

    pointers to blobs or other trees. Each line in the tree object’s file contains

    a pointer (the object’s hash) to one such object (tree or blob), while also

    providing the mode, object type, and a name for the file or directory.

    $ git add

    $ git commit -m ‘Add readme’

    $ tree -I "info|pack" .git/objects


    ├── 3b

    └── 18e512dba79e4c8300dd08aeb37f8e728b8dad

    ├── 73

    └── 94b8cc9ca916312a79ce8078c34b49b1617718

    └── ef

    └── 34a153025fffb8a498fff540f7c93963937291

    In committing our file, we create two new objects. One is the

    object for the commit itself, but the other, ef34a15…, is the new "tree"

    object that represents our current directory. (Remember that the full hash for

    an object is its directory name prepended to the file name, ef and 34a15…

    in this case). We can view it with:

    $ git cat-file -t ef34a15


    $ git cat-file -p ef34a15

    100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

    Our new tree object consists of a single line, listing the mode/permissions,

    the type, the hash, and the file name of our file.

    Again, we’ll note that tree objects themselves do not have names, much like

    blobs. Parent trees associate names for subtrees, and the root tree, referred

    to as the "working tree" of a repository, in fact has no name.

    This has two fun characteristics:

    The repo doesn’t care what you call it. You can rename your local

    directory that contains your repository to anything you’d like. Git is

    blissfully unaware of the name of the directory that contains the .git repo


    We can rename subtrees as much as we want, and only parent objects

    need to update. The subtree object itself and everything below remain



    Trees require at least one file, and optionally have subtrees. An empty

    directory would yield an empty tree, and this is why we can’t track empty

    directories in Git and have to use tricks like adding a hidden .gitkeep file

    into the directory. (Technically, there’s no strict reason for this limitation,

    it’s just that no one has fixed it… ¯(ツ)/¯)

    We’ll create a subtree with:

    $ mkdir app

    $ touch app/script.rb

    $ git add —all

    $ git status

    ## master



    $ git commit -m ‘Another file in app Dir’

    Looking in the objects/ directory, there are now multiple new objects.

    Of most interest to us is the new tree object for our working directory, our

    current root tree. Since there are so many objects now, we can’t just guess

    which is which, but we can ask Git directly to show us a specific tree using

    the ls-tree command.

    $ git ls-tree master

    040000 tree 67b21f78a4548b2ba3eab318bb3628d039e851e6


    100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

    We passed master as the "tree" to view since master, a branch, points at a

    commit, which points at a tree. By passing master as the argument, we’re

    identifying the tree master indirectly points at.

    We have a new tree object and it contains a new line, the first line,

    identifying a subtree for our app subdirectory. We can view the

    tree by grabbing its hash and running:

    $ git ls-tree 67b21f78a4548b2ba3eab318bb3628d039e851e6

    100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391


    And here we see a single line for the script.rb file in the app

    directory. This rounds out our understanding of trees. To review:

    Trees list out the contents of a directory (blobs and subtrees).

    For each object, the mode, permissions, type, hash, and name is listed.

    Tree objects must contain at least one blob or tree.

    Trees can be nested to any depth.

    Trees, like blobs, don’t store names. The names are stored in parent trees.

    Trees are named and stored in the objects/ directory by hashing their

    contents (the list of objects described above).


    A commit is the final piece in our object puzzle, and it connects all

    of the other objects together, acting as the hub of our object graph. Just like with

    our other objects, we can use cat-file -p to get a pretty printed view of

    how Git stores commit objects.

    $ git log —oneline —decorate

    • f95b2fe (HEAD -> master) Another file in app dir

    • ef34a15 Add readme

    $ git cat-file -p f95b2fe

    tree 0cae7dc167b255c0123c7c396fc48ce40fc35cfa

    parent ef34a153025fffb8a498fff540f7c93963937291

    author Chris Toomey

    1441311544 -0400

    committer Chris Toomey

    1441311544 -0400

    Another file in app dir

    A commit is a file, just like our blob and tree objects, with a specific

    structure. That structure includes:

    The hash of the working tree - This is always a single tree, never more, never

    less. The tree can point to any number of subtrees, but for every version

    of our code there is one root working tree.

    The hash of the parent commit(s) - Git tracks the history by simply pointing at the previous commit. In the case of a merge,

    there can be multiple parent commits, or, in the case of the root commit, no


    The author info and date.

    The commiter info and date.

    The full commit message.

    This file is then passed through the SHA-1 hash function and saved alongside

    our other objects in the .git/objects directory.

    It’s worth noting that the commit object only contains a single reference to a

    working directory; Git doesn’t store diffs. When diffing between two

    commits, it compares the working trees of the commits, computing the diff on


    Walking the Git Object Graph

    Commits are the core of the Git object graph, and we’ll explore this by

    walking this graph just a bit:

    # using the "parent" commit hash from above

    $ git cat-file -p ef34a153025fffb8a498fff540f7c93963937291

    tree 7394b8cc9ca916312a79ce8078c34b49b1617718

    author Chris Toomey

    1441311368 -0400

    committer Chris Toomey

    1441311368 -0400

    Add readme

    Here we’ve walked the graph and viewed the parent commit, which we see is the

    root commit (as it has no parent), and now we go a step further to view the

    working tree of this parent commit:

    $ git cat-file -p 7394b8cc9ca916312a79ce8078c34b49b1617718

    100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

    Here we see the initial directory with the single script.rb file, and


    $ git cat-file -p 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

    hello world


    And with that, we’ve covered the primary objects Git uses to store our code:

    Blobs - Contain the contents of a file.

    Trees - List the contents of a directory, connecting "blobs" with names

    and permissions to reference files and


    Commits - Store a reference to a specific version of the code (a single

    tree), the direct parentage (parent commit hash(es)), and other metadata.

    We’ve also seen how we can walk through the history by following the hash

    references from commits, trees, and eventually to blobs. This wraps up the

    foundation of the object model, but in the next video we’ll see how

    branches, remotes, and tags fit in, as well as how Git commands operate on

    these objects.


    Tagged with git

    —Huffduffed by jakehschwartz

  2. Crafting History With Rebase | Online Video Tutorial by thoughtbot

    One of the most powerful features of Git is how it separates the acts of

    coding and version control. There’s no central server to sync with, no

    locking files so you teammates can’t edit them while you do, in fact there is

    almost nothing required before you start coding.

    Instead, you can simply go to work, coding and figuring things out as comes

    natural. Whenever you’re ready you can then focus on version control and

    commit your changes.

    While this kind of freedom is invaluable, it doesn’t always lead to the most

    straightforward history. Luckily for us, Git provides many ways to craft our

    history, arranging it to tell the story of building a feature as we’d want,

    rather than being stuck with the wandering sequence of changes we initially


    In this video we’ll cover these techniques, including selective staging,

    cherry picking, and all forms of rebase.

    Add Patch

    Often when we’re ready to commit our changes, we’ll run git add . or git

    add —all, but these are a bit coarse. We can use the more focused form

    where we name files or directories to stage, for instance git add Gemfile,

    but even this can be too coarse if we have distinct change sets within a

    single file.

    Instead, we can use the —patch flag to tell Git that we would like to

    review each group of changed lines individually, and choose whether or not to

    stage them. The full command is run as:

    $ git add —patch

    When running git add —patch, Git will split the changes in each file into

    "hunks" and present them one at a time, prompting you for how to proceed. The

    primary operations are to stage the hunk, skip it, or split it into smaller

    hunks if possible. Below is a collection of some of the more common

    operations (this list can also be seen by typing h at the prompt):




    Display the list of available keys and their operation


    Stage the current hunk


    Skip this hunk


    Split the hunk


    Stage this and all remaining hunks


    Quit, skipping all remaining hunks


    Edit the hunk manually, allowing for line be line staging

    Cherry Pick

    In some cases we’ll find that we’ve made a commit on the wrong branch. We might

    have checked out master and made changes there, rather than our feature

    branch. Luckily Git provides a command, cherry-pick, that allows us to copy

    commits onto a different branch.

    Assume we have two commits made to our master branch and we want to move

    them onto our sanitize-search-query feature branch. We can do this by first

    identifying the commits we want to bring across. We could specify them by

    their commit hashes, but an easier option is to reference them as the range

    from origin/master up to master. We can confirm that we’ve specified the

    range properly by running either git diff or git log with the range:

    $ git diff origin/master..master

    # confirm that the diff contains all the expected changes


    $ git log origin/master..master

    # confirm that only the expected commits are listed

    From there, we can check out our feature branch and run the cherry-pick

    command, passing the range as our argument:

    $ git checkout sanitize-search-query

    $ git cherry-pick origin/master..master

    # git will create a new commit for each in the range and output a summary of

    # the new commits

    Reset Hard

    Note, with the above cherry-pick operation, as with all Git operations, Git

    does not destroy or edit commits, but instead simply creates new ones. This

    means that the two commits as authored are still on our master branch.

    We can solve this by reseting our master branch to align it with

    origin/master, essentially erasing the original commits (although Git still

    remembers just in case; Git’s got our back).

    $ git checkout master

    $ git reset —hard origin/master


    Now that we’ve seen cherry-pick, we can tackle the oft-dreaded rebase. It

    turns out that a standard rebase is essentially identical to the cherry-pick

    workflow that we’ve just shown.

    When we rebase, we do it from the context of our feature branch, and we

    specify the target branch we want to to rebase onto. So the command name

    "rebase" actually does a great job of explaining what the command does; it "re

    bases" or bases again. We want to take the work we’ve done on our feature

    branch, and reapply it as if it was done on top of the additional commits in

    our target branch.

    As an example, let’s assume we have a branch that when started was based off of

    master. We’ve made some changes on our branch and now have two new commits,

    but at the same time our colleagues have also made changes on the master


    $ git branch

    • faq-updates


    $ git rebase master

    When performing the rebase, Git finds the commits unique to our branch and

    computes the diff off the changes they introduced, then moves to the target

    branch, master in this case, and one by one applies the diffs, creating new

    commits reusing the commit messages from our branch. Once done, it updates

    our branch to point at the newest of these commits created by reapplying the


    Interactive Rebase

    And now we’re ready to move on to our final form of history crafting which is

    the surprisingly-powerful interactive rebase command. Unfortunately it shares

    a name and command with the standard rebase we just reviewed, but for

    practical purposes it’s actually quite different.

    With interactive rebase we’re not moving our commits to a different point in

    history, but instead revising the given range of commits in place. The most

    common usage is to combine or squash commits together, but you can even go so

    far as to entirely delete or reorder commits.

    Some folks will say that revising history is an unforgivable sin, but we here

    at thoughtbot consider it an important part of our workflow. While we would

    never revise published history, specifically the master branch, we almost

    always revise our commits on feature branches before merging them in. We value

    a clean history, and the majority of the time, the commits in a feature branch

    contain many rounds of refactoring and PR reviews which we don’t want in the

    permanent history. Instead, we want the most direct and concise form of the

    history that fully captures the change we settled on in our feature branch

    after completing any refactoring or updates.

    To demonstrate, we’ll again come back the faq-updates and can see that the

    history currently is as follows:

    $ git log —oneline —decorate -5

    • 009ac91 (HEAD -> faq-updates) Add other file

    • c0a3941 Remove line in README

    • be891be WIP add forum answer to FAQ

    • a915fac (origin/master, origin/HEAD, master) Add a search page using…

    • 85ff650 Update skylight gem

    From this view, we can see that we have 3 commits on on our faq-updates

    branch, and they are directly ahead of master. Using interactive rebase, we

    can squash these down into a single commit:

    $ git rebase -i master

    Git will then open our editor with a file for us to edit, similar to how

    commit messages are composed, and in this file the commits we can operate on

    are presented, one per line, in reverse chronological order. We can then

    choose from an array of operations, but the most common is simple to "squash"

    the commits below the first commit.

    pick be891be WIP add forum answer to FAQ

    s c0a3941 Remove line in README

    s 009ac91 Add other file

    Squashing has the effect of keeping the working tree for a commit, but folding

    the commit object itself back into the previous so we are left with only a

    single commit for which the working directory is taken from the last of the

    "squash" commits.


    Tagged with git

    —Huffduffed by jakehschwartz

  3. Wer ist der Beste Center der Welt? | SHOTS FIRED vs C-Bas

    C-Bas Video: James Harden besser als Dwyane Wade?

    Kobe Bjoern & C-Bas debattieren jeden Donnerstag spannende Themen zur aktuellen NBA und NBA history. Heute stellen wir die Frage wer der Beste Center der NBA ist. Nikola Jokic oder Joel Embiid. Welcher NBA Center ist besser.

    Mehr von C-Bas:

    Mehr von Kobe Bjoern:

    Original video:
    Downloaded by on Sat Mar 6 14:23:38 2021 Available for 30 days after download


    Tagged with sports

    —Huffduffed by netdom

  4. BBC Radio 4 - In Our Time, Food

    Melvyn Bragg explores the history of food in Modern Europe. The French philosopher of food Brillat-Savarin wrote in his Physiology of Taste, ‘The pleasures of the table belong to all times and all ages, to every country and to every day; they go hand in hand with all our other pleasures; outlast them, and remain to console us for their loss’ . The story of food is cultural as well as culinary, and what we eat and how we eat has always been linked to who we are or whom we might become, from the great humanist thinker Erasmus warning us to ‘Always use a fork!’ to the materialist philosopher Feuerbach telling us baldly, ‘You are what you eat’.But what have we eaten, and why? In Europe since the Renaissance how have our intellectual appetites fed our empty stomachs? With Rebecca Spang, Lecturer in Modern History at University College London; Ivan Day, food historian; Felipe Fernandez-Armesto, Professor of Modern History at Oxford University.

    —Huffduffed by adactio

  5. BBC Radio 4 - In Our Time, Language and the Mind

    Melvyn Bragg and guests discuss the history of our ideas about the formation of language. The psychologist George Miller worked out that in English there are potentially a hundred million trillion sentences of twenty words in length - that’s a hundred times the number of seconds since the birth of the universe. “Language”, as Chomsky put it, “makes infinite use of finite media”. “Language”, as Steven Pinker puts it, “comes so naturally to us that it’s easy to forget what a strange and miraculous gift it is”. “All over the world”, he writes, “members of our species spend a good part of their lives fashioning their breath into hisses and hums and squeaks and pops and are listening to others do the same”. Jean Jacques Rousseau once said that we differ from the animal kingdom in two main ways - the use of language and the prohibition of incest. Language and our ability to learn it has been held up traditionally as our species’ most remarkable achievement, marking us apart from the animals. But in the 20th century, our ideas about how language is formed are being radically challenged and altered. With Dr Jonathan Miller, medical doctor, performer, broadcaster, author and film and opera director; Steven Pinker, cognitive scientist, Professor of Psychology and Director of the Centre for Neuroscience, Massachusetts Institute of Technology, California.

    —Huffduffed by adactio

  6. BBC Radio 4 - In Our Time, Yeats and Irish Politics

    Melvyn Bragg and guests discuss the poet W.B. Yeats and Irish politics. Yeats lived through a period of great change in Ireland from the collapse of the home rule bill through to the Easter Rising of 1916 and the partitioning of the country. In May 1916, 15 men were shot by the British government. They were the leaders of the Easter Rising – a doomed attempt to overthrow British rule in Ireland - and they were commemorated by W.B. Yeats in a poem called Easter 1916. It ends with the following lines: MacDonagh and MacBrideAnd Connolly and PearseNow and in time to be,Wherever green is worn,Are changed, changed utterly:A terrible beauty is born.Yeats lived through decades of turbulence in Ireland. He saw the suspension of home rule, civil war and the division of the country, but how did the politics of the age imprint themselves on his poetry, what was the nature of Yeats’ own nationalism, and what did he mean by that most famous of phrases ‘a terrible beauty is born’?With Roy Foster, Carroll Professor of Irish History at Oxford University and Fellow of Hertford College, Oxford; Fran Brearton, Reader in English at Queen’s University, Belfast and Assistant Director of the Seamus Heaney Centre for Poetry; Warwick Gould, Director of the Institute of English Studies in the School of Advanced Study, University of London

    —Huffduffed by adactio

  7. BBC Radio 4 - In Our Time, Mathematics and Music

    Melvyn Bragg and guests discuss the mathematical structures that lie within the heart of music. The seventeenth century philosopher Gottfried Leibniz wrote: ‘Music is the pleasure the human mind experiences from counting without being aware that it is counting’. Mathematical structures have always provided the bare bones around which musicians compose music and have been vital to the very practical considerations of performance such as fingering and tempo. But there is a more complex area in the relationship between maths and music which is to do with the physics of sound: how pitch is determined by force or weight; how the complex arrangement of notes in relation to each other produces a scale; and how frequency determines the harmonics of sound. How were mathematical formulations used to create early music? Why do we in the West hear twelve notes in the octave when the Chinese hear fifty-three? What is the mathematical sequence that produces the so-called ‘golden section’? And why was there a resurgence of the use of mathematics in composition in the twentieth century? With Marcus du Sautoy, Professor of Mathematics at the University of Oxford; Robin Wilson, Professor of Pure Mathematics at the Open University; Ruth Tatlow, Lecturer in Music Theory at the University of Stockholm.

    —Huffduffed by adactio

  8. 13: Maik Weichert & Matthias Voigt (HEAVEN SHALL BURN) - Und dann kam Punk

    Im Gespräch mit Maik & Matthias. Wir reden u.a. über Punk in der DDR, SchleimKeim, die Förderung von Underground durch die DDR-Führung, keine Punks in Thüringen, erste Konzerte nach der Wende, Dorfdisko mit Wave & Poppern, Rock Hard Festival in Jena mit Napalm Death & Co, Jugend im Plattenbau, die Ost-Thrash-Band Macbeth, die Ausnahme-Band Schleimkeim, auf der Suche nach Bands mit politischem Anspruch zum Punk, die Erleuchtung durch Earth Crisis, Schutt & Asche aus Arnstedt, das erste Schlagzeug für 50 Mark, die Bands Zerstörtes Ich & Amoklauf, die erste Band Before the Fall, 500 Leute beim ersten Konzert, Consense, die Gründung von Heaven Shall Burn, der Einfluss der H8000-Szene aus Belgien, Growing Movement, durch die Hardcore-Szene in die Welt, die elitäre Hardcore-Szene vs. die Metal-Szene aus der Arbeiterschicht, die rohe Energie von Hardcore, das 95er Dynamo, die megacoolen Power Trip, Elmar von Deeds of Revolution Records, Lifeforce Records, die Hardcore-Szene starb als professionell Rechnungen bezahlt wurden, es stand nie zur Debatte die thüringische Provinz zu verlassen, keine Sehnsucht nach Ausbrechen, das erste Mal auf dem Vort´n´Vis Festival, die erste Show in Santiago de Chile, Studium & Band unter einen Hut zu bekommen, die Rechnung immer allein zahlen, viele Prominente versuchen kein Arschloch zu sein, die lange Pause von Matthias, der Umgang damit nicht mehr Schlagzeugspielen zu können, der Druck auf großen Festivals zu spielen, immer machen was Du kannst, dass das Publikum beim Wacken aussieht wie ein Meer von Baked Beans, der putzige Thüringer Dialekt, live kommt sowieso Einiges vom Band, alte Fans zufriedenstellen und gleichzeitig experimentieren können, kreative Feigheit, Matzes Einstieg bei ClearXCut, Heimat wird zum Problem, wenn Leute nicht wissen wo sie hinwollen, wie es ist in einem Ort mit 35% AfD-Wählerschaft zu leben, die gelebte Schizophrenie auf dem Thüringer Land, vier Stunden Schnee-Schippen, Masterstudiengang Sammlungs-bezogene Kulturgeschichte, den inneren Wertecodex zu behalten, Schleimkeim, Rammstein, Renft, Karat, Biest, uvm.

    —Huffduffed by chrib

Page 1 of 35881