Thanks for the help. See additional questions and remarks below.... On 4/22/19, Jonathan Brandmeyer <jbrandme...@planetiq.com> wrote: > ``` > # Construct the matching branch name > git branch mistake 9b888fc > # Push the name alone to the remote > git push -u origin mistake > # Move the name of master > git checkout master && git reset --hard <correct-master-sha> > # Push the new name of master > git push --force > ``` > > Git reset --hard will move the name of the current working branch to > another branch SHA, which is why you need to first check out the > branch being moved: Its context sensitive. You are re-writing > history, though.
I don't understand this part. From the Fossil perspective, moving a check-in from one branch to another is just adding a new tag to that check-in. No history is changed. The DAG of check-ins (the block-chain) is unmodified. Subsequent to your message, I fixed the recent breakage of the SQLite Git mirror as follows: (1) cd into the refs/heads directory (2) run "cat master >mistake" (3) run "echo a9a5465eb44d0d8f1c3c9d288b7f23f628ddb50b >master" (4) run "git push --mirror https://github.com/sqlite/sqlite.git"; This was a one-time fix. I have not yet enhanced the mirroring mechanism to make this happen automatically, but probably I will soon. 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? Any further explanation is appreciated. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
