Scenario: removed-before-init
Why a splice's upstream history starts at init: everything the folder
held before stays in the monorepo, including what was removed again.
- Monorepo (
lib/a/): two commits, then a commit that adds a password toconfig.txt, and one that removes it again. - Upstream: empty.
Until init, the folder was written for the monorepo, not for an
upstream. Its history may hold passwords, internal names or files that
were removed before anyone decided to publish the folder. So the first
push sends the folder as it is at init, as one commit: the init commit,
with its message and author. Every commit after it is pushed as usual.
The same goes for a folder that becomes a splice with clone --merge:
the upstream gets the merge, not the folder's history from before it.
It's the same concern as
pushing the monorepo to a subfolder's upstream,
on a smaller scale: history reaching an upstream it wasn't meant for.
Output
setup.bash builds this state:
$ build_scenario scenario_removed_before_init
The password is in the monorepo's history:
$ git log --format=%s -- lib/a
remove the password again
password = hunter2
second version
first version
$ git splice init lib/a "$UPSTREAM" && git splice push lib/a
ok lib/a: initialized -- 'git splice push lib/a' publishes it
?? lib/a: upstream has no 'main' branch yet -- this push creates it
ok lib/a: pushed 905f2b9 to main
The upstream starts at the init commit:
$ git -C "$UPSTREAM" log --format=%s main
splice: init lib/a
It never had config.txt, so it never had the password:
$ git -C "$UPSTREAM" log --format=%s main -- config.txt