Skip to content

Instantly share code, notes, and snippets.

@StevenMaude
Last active April 17, 2018 20:33
Show Gist options
  • Save StevenMaude/3794e292fb9c2956ec11f002f487bd11 to your computer and use it in GitHub Desktop.
Save StevenMaude/3794e292fb9c2956ec11f002f487bd11 to your computer and use it in GitHub Desktop.
Destroy All Software screencast notes

Destroy All Software screencast notes

Earlier this year, the Destroy All Software screencasts were free to download. I grabbed a few that sounded interesting to watch.

These are notes of new things I learned.

0004: Source Code History Integrity

Difference in philosophy between git and Mercurial. Some Mercurial users don't believe that version control history should be changed. In git, changing history is a commonly used feature. Examples: rebase to reorder commits; doing commit --amend to change commit messages.

Arguments against changing history

  1. Breaks tests.

    You may rewrite history and find tests don't work against every commit.

    Making tests work against every commit before pushing can be useful if e.g. want to ensure that performance benchmarks run for every commit.

    Counter-argument: possible to use commands like:

    git rev-list --reverse master | while read rev; do git co $rev && git clean -fd && python runtests.py; done; git co master # Run tests on all master commits, then return to current master commit.

    and

    git rev-list --reverse origin/master..master | while read rev; do git co $rev && git clean -fd && python runtests.py; done; git co master # Run tests on all commits in master that have diverged from origin/master, then return to current master commit.

    CAUTION: these use git clean -fd.

  2. Clobbers existing work.

    Rewriting history and pushing will overwrite a remote.

    Counter-argument: have to force push to do that. When doing git push -f, should consider it carefully before doing so.

  3. Loses your work; can't revert back.

    Changing history will lose work you've done, so can't return to it.

    Counter-argument: git maintains commits for at least 30 days. Can use the reflog to go back in that time. Shouldn't fear changing history as the reflog does allow you to fix your mistakes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment