seanbecker15

// Read blog here: https://seanbecker.me/posts/chatgpt-text-completion

import { ChangeEvent, useState } from "react";
import { createParser, ParsedEvent, ReconnectInterval } from "eventsource-parser";

// Assumes that you can already fetch a completion from OpenAI
import { fetchCompletion } from "./api";

// Convert the stream to an async iterator.
// Found here https://jakearchibald.com/2017/async-iterators-and-generators/#making-streams-iterate

seanbecker15

Overview

Cleaning up branches before merging code on a team can be non-trivial. The goal of this gist is to discuss some of the common scenarios that occur as we are cleaning up our branch in preparation to merge.

Scenarios

Forked off of a branch that was squash merged

In this scenario, imagine that we start with 2 branches: main and a. Branch a has several commits that are not yet in main. We branch off of a to create branch b. Branch a is squash merged into main, leaving b with several commits that no longer need to be merged. When we are ready to merge b, how do we avoid merging all of these commits?

1. Squash merge b
   • When people review the PR, they will see all of the commits from a while reviewing. This leads to a less than desirable code review experience.

• Looking at the history of branch b in the future will be quite confusing.

seanbecker15

# This command allows you to cherry-pick a range of commits from sha1 (inclusive) to sha2 (inclusive).
# Finding the commit shas can be done using `glog`, `git log`, or by clicking on the history of a branch in github.

git cherry-pick $(git log sha1^..sha2 --reverse --pretty=format:"%h")

# Explanation of this command
# - The caret (^) indicates that we want to include sha1 in our output.
# - `git log` normally outputs commits from most recent to oldest, so --reverse is used to preserve commit order.
# - `--pretty=format:"%h"` indicates that we only want to display commit shas (and no other information).