DEV Community: Michael Sanford

Recover from a disconnected remote `do-release-upgrade` session

Michael Sanford — Tue, 17 May 2022 00:39:15 +0000

New Ubuntu Release

You log in over ssh and see this MOTD banner; woohoo new release!

481 updates can be applied immediately.
To see these additional updates run: apt list --upgradable

New release '22.04 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

So you do-release-upgrade - it starts, spawns a new screen session, you accept the scary warnings, and you're off.

Then, the client machine from which you were doing the update crashes (BSOD, kernel panic, what have you) and your session is lost.

Easy Recovery

Since do-release-upgrade spawned a screen session, you can simply reattach to it.

When you log in to your server and you will likely find a pts session open for root. This is the upgrader.

ubuntu@pi:~$ who
ubuntu   pts/0        2022-05-16 22:36 (192.168.0.x)
root     pts/1        2022-05-16 22:38 (192.168.0.x:S.0)

Switching to root, you see there is an attached screen session:

ubuntu@pi:~$ sudo su
root@pi:/home/ubuntu# screen -ls
There is a screen on:
        3915.ubuntu-release-upgrade-screen-window       (05/16/22 22:38:22)     (Attached)

Simply screen -d -r and you can take over the screen session and continue the update / follow its progress.

Temporarily Suspend BitLocker for firmware updates with reboot

Michael Sanford — Mon, 09 May 2022 06:04:09 +0000

Intel ME / Firmware on my Razer Blade Advanced

I recently discovered I was out of date with my Razer Blade Advanced Intel ME firmware.

However, the Razer Updater complains that I must "temporarily disable Bitlocker". However, suspending BitLocker from the Manage BitLocker Control Panel does not quell the warning.

That's because you need to boot the computer with BitLocker suspended and the GUI control panel does not allow you to do this:

PowerShell to the rescue!

In an Administrative PowerShell console, run the Suspend-BitLocker commandlet specifying that you want to automatically re-enable BitLocker after the second reboot:

Suspend-BitLocker -RebootCount 2 -MountPoint C

Which, if successful, will show you something like this:

C:\Windows\System32> Suspend-BitLocker -RebootCount 2 -MountPoint C

   ComputerName: BLADE

VolumeType      Mount CapacityGB VolumeStatus           Encryption KeyProtector              AutoUnlock Protection
                Point                                   Percentage                           Enabled    Status
----------      ----- ---------- ------------           ---------- ------------              ---------- ----------
OperatingSystem C:        460.71 FullyEncrypted         100        {Tpm, RecoveryPassword}              Off

Next Steps

Reboot your machine.

Run your firmware updater.

Reboot (firmware updater will probably do this for you).

Voilà - updated Intel ME and BitLocker is automatically re-enabled.

How to get Kali tools and Snap on a Chromebook

Michael Sanford — Thu, 10 Mar 2022 15:34:24 +0000

Introduction

Google has shipped (let's call it reasonable) support for Linux inside a container - official documentation.

I'll walk through how to set up Linux, add the Kali aptitude repo as well as Snap. This will get you up and running with your favourite tools.

You will not have a Kali desktop UI at the end of this tutorial, just access to the CLI tools, and Snap-based UI applications.

Enable Linux

Installing

Hit Search and type "Terminal".

This will bring up the "Set up linux development environment" wizard, which is also accessible through Settings.

Choose a username.

You can safely go with the recommended size of 10 GB, which can be easily resized later if you need more - or less - space.

Hit Next and wait a couple of minutes.

This will prepare a Debian Buster system in a virtualized container.

It will then open the Terminal app. Right-click it and Pin it to your taskbar for easy access, which you'll need later.

Customising your System

If you don't like the default hostname "penguin" you can change it. My Chromebook is silver in colour, and I'm French-speaking, so I decided to call mine "argent".

Modify the /etc/hostname file, replacing penguin with your preferred hostname.

Then, modify the first line of /etc/hosts to match, and leave the rest as they are. In my case:

127.0.1.1       argent
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

Now, instead of rebooting, right-click the Terminal in the taskbar and choose Shut down Linux. Then again to start it.

shutdown and reboot do not work as expected in this Linux subsystem; don't use them.

Adding Kali Aptitude Repos

Next, we'll add the Kali apt repos and the public GPG key:

echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list.d/kali.list

wget -q -O - https://archive.kali.org/archive-key.asc | sudo tee /etc/apt/trusted.gpg.d/kali-rolling-repo.asc

Note: You may see references elsewhere to apt-key add. This feature was deprecated yesterday, the above method is preferred.

Update your local aptitude cache:

sudo apt update

Get:1 http://kali.download/kali kali-rolling InRelease [30.6 kB]
Get:2 http://kali.download/kali kali-rolling/main amd64 Packages [18.0 MB]                  
Ign:3 https://storage.googleapis.com/cros-packages/99 bullseye InRelease
Hit:4 https://storage.googleapis.com/cros-packages/99 bullseye Release
Get:6 http://kali.download/kali kali-rolling/contrib amd64 Packages [113 kB]
Get:7 http://kali.download/kali kali-rolling/non-free amd64 Packages [194 kB]
Fetched 18.3 MB in 3s (5,779 kB/s)                       
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

347 packages can be upgraded. Run 'apt list --upgradable' to see them.

And update everything, clean and remove redundancies:

sudo apt update && sudo apt dist-upgrade -y && sudo apt autoremove -y && sudo apt autoclean -y

This took around 4 minutes on my N6000.

Restart the Linux system by right-clicking Terminal and choosing Shut down Linux. Click to start it again.

Snap

What is Snap?

Snaps are app packages for desktop, cloud and IoT that are easy to install, secure, cross‐platform and dependency‐free. Snaps are discoverable and installable from the Snap Store.

You can snap-in lots of great applications with a single command, like JetBrains IDEs, VS Code, Firefox, LibreOffice, and heck, even PowerShell!

Installing Snap

You need to install a few dependencies, notably the SquashFS and FUSE, and Snap itself:

sudo apt install libsquashfuse0 squashfuse fuse snapd

If you try to install Snap without Fuse, you'll get this error:

error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:

By default snapd will not start automatically when the Linux system is restarted; trying to run snap will fail with the following error:

error: cannot communicate with server: Post http://localhost/v2/snaps/hello-world: dial unix /run/snapd.socket: connect: no such file or directory

The permanent fix is to enable the service at startup:

sudo systemctl enable --now snapd.apparmor

Installing Snaps

Find some snaps from https://snapcraft.io/store and follow the instructions to install them.

Running Snaps

To run the snap for VS Code, for example:

snap run code

Note that the first time you run a snap it may take a long time to initialize. Subsequent runs will be quick.

SSH Keys

Might as well generate an SSH key while we're at it. ECDSA with key size of 521 bits is the currently-recommended standard but be warned it is not widely adopted:

ssh-keygen -t ecdsa -b 521

Hat-tips:

Kali VPN Tweaks for TryHackMe

Michael Sanford — Thu, 23 Dec 2021 16:27:25 +0000

I recently signed up for TryHackMe, a CTF-style online platform for learning cyber security, using hands-on exercises and labs. I prefer to use my own tooling (Kali) in a local virtual machine rather than the browser-based Attack Box. This requires an OpenVPN tunnel connection.

I discovered that while you can use Kali's default VPN client, you need to make a few configuration changes once you import your personalized .ovpn configuration file.

Note: This assumes you have configured your LAN to use a private IP range of 192.168.0.0/16 which virtually all SoHo routers do. (If you've reconfigured your router to address in 10.0.0.0/8 you probably don't need this guide.)

Step 1 - Download & Import your Configuration File

Click the Network Connections menu in the quick launch bar (top right), choose VPN Connections > New, choose Import A Saved VPN Confiruation... and provide your <tryhackme-username>.ovpn file.

Step 2 - Tweak Routes

Open the configuration's settings and choose the IPv4 Settings Tab, and click Routes....

Check off Use this connection only for resources on its network

Without this, all traffic will pass over the VPN tunnel, which has the negative side-effect of blocking anything that isn't served from the TryHackMe 10.0.0.0/8 network.

Step 3 - Set tool scope

You could additionally set scope of tools like BurpSuite to TryHackMe's IP range:

Clean up Github Actions Workflow Runs in PowerShell

Michael Sanford — Wed, 13 Oct 2021 15:47:01 +0000

Eager to set up all the CI bells-and-whistles, I went to test out Github Actions Workflows in a small, simple Python project.

I had two peculiarities with the project I was testing it with, though:

It's a serial modem adapter (yes, this kind) and I was using my git repo largely to version code and move it my Raspberry Pi.
After every test, I'd realize I needed another serial setting. Rather than polluting my commit history with broken intermediary projects, I would just amend the same commit and force push over and over. That rendered past Workflow runs uninformative garbage because they no longer referred to commits in the repo's history.

Now that I'm back in a more Operations-focused role, I'm keen to use PowerShell where I can, so I whipped up this "one-liner":

based on the bash-isms found herein (I also posted this as an answer there):

Anyone know a way to delete a workflow from GitHub Actions?

Sep 13 '19 Comments: 1 Answers: 19

I create a couple workflows in the .github/workflows folder of my repository to experiment with GitHub Actions. I have since learned quite a bit and deleted said "experimental" workflows from my repo. After deleting the "experimental" workflow yaml files and committing the deletions, when I go to the Actions tab…

Open Full Question

Finding breaking commits with git bisect

Michael Sanford — Fri, 21 Jul 2017 17:18:44 +0000

Step-by-step guide

The workflow goes like this:

git log to examine the commit history
git checkout <a confirmed working commit>
git checkout <a confirmed broken commit; often HEAD>
git bisect to find the breaking commit

To “bisect” means to cut in two. Git bisect does just that: you pick two commits, one that is known to be bad, and one that is known to be good, and git will check out revisions about half-way between both, and ask you to check each one and mark is as good or bad until you find the specific commit that introduced a bug.

In a small project with a handful of developers, it may be trivially easy to identify breaking commits. But when projects grow in complexity and large blocks are committed in rapid succession, by a large, distributed team, tools like this become useful.

Important note: Git bisect exists because people are human and make mistakes; this is simply a walkthrough of a tool used to help find those mistakes that slip through despite our best efforts.

Working Example

We will take a real-world example and walk through resolving the issue.

Noticing the problem

A developer attempts to start the exostore and is greeted with this message:

14:29:24.78 \<trace\> [init][db]start createDataPool (in dblink.js:63)
14:29:24.80 \<trace\> [kakyo] Init DB OK (in dblink.js:59)

/vagrant/exostore-v4/exo\_lib/data/modules/dbapi\_admin\_device.js:66
).error(errorHandler ).then(funcation(result){
^
SyntaxError: Unexpected token {
at Module.\_compile (module.js:439:25)
at Object.Module.\_extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module.\_load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.\<anonymous\> (/vagrant/exostore-v4/exo\_lib/data/dbmodules.js:9:23)
at Module.\_compile (module.js:456:26)
at Object.Module.\_extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
**error: Forever detected script exited with code: 8**

While it is immediately obvious where the problem lies (i.e., dbapi_admin_device.js:66), it would be imprudent to simply run in and fix it. We need to examine the commit history and see if other things were changed as part of a batch that may affect other components.

Examining the Log

git log oneline decorate

**759c997** ( **HEAD** , **origin/master** , **origin/HEAD** , **msanford** , **master** ) Globally refactor SUCCESSED \> SUCCESS; MSGID \> MSG\_ID; datas \> data.

**47a77a2** [EXO-135](https://exouinc.atlassian.net/browse/EXO-135) #resolve Add admin user account creation API, update stored procedure for error handling, scaffold unit test.

**19371ec** 1. Added a constraint in admin db tbe\_domain. 2. Added two test helper functions. 3. Added a insertion helper function. 4. Added a unit test case set for db\_store\_app model class.

**d38a884** add device related implementations

**9f05de2** Remove old fixture generation script

**a1f5ff3** Refactor comment style in db/\*.sql

**ea1b955** Manually regenerate vagrant-v4 fixtures

**3248f20** Updated translation support — Added data table sample — Removed unused stuff — Replaced message APIs routes by correct paths in `app.js`

**d7f3076** add get msg count apis

Here we see a series of commits, any one of which have the potential to break the system.

Rebasing is a time machine

While it might be tempting to assume the last commit in the history introduced the breaking change if you just saw it break for the first time, that is not necessarily the case!

Because we work in a private branch, rebase onto master, and then rebase master onto our working branch before pushing, commits made later in time may appear earlier in the work history because they were rebased.

Finding a good state

git checkout 9f05de2

Store starts correctly!

Find a bad state

git checkout master

This checks out origin/master HEAD (which at this time is 759c997). Store breaks!

Finding the breaking commit

Set up the initial state

git bisect start

git bisect good 9f05de2

Begin bisecting by marking a bad commit

git bisect bad 759c997
Bisecting: 1 revision left to test after this (roughly 1 step)
[19371eca935657ebaecb0a4e9879ce295a91f5a2] 1. Added a constraint in admin db tbe\_domain. 2. Added two test helper functions. 3. Added a insertion helper function. 4. Added a unit test case set for db\_store\_app model class.

Found bad commit, continue

At this point, git has checked out a specific revision (commit) about halfway between good and bad. After testing it, we see that the store fails to load, so we mark this as a bad commit.

git bisect bad

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[d38a88471524c07f3762921a030887e29460dc3e] add device related implementations

0 revisions to test after this means we have to test this revision, too. We’re getting close! But the store fails to start in this scenario as well. So, we mark this commit as bad.

Found another bad commit, continue

git bisect bad

**d38a88471524c07f3762921a030887e29460dc3e is the first bad commit**
commit d38a88471524c07f3762921a030887e29460dc3e
Author: [REDACTED]
Date: Thu Aug 28 09:16:14 2014 -0700

add device related implementations

:040000 040000 53c2f55597509733e427063ff7c8c8d9f6d5efeb aa6a09dd673be0a7d73ccf36f25fc6078ee3ae5d M exo\_lib
:040000 040000 f1d3b03ff9ffd3a56fa16a7f698c76bbc7883dd0 a75004b9fe513ec4edd27c12d5d7ae25177c3134 M routes

Found it!

The bisection is complete, we have identified the bad commit, so we can reset our working copy to its previous state.

git bisect reset

Previous HEAD position was d38a884… add device related implementations
Switched to branch ‘master’
Your branch is up-to-date with ‘origin/master’

Fixing it

Now that you have found the commit that introduced the breaking change, you can take steps to remedy it, which may include:

Contacting the commit author directly,
Correcting it yourself and pushing an urgent fix commit.

In this case, finding the commit was useful because it surfaced not only the obvious, known issue as well as another, related issue in the same commit.

Performance

Bisection is usually the term given to searching over a continuous value function, whereas git commits are obviously discrete elements, properly making git-bisect a binary search algorithm.

Binary search runs in worst case O(log n) time and O(1) space.

Binary search method for the value 7 starting at 14; WikiMedia Commons.

Replace 14 and 6 with “known good” and “known bad” commits, and it’s essentially the same process.

Popups in Print Media 2.0

Michael Sanford — Wed, 08 Jul 2015 02:42:41 +0000

Well, we’ve come full circle. This morning, I took a Journal métro (while exiting the Métro) to discover that an enterprising marketing guy had stuck a popup on my print media.

I’m a fan of print media. I prefer to read Le Monde Diplomatique or Monocle in their print forms (even considering tablets). I also think that traditional media can learn from new media. But, seriously, let popups and popovers die already.

Originally published at michaelsanford.com on January 15, 2013.

Compiling xslcache 0.7.1 for PHP 5.4

Michael Sanford — Fri, 22 May 2015 19:46:09 +0000

We make heavy use of xslt at work (parsing xml data generated by php controllers), so the xslcache pecl module is pretty fundamental to our infrastructure. Of course, if you are using PHP 5.4 or above, like many pecl modules, it breaks. Here’s how to get it to work.

Currently, trying sudo pecl install xslcache-beta with PHP >= 5.4 throws the following error at make:

/tmp/pear/temp/xslcache/php\_xsl.c: In function 'xslcache\_objects\_new': /tmp/pear/temp/xslcache/php\_xsl.c:211:52: error: 'zend\_class\_entry' has no member named 'default\_properties' make: \*\*\* [php\_xsl.lo] Error 1 ERROR: `make' failed

Download xslcache

Download the original source from the pecl svn repository, the 5.4 patch, and patch it manually:

svn checkout [http://svn.php.net/repository/pecl/xslcache/trunk](http://svn.php.net/repository/pecl/xslcache/trunk) xslcache cd xslcache wget -O php\_xsl.c.patch 'https://bugs.php.net/patch-display.php?bug\_id=62856&patch=xslcache-php5.4-compat&revision=1362641549&download=1' patch \< php\_xsl.c.patch

Make and install

This is a pretty straightforward make process for most linux software (you may need to adjust the location of xslcache.ini):

phpize ./configure make make test sudo make install sudo nano /etc/php5/cgi/conf.d/xslcache.ini #add "extension=xslcache.so"

Note that if you make test the tenth may fail with the following:

=================================================================== FAILED TEST SUMMARY 
------------------------------------------------------------------- Test 10: EXSLT Support [tests/xslt010.phpt] ===================================================================

If you’re using XSLT 2.0, you probably don’t need to worry about it.

Verify that xslcache is installed and enabled

Since we’re already in the command line, let’s check there:

php -i | grep XSLCACHE

Hopefully, you will see the following line:

XSLCACHE =\> enabled

Furthermore, you should be able to actually know it’s doing its job because your benchmarks should improve.

Originally published at michaelsanford.com on March 22, 2013.

Clean up and compact your VDI

Michael Sanford — Fri, 22 May 2015 19:24:34 +0000

TL;DR

Guest OS: sudo sfill -llvz /

Host OS: VBoxManage modifyhd --compact \<\_.vdi\>

Details

My VirtualBox thin server had put on a few pounds over the months of guest OS database imports, static resource creation, temp file creation, log rotation, and a bunch of other stuff I don’t need to store indefinitely. Every time more sectors need to be called upon to store something in the guest, VirtualBox will grow the physical VDI image accordingly, up to the maximum size specified. However, when you delete files from the guest system, the VDI doesn’t shrink accordingly (and with good reason).

If you have implemented a backup strategy — as I have with Time Machine — you probably don’t want to back up a 30 GB VDI file every single time a single bit changes (for example, when you boot the virtual machine). This is particularly true when you have deleted old databases, resources and logs, and the guest OS really only represents about 5 GB of data.

VBoxManage modifyhd allows you to compact a physical VDI, but with one important precondition, it only truncates zeros in the guest from the VDI:

With the — compact option, can be used to compact disk images, i.e. remove blocks that only contains zeros. This will shrink a dynamically allocated image again; it will reduce the physical size of the image without affecting the logical size of the virtual disk. Compaction works both for base images and for diff images created as part of a snapshot.

So simply having deleted a file from your guest will not allow you to reclaim space. You have to zerofill the free space on guest OS’s volumes.

In your Guest (in this case, Ubuntu Server 12.04.02 LTS)

sudo apt-get install secure-delete sudo sfill -llvz /

The -ll option writes only one pass (instead of the default 38) and the -z option replaces the single pass of data from /dev/urandom with zeros, which is what VBoxManage is looking for.

In your host:

VBoxManage modifyhd --compact \<virtual\_disk\_file.vdi\>

I shrunk mine from 25 GB to 5 GB in a single step. My SSD allowed me to zerofill about 20 GB in the guest and compact the VDI in less than 90 seconds.

Originally published at michaelsanford.com on August 8, 2013.

Rebasing to avoid merge commits

Michael Sanford — Fri, 15 Aug 2014 17:00:10 +0000

Everyone likes to keep the source control history linear, preferring fast-forward merges to merge commits. It’s really not that hard. Promise.

Git’s commit structure is a linked list of snapshots whose commits point to one or several ancestors. This means that you must “base” your work on a previous commit.

What’s a merge commit?

Merge commits can be useful when merging topic/feature branches together to indicate, in the history, where branches were combined.

When working on a single branch, however, they are ugly, unnecessary, clutter the history, and look like this:

Here, I worked on master in two places,

This is the result of doing work — not necessarily on the same file just in the same branch — in two places at once. Here, eada9ae and eac49bb are both children of 7036724, but they contain different snapshots which were merged at 53ad270.

Rebasing for great success

Let’s start with a history like this:

Nice, linear history (so far)

Now, let’s work on the same file in two places at once (and also simulate a merge conflict). To do this, I’ll edit the file locally in the working copy, and I’ll edit it in the BitBucket editor (which gets committed and pushed immediately):

BitBucket edit appears in the history.

Now, edit and commit the file locally:

msanford@Tenjin:/tmp/rebase-example $ git commit -m “Fourth commit — working copy”
[master 25dd301] Fourth commit — working copy
 1 file changed, 1 insertion(+)

Our branches are now out of sync: HEAD in origin/master points to 4ff5d2 whereas it points to 25dd301 in the working copy:

msanford@Tenjin:/tmp/rebase-example $ git log --oneline
25dd301 Fourth commit — working copy
e8a2bb8 Third commit — working copy
988eb03 Second commit — working copy
4168ee0 Initial commit — working copy

At this point, if you git push from the working copy, you’ll see this familiar message, suggesting that you git pull:

msanford@Tenjin:/tmp/rebase-example $ git push
To [git@bitbucket.org](mailto:git@bitbucket.org):michaelsanford/rebase-example.git
 ! [rejected] master -> master (fetch first)
error: failed to push some refs to ‘[git@bitbucket.org](mailto:git@bitbucket.org):michaelsanford/rebase-example.git’
hint: **Updates were rejected because the remote contains work that you do**
hint: **not have locally**. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ‘ **git pull** …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘ **git push --help** ’ for details.

Note that the hint also suggests consulting “the fast-forward section of the manpage” which, of course, nobody has ever done. It suggests a more elegant course of action.

msanford@Tenjin:/tmp/rebase-example $ **git pull --rebase**
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From bitbucket.org:michaelsanford/rebase-example
 e8a2bb8..4ff45d2 master -> origin/master
**First, rewinding head to replay your work on top of it…**
Applying: Fourth commit — working copy
**Using index info to reconstruct a base tree…**
M README.md
Falling back to patching base and 3-way merge…
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Failed to merge in the changes.
Patch failed at 0001 Fourth commit — working copy
The copy of the patch that failed is found in:
 /private/tmp/rebase-example/.git/rebase-apply/patch

When you have resolved this problem, run “git rebase —continue”.

Rebase succeeded (no error messages)? No merge conflicts? You can push right away!

Handling Merge Conflicts

Oh no, a merge conflict in the file we were working on!

README.md:

Edited locally in the working copy.
Second edit locally from the working copy.
Third commit locally from the working copy.
<<<<<<< HEAD
Fourth commit from BitBucket.
=======
Fourth commit locally from the working copy.
>>>>>>> Fourth commit — working copy

No problem: we can edit the file in the working copy, resolve the conflict, and rebase continue.

msanford@Tenjin:/tmp/rebase-example $ vi README.md
msanford@Tenjin:/tmp/rebase-example $ git add README.md
msanford@Tenjin:/tmp/rebase-example $ git rebase —continue
Applying: Fourth commit — working copy

msanford@Tenjin:/tmp/rebase-example $ git status
On branch master
Your branch is ahead of ‘origin/master’ by 1 commit.
 (use “git push” to publish your local commits)

What happened?

Git rebase has, as the name suggests, changed the base of our working copy’s commit history to match origin/master’s base. Since both the local working copy and the remote have the same base commit (after fixing the merge conflict) it has allowed us to fast-forward our work as a patch on top of the remote’s commit and maintain a linear history.

This results in a nice, straight line that contains all of the work done in a semantically-sensible way (because the merged changes are topical):

In the first example (with the merge commit) if our working copy held the blue line with eac49bb, git pull rebase would pull eada9ae, then create a patch and replay the work contained in eac49bb on top of that commit (_instead of using _7036724 as the base_)_, fast-forwarding it and preserving a linear topical history.

Teams

In this example I have used only one developer, but that is not relevant: you can do this in teams exactly the same way!