ffmpeg -i <input-file> -c <codec> <output-file>

Start with the ffmpeg command

-i = input file

<input-file> either a stream url or local file

-c = codec to be used

<codec>\= I always use copy to use the same codec as the stream, or you can specify any other codec you want

<output-file> = the filename you want to save

Trim the parts you don't want

ffmpeg -ss <hh:mm:ss> -i <input-file> -to <hh:mm:ss> -c <codec> <output-file>

Start with the ffmpeg command

-ss = start time of the video to trim

<hh:mm:ss> = must be in the format of hours:minutes:seconds

-i = input file

<input-file> either a stream url or local file

-to = total length of clip time, this can be confusing at first because you need to calculate the elapsed time of the clip. e.g. If you want to trim a clip that begins at 01:23:33 (one hour, 23 minutes, 33 seconds) and you want the video trimmed to 01:23:55 (one hour, 23 minutes, 55 seconds), the value of to would be 00:00:22 (22 seconds elapsed time)

-c = codec to be used

<codec>\= I always use copy to use the same codec as the stream, or you can specify any other codec you want

<output-file> = the filename you want to save, make sure you create a copy and don't overwrite the original file you are trimming

Save all your files with a consistent naming pattern to easily collect them for future use

for f in <pattern>; do echo "file '$f'" >> <output-file>; done

let's write a bash script to easily create a playlist of the files you want to concat

for <variable> in is a bash loop to find all instances of the pattern given

f is a variable name for "file", it could be anything

<pattern> is a regex pattern of the filename e.g. *title-mm-dd-yy*

do begins the looping process

echo "file '$f'" tells bash to write the text "file <filename>" from the variable f to stdout (the terminal)

>> is a direction operator in Linux to write a file. When two arrows are present, it signifies append to the existing file

<output-file> should be a text file e.g. files.txt

<semi-colon> is used to end the previous command

we need to finish with a done command to finish the loop

This will create a files.txt with a playlist of the matching files

file 'game-01-01-23_1.mp4'

file 'game-01-01-23_2.mp4'

file 'game-01-01-23_3.mp4'

file 'game-01-01-23_4.mp4'

Concat your files

ffmpeg -f concat -i <input-file> -safe 0 -c <codec> <output-file>

Start with the ffmpeg command

-f\= indicates to ffmpeg to list each file for concatenation

concat = concatenate command

-i = input file

<input-file> either a stream url or local file

-safe 0 = dictates unsafe file names should be ignored, this is mainly used to allow relative paths

-c = codec to be used

<codec>\= I always use copy to use the same codec as the stream, or you can specify any other codec you want

<output-file> = the filename you want to save, make sure you create a copy and don't overwrite the original files you are using to create the final version

This has some challenges, especially when reviewing PRs and committing changes to those PRs on the respective, remote forks.

After many months and lots of blog reading, git-scm.org - The Refspec review and trial and error, I think I finally figured out the best way to work with this forking strategy.

First things first, set your refspecs to pull down all the PRs to the main repo. I picked this up from Atlassian's blog - Pull Request Proficiency.

I went about it slightly differently from their post but it works just as well and it was fewer steps.

Add a git config for remote.origin.fetch This adds a local namespace so you can eventually checkout a pr with shorthand

git config add remote.origin.fetch +refs/pull-requests/*:refs/remotes/origin/pr/*

git pull origin <main branch> or whichever branch you are receiving the PRs

 git pull origin develop
remote: Enumerating objects: 501, done.
remote: Counting objects: 100% (326/326), done.
remote: Compressing objects: 100% (229/229), done.
remote: Total 248 (delta 170), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (248/248), 54.99 KiB | 1.37 MiB/s, done.
Resolving deltas: 100% (170/170), completed with 42 local objects.
From ssh://bitbucket.<your-domain>.com:<port>/<project>/<repo>
 * branch                  develop                      -> FETCH_HEAD
 * [new ref]               refs/pull-requests/1472/from -> origin/pr/1472/from
 * [new ref]               refs/pull-requests/1473/from -> origin/pr/1473/from
 * [new ref]               refs/pull-requests/1474/from -> origin/pr/1474/from
 * [new ref]               refs/pull-requests/1475/from -> origin/pr/1475/from
 * [new ref]               refs/pull-requests/1477/from -> origin/pr/1477/from

Now you can checkout the PR on your local machine with git checkout origin/pr/1474/from

git checkout origin/pr/1474/from
Note: switching to 'origin/pr/1474/from'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at <commit> fix spec validations

Now you're free to poke around, make changes, and commit changes to your local detached HEAD state

You'll notice here, git reminds you that you are in detached HEAD state on commit.

git commit -m "<commit message title>" -m "    <commit message body>[APIDESGN-1367]"
[detached HEAD <commit>] feat(api): update event-notifications schema
 7 files changed, 32 insertions(+), 384 deletions(-)
 delete mode 100644 <some-file-named-you-modified>

-- You ARE using <issue-keys> in your commit messages, RIGHT?!?!

Now comes the fun part, setting up the remote fork and pushing your local changes to the PR. Add a new remote and name it whatever you want. This is the fork where the PR originated. I usually use the PR number as the remote to remind me of the PR number

git remote add 1474 ssh://git@bitbucket.<your-domain>.com:<port>/<project>/<repo>.git

You can run git remote -vv to see all of your remote configs

git remote -vv
1474    ssh://git@bitbucket.<your-domain>:<port>/<fork-project>/<repo>.git (fetch)
1474    ssh://git@bitbucket.<your-domain>:<port>/<fork-project>/<repo>.git (push)
origin  ssh://git@bitbucket.<your-domain>:<port>/<main-project>/<repo>.git (fetch)
origin  ssh://git@bitbucket.<your-domain>:<port>/<main-project>/<repo>.git (push)

Now you can run git branch and notice you have the HEAD detached and your develop branch. (you may have additional branches)

git branch
* (HEAD detached from origin/pr/1474/from)
  develop

It's time to fetch the upstream repo to pull down the actual branch name on the remote fork

 git fetch 1474
remote: Enumerating objects: 54, done.
remote: Counting objects: 100% (54/54), done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 60 (delta 28), reused 1 (delta 1), pack-reused 6
Unpacking objects: 100% (60/60), 16.54 KiB | 127.00 KiB/s, done.
From ssh://bitbucket.<your-domain>:<port>/<fork-project>/<repo>
 * [new branch]            develop    -> 1474/develop
 * [new branch]            feature/APIDESGN-1367-<branch-name> -> 1474/feature/APIDESGN-1367-<branch-name>

Now we know the name of the original branch from the fork, we can checkout and merge our new commits. Since I've committed changes to the detached HEAD, I need to merge that commit into the branch. You can work in detached HEAD state or you can work on the actual branch, I just happened to make some changes while poking around in detached state. The beauty of checking out the branch in this fashion is git automatically sets the new branch to track the upstream branch, which is linked to the original PR

 git checkout feature/APIDESGN-1367-<branch-name>
Warning: you are leaving 1 commit behind, not connected to
any of your branches:

  <commit> feat(api): update event-notifications schema

If you want to keep it by creating a new branch, this may be a good time
to do so with:

 git branch <new-branch-name> <commit>

Switched to a new branch 'feature/APIDESGN-1367-<branch-name>'
branch 'feature/APIDESGN-1367-<branch-name>' set up to track '1474/feature/APIDESGN-1367-<branch-name>'.

Checking git branch -vv once more indicates the new branch is tracking the upstream we defined as 1474

git branch -vv
  develop                                    <commit> <commit-message>
* feature/APIDESGN-1367-<branch-name> <commit> [1474/feature/APIDESGN-1367-<branch-name>] fix spec validations

I opted not to create a new branch as suggested by the git cli but rather merge my previous commit on the detached HEAD to the branch we just checked out

git merge <commit-from-detached-head>
Updating <commit>..<commit>
Fast-forward
 ...<some-modified-files>     | 104 +---------
 7 files changed, 32 insertions(+), 384 deletions(-)

Now we are ready to push our local changes to the upstream remote fork, but first let's check the status to see where we are. Oh look! Git recognizes we are now 1 commit ahead of our upstream remote fork branch

git status
On branch feature/APIDESGN-1367-<branch-name>
Your branch is ahead of '1474/feature/APIDESGN-1367-<branch-name>' by 1 commit.
  (use "git push" to publish your local commits)

OK, let's push! We use the upstream remote name and the branch name to tell git where we want to go and where the changes were made

git push 1474 feature/APIDESGN-1367-<branch-name>
Enumerating objects: 24, done.
Counting objects: 100% (24/24), done.
Delta compression using up to 8 threads
Compressing objects: 100% (12/12), done.
Writing objects: 100% (13/13), 1.44 KiB | 491.00 KiB/s, done.
Total 13 (delta 8), reused 0 (delta 0), pack-reused 0
remote:
remote: View pull request for feature/APIDESGN-1367-<branch-name> => develop:
remote:   https://bitbucket.<your-domain>.com/projects/<project>/repos/<repo>/pull-requests/1474
remote:
To ssh://bitbucket.<your-domain>.com:<port>/<project>/<repo>.git
   <commit>..<commit>  feature/APIDESGN-1367-<branch-name> -> feature/APIDESGN-1367-<branch-name>

git log --follow --name-only -p <file>

• git log: is the command to view the history of the entire repo
• --follow: allows us to "follow" the commit history of a specific file including where a file was renamed
• --name-only: allows us to trim the commit message output to only view the file names and metadata associated with the commit message rather than the complete diff
• -p: indicates the file path to search for

Using freeCodeCamp Open Source project gives us the following when searching for the Hall Of Fame (HoF.md) file.

git log lists commits in reverse chronological order: (newest first)

Here you can see the file:

• created Feb 6, 2020
• updated on Feb 8, 2020
• updated again on Mar 18, 2020.

// using a relative path of the root folder freeCodeCamp to find HoF.md

$ git log --follow --name-only -p './HoF.md'

commit 7613df56e1736ae6c53fac3eaedc3570cdb636a9
Author: mrugesh <1884376+raisedadead@users.noreply.github.com>
Date:   Wed Mar 18 06:23:56 2020 +0530

    chore: add Peter-Samir to HOF (#38384)

    Co-authored-by: Peter-Samir <43256727+Peter-Samir@users.noreply.github.com>

HoF.md

commit 9e1bac4807d0268c561bb8ddad84fffac8ee07e1
Author: mrugesh <1884376+raisedadead@users.noreply.github.com>
Date:   Sat Feb 8 21:12:19 2020 +0530

    docs: update hall of fame verbiage

HoF.md

commit 158188924b9281f2afe5332c7804ddcd058137c9
Author: Mehul Mohan <mehulmpt@gmail.com>
Date:   Thu Feb 6 18:14:20 2020 +0530

    docs: added responsible disclosure and hall of fame

HoF.md

I've been knee deep in OpenAPI specs in my current role as an API Product Manager. While the work is fulfilling, there are some very mundane aspects to onboarding a development team when using the OpenAPI specification; particularly, the formatting of YAML documents. There is a wonderful readability aspect to working with YAML when certain behaviors are adhered to. Without getting into the firestorm of using single quote ('), double quote (") or no quotes, you can read more about that here, I find myself reviewing several documents where our development team are diverging from each other in the way they are documenting our API's. Certainly, there is a selfish aspect of wanting consistency while reviewing these documents. I have 1000's of specs to review for our internal developer ecosystem and I'm trying my best to automate as much review work as possible.

Ok, let's get to it: I have documents exceeding 10-thousand lines of code and there are 100's of enumerations throughout. I needed a quick and easy way to clean up the excessive quotes wrapping enum strings because it looks hideous!

Typically, I'm reviewing OpenAPI docs in VS Code because first and foremost, it's my favorite editor, and secondly, the plethora of extensions for making my life easy to read 10-thousand line documents.

some of my faves: Indent-Rainbow Spectral API Linter Prettier

Start with ctrl + f / cmd + f and select the .* icon, or toggle regex with alt + r / cmd + r

There is probably some caveat here about using example(s) in OpenAPI because there are a few different ways to represent them, depending on the version. I'm using example at the schema level which means we don't have any representation of an array example which can be overwritten by my regex.

We start with an OpenAPI document similar to our Animal example:

openapi: 3.0.3
info:
  description: This is a great representation of an Animal
  version: '1.0.0'
  title: Animal
  contact:
    name: 'jeremy'
    email: 'hola@jeremyfiel.com'
paths:
    /endpoint:
      get:
         ...
components:
  schemas:
    Animal:
      description: Some type of living creature
      type: object
      required:
        - breed
      properties:
        breed:
          type: string
          enum:
            - 'GERMAN SHEPARD'
            - 'BEAGLE'
            - 'RETRIEVER'
          example: 'BEAGLE'

I'm looking for any representation of an enumeration in the file.

The formatting is:

• any line starting with spaces or tabs
• eventually a -
• followed by a single space to indicate the array of enumerations available.
• Then, I'm expecting a string wrapped in some form of quotes.

 ^(\s+-\s)  ('|"|`)  (\w+((\s|-)+\w+)*)  ('|"|`)$
 ^---1---^  ^--2--^  ^--------3--------^ ^--4--^

Capture Groups:
  one: starts with any number of spaces or tabs, a dash and exactly one following space
  two: finds any type of quote. single('), double("), backtick (`)
  three: finds any word representation, including spaces, underscore, or hyphens
  four: finds any type of quote. single('), double("), backtick (`)

VS Code uses ripgrep as their regex search engine, so we are able to use positional arguments provided by the bash scripting engine. This is why I've split the regex into capture groups. Each capture group is returned as a separate argument and we can utilize these arguments to replace our enum strings without the ugly quotes.

The arguments follow a numbering sequence and can be called directly in the replace text field.

If we were to look at the argument sequence, it breaks down like this:

• $0 is equivalent to the first match of the entire find command. In our case, the result of the regex pattern we used to search ......- 'GERMAN SHEPARD'
• $1 is the indentation, dash and single space before the string ......-
• $2 is the first set of quotes '
• $3 is our enum string GERMAN SHEPARD
• $4 is the final set of quotes '

Now we can use these arguments to replace the text without the quotes.

$1$3

   $1 holds the first capture group which is "        - ".  This is the indentation and dash 
   $3 holds the third capture group which is our enum string *without* quotes.

Viola!

      properties:
        breed:
          type: string
          enum:
            - GERMAN SHEPARD
            - BEAGLE
            - RETREIVER
          example: 'BEAGLE'

It's so beautiful!! Now I can get back to reviewing my documents without stabbing my eyeballs with a bunch of ugly quotes.

If you like tips like these, let me know!