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.
The key bit here is that in git, every commit references its parent commit
hash, and thus implies the entire past history for that commit. And local
git repos contain that entire history. So when a branch head is updated
upstream, git can tell if history has moved forward (ie, the new head
commit contains the previous head commit in its history), and if not, it's
considered a "forced update", which is to say, history was re-written --
since the last previously know state of history is nolonger part of
history.
Carl
On Mon, 22 Apr 2019, Carl Edquist wrote:
Hi Richard,
As Jonathan mentioned, in git land, if you have already published a
"mistake" commit publicly, the proper way to revert it is to make another
commit to reverse/undo the change.
By removing a commit from the public history of the published 'master'
branch, it forces everyone downstream to manually fix their history.
If they do a normal "git pull", git will attempt to merge their master
(the mistake commit) with the latest upstream master, which is not
actually your intention.
But if you make an "revert" commit to undo the change, history will
continue forward for the master branch from the downstream perspective.
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";
Not that you want to do it this way again if you can avoid it, but the
safe git way to do (2),(3) is:
2) git update-ref refs/heads/mistake refs/heads/master
3) git update-ref refs/heads/master a9a5465eb44d0d8f1c3c9d288b7f23f628ddb50b
Carl
On Mon, 22 Apr 2019, Richard Hipp wrote:
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
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
