diff options
Diffstat (limited to 'feedback_pull_before_build.md')
| -rw-r--r-- | feedback_pull_before_build.md | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/feedback_pull_before_build.md b/feedback_pull_before_build.md new file mode 100644 index 0000000..5fc187c --- /dev/null +++ b/feedback_pull_before_build.md @@ -0,0 +1,14 @@ +--- +name: feedback-pull-before-build +description: Always git fetch/pull to latest before building or publishing anything from a repo — do not build from whatever happens to be checked out +metadata: + node_type: memory + type: feedback + originSessionId: f8b83784-e0ed-462c-8310-7de6aadc9650 +--- + +Always `git fetch` and fast-forward to the remote's latest before building or publishing any artifact from a git-tracked project — never just build whatever is currently checked out in the sandbox. + +**Why:** Built and published a doot widget APK from a sandbox checkout that was 3 days / 90 commits stale (missing a full widget refactor plus several shipped features), without checking first. The user's reaction was sharp: this isn't a "turns out" surprise to shrug off, it's a basic step that should never be skipped — described it as "rookie shit." See [[project-doot-widget-build]] for the specific incident and the git remote gotcha that caused it (a stale/unreachable secondary remote made `git status` look misleading). + +**How to apply:** Before any build/compile/package/publish action in a git repo, proactively fetch and fast-forward first (or at minimum diff local HEAD against the relevant upstream) — do this by default, unproclaimed, not only when asked or when something looks off. Treat "did you pull first?" as a question that should never need asking. |
