On Mon, Apr 22, 2019 at 12:22 PM Richard Hipp <d...@sqlite.org> wrote:
> But before I proceed, I would like to better understand how rewiring > the refs this way constitutes "changing history". The refs/heads > entries are all ephemeral - they are constantly changing on their own, > and no historical record of their past values is retained. So if I > modify the refs to synchronize with the canonical Fossil repository, > how is that changing history, exactly? > Certainly no new SHA's were created, so this is much less obvious of a re-write than if you had performed a rebase of some kind. Nonetheless, I claim that this constitutes rewriting history because it has a similar impact to downstream users. Some user-visible symptoms, after a user had already synchronized to the master which was later abandoned: - From a context of master, `git pull` alone would construct a merge commit between the abandoned branch and the new master. `git pull --ff-only` would fail. - From a context of a custom patch series, `git rebase master` has unexpected effects, in that it also rebases the mistake you tried to orphan. - `git fetch` shows a forced update to origin/master. - A user who was using a merge-based workflow and had merged to your mistake branch would have a rough time following the change in branch name. One method would be to construct a new merge to the newly corrected master and then rebase any of their subsequent changes onto the new merge commit. Their workflow is no longer strictly merge-based and they still have to deal with the impacts of re-writing their history. Alternatively, they could construct the inverse of the mistake via `git revert` onto their own working branch and then merge again against the new master. These user-visible impacts and the recovery actions are almost the same as what a Git user would see if you had initially constructed (A, B, C, D) and re-written it to be (A, C', D') instead via a rebase. IMO, the proper corrective action after pushing the commit with a mistake in it would have been to commit the inverse of the mistake and then merge it to the alternate path. Yes, it would have constructed a merge commit in the history, which is unfortunate when you are trying to maintain a clean and linear history. But the impact to downstream users would have been negligible. `git pull --ff-only` would have Just Worked, `git rebase master` from a patch series would have Just Worked, and a merge-based workflow would have Just Worked, too. -- Jonathan Brandmeyer _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
