Levandor

esign_css customization/instacash — orphan-history operational warning

5 min read

esign_css customization/instacash — orphan-history operational warning

CRITICAL — read this before any esign_css instacash update

customization/instacash in esign_css is not a fork of devel in the conventional sense. It is a single squashed orphan commit with zero shared history with devel. Standard git merge origin/devel will halt with refusing to merge unrelated histories, and git rev-list --count A..B returns misleading numbers because there is no merge base. Future sessions need this context before attempting any sync.

What “orphan” means here

PropertyValue
customization/instacash HEADb7cee2f (“1.3.0.10”, 2025-11-20)
Number of commits on the branch1 (it’s a single squashed commit)
git merge-base origin/customization/instacash origin/develEmpty — returns nothing
Shared history with develNone
Standard merge behaviorHalts: refusing to merge unrelated histories

This is not a “very stale branch” — it’s a structurally distinct line of history that was squash-built off some prior baseline and forced into the branch as the sole commit. Treating it like a normal long-running customization branch will lead to either misleading status output or destructive merges.

Path delta against devel (as of 2026-05-27)

Even though there is no shared history, the trees differ in 95 paths:

ClassCountMeaning
Modified (M)26Both branches have the file, contents diverge
Added (A) on devel14New on devel, absent on instacash
Deleted (D) on devel55Removed from devel, still on instacash

The 55 retained files are intentional

The 55 paths in the “deleted from devel, still on instacash” set include MBH/MKB branding assets that InstaCash wants to retain. They are not stale — they are part of the InstaCash deliverable. Any merge strategy must preserve them or surface them for explicit decision-per-file.

Gotchas this creates

1. git merge origin/devel halts immediately

$ git merge origin/devel
fatal: refusing to merge unrelated histories

You can force it with --allow-unrelated-histories, but doing so blind produces a 95-path conflict surface and risks dropping the 55 retained files if you accept the upstream side wholesale.

2. git rev-list --count A..B is meaningless

Because there is no merge base, the “X behind / Y ahead” counts reported by git rev-list or git status against an upstream do not reflect a real commit distance. Don’t quote those numbers in tickets or status reports for this branch — they’re a category error.

3. Cherry-pick across the boundary is fragile

Without a shared base, git cherry-pick <devel-commit> onto customization/instacash is operating against a different ancestor than the commit was authored against. Conflicts will be much heavier than a same-history cherry-pick.

Workflow options going forward

Three viable strategies, each with tradeoffs. Decision needed before attempting the 2026-05-27 update.

Option A — Brutal --allow-unrelated-histories merge

git merge --allow-unrelated-histories origin/devel
  • Pro: One-shot, recoverable via git merge --abort.
  • Con: 95-path conflict surface; very high cognitive load to reconcile correctly without dropping branded files; produces an irregular history shape.
  • When to pick: Only if the InstaCash baseline genuinely needs to align to current devel and the team accepts the resolution cost.

Option B — Rebase-replay (suspected historical pattern)

Replay devel + a captured InstaCash delta on top, then force-push the result as a new squashed orphan.

  • Pro: Keeps the “single squashed commit” shape that the previous release 1.3.0.10 (b7cee2f) appears to use; consistent with how prior InstaCash releases on esign_css seem to have been built.
  • Con: Requires reconstructing or maintaining a canonical “InstaCash delta over devel” patch set; force-push means losing reflog visibility for any contributor who pulled the old shape.
  • When to pick: If the team confirms (see “Confirmation needed” below) that this is the documented historical pattern.

Option C — Cherry-pick the InstaCash delta forward

Identify the InstaCash-specific changes against the prior baseline devel (whatever it was when 1.3.0.10 was cut), then cherry-pick that delta onto current devel.

  • Pro: Cleanest narrative; produces a real diff you can review per-commit.
  • Con: Requires excavating the prior baseline (no merge base helps here); cherry-pick boundaries are still fragile across unrelated histories; assets-only changes (the 55 retained files) need separate handling.
  • When to pick: If the InstaCash delta is small enough to enumerate and you want a reviewable PR shape.

Confirmation needed

Before committing to a workflow, confirm with the FaceKom team (or by inspecting prior update/customization/instacash-* branches if any remain on origin):

  • Was the 1.3.0.10 cut (b7cee2f, 2025-11-20) done via Option B (rebase-replay + force-push)?
  • Is there a canonical “InstaCash delta” patch set maintained anywhere, or is the squashed commit itself the source of truth?
  • Does the team want to break the orphan pattern going forward (use a true long-running branch with shared history) or continue the squash-orphan release cadence?

These three questions decide whether the 2026-05-27 update is a procedural exercise or a workflow-design conversation.

Quick reference — diagnostics that work

When the standard merge tools mislead, these still give you useful signal:

# Verify there is no merge base (returns empty if orphan)
git merge-base origin/customization/instacash origin/devel
 
# Count commits on the branch (will be 1 if squashed orphan)
git rev-list --count origin/customization/instacash
 
# Path-level diff against devel (95 paths in 2026-05-27 snapshot)
git diff --name-status origin/customization/instacash..origin/devel
 
# Split the 95 by class
git diff --name-status origin/customization/instacash..origin/devel | awk '{print $1}' | sort | uniq -c

Graph View

Backlinks