mitchellh

I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.

I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:

mitchellh

/// Returns a ComptimeStringMap for all of the capabilities in this terminfo.
/// The value is the value that should be sent as a response to XTGETTCAP.
/// Important: the value is the FULL response included the escape sequences.
pub fn xtgettcapMap(comptime self: Source) type {
    const KV = struct { []const u8, []const u8 };

    // We have all of our capabilities plus To, TN, and RGB which aren't
    // in the capabilities list but are query-able.
    const len = self.capabilities.len + 3;
    var kvs: [len]KV = .{.{ "", "" }} ** len;

mitchellh

/// This is demonstrating a strange behavior that I can't explain.
///
/// This is a minimal SwiftUI application that renders a NSView that only implements NSTextInputClient, allowing
/// it to behave like a text input field. The implementation is minimal. Any characters you type will be logged
/// to the console wit the codepoints that are inserted. If you type "a" you should see "97" in the logs, for example.
///
/// 1. Launch the program with the US traditional ("US") keyboard layout.
/// 2. Type characters and notice they are logged.
/// 3. Type a control character such as enter, backspace, notice they are _not_ logged (this is fine).
/// 4. Switch to US international ("us-intl") keyboard layout.

mitchellh

//! Renderer implementation for Metal.
//!
//! Open questions:
//!
pub const Metal = @This();

const std = @import("std");
const builtin = @import("builtin");
const glfw = @import("glfw");
const objc = @import("objc");

mitchellh

//! A zig builder step that runs "libtool" against a list of libraries
//! in order to create a single combined static library.
const LibtoolStep = @This();

const std = @import("std");
const Step = std.build.Step;
const RunStep = std.build.RunStep;
const FileSource = std.build.FileSource;

pub const Options = struct {

mitchellh

const std = @import("std");
const builtin = @import("builtin");
const assert = std.debug.assert;
const Allocator = std.mem.Allocator;
const ArenaAllocator = std.heap.ArenaAllocator;
const StreamingParser = std.json.StreamingParser;
const Token = std.json.Token;
const TokenTag = std.meta.FieldEnum(Token);

/// Field options are options that can be set per-field on a struct at

mitchellh

const std = @import("std");
const assert = std.debug.assert;
const Allocator = std.mem.Allocator;
const builtin = @import("builtin");

const log = std.log.scoped(.flatpak);

/// Returns true if we're running in a Flatpak environment.
pub fn isFlatpak() bool {
    return if (std.fs.accessAbsolute("/.flatpak-info", .{})) true else |_| false;

mitchellh

const std = @import("std");
const assert = std.debug.assert;

/// An intrusive heap implementation backed by a pairing heap[1] implementation.
///
/// Why? Intrusive data structures require the element type to hold the metadata
/// required for the structure, rather than an additional container structure.
/// There are numerous pros/cons that are documented well by Boost[2]. For Zig,
/// I think the primary benefits are making data structures allocation free
/// (rather, shifting allocation up to the consumer which can choose how they

mitchellh

let
  # Playdate distributes their SDK as precompiled x86_64 binaries
  # currently so we have to import cross-compiled packages for it
  # if we're not on an x86_64 system.
  pkgsIntel = import <nixpkgs> {
    crossSystem = {
      config = "x86_64-unknown-linux-gnu";
    };
  };
in

mitchellh

//! Implements a texture atlas (https://en.wikipedia.org/wiki/Texture_atlas).
//!
//! The implementation is based on "A Thousand Ways to Pack the Bin - A
//! Practical Approach to Two-Dimensional Rectangle Bin Packing" by Jukka
//! Jylänki. This specific implementation is based heavily on
//! Nicolas P. Rougier's freetype-gl project as well as Jukka's C++
//! implementation: https://github.com/juj/RectangleBinPack
//!
//! Limitations that are easy to fix, but I didn't need them:
//!