3 ms·

What do you mean by "persistent"? Unlike Git, in Fossil you cannot rewrite history _at all_. It's an immutable collection of artifacts. There's no rebase. See h

by dchest 15y ago

What do you mean by "persistent"? Unlike Git, in Fossil you cannot rewrite history _at all_. It's an immutable collection of artifacts. There's no rebase. See http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.wiki http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.... Zed lost his working copy. You can do this in git by running "git reset --hard".

ollysb 15y ago
git reset --hard will only orphan commits, they're still there. git reflog will get you to them fast and I'm sure there's many other more exotic ways to find them. Admittedly garbage collection will remove them at some point but that's generally a lot further away than 'oops'.
- dchest 15y ago
  Working copy
j_baker 15y ago
You can't rewrite history in git either. You can however make new commits that are different from the old commits somehow. A branch in git is basically just a pointer to a set of immutable commits. http://hackerne.ws/item?id=2524993 http://hackerne.ws/item?id=2524993
- dchest 15y ago
  It depends on what you mean by "history". Moving refs around is already "modifying history" in Fossil world.
  - j_baker 15y ago
    I don't care what Fossil considers rewriting history. Rewriting history means altering a commit that has taken place in the past, which git can't do.
    - dchest 15y ago
      What about branches? Tags? Git's fast-forward? Some people think of the whole DAG as history.
      - jlouis 15y ago
        Branches and tags are just "Stick-it-notes" you attach to the DAG. They can be removed around at whim, but they only serve to mark a point in the DAG for your convenience. The GC process will kill parts of the DAG with no such branch/tag, but it only happens after some days by default. Were git able to rewrite history, it couldn't use SHA1 checksums as names for the content. Note that a rebase alters the SHA1 stack you have, so it is regarded as something different. But you can't do that easily with published stuff as it would render further work impossible. Fast forward is the recognition that a stick-it-note can be moved linearly ahead. You won't be rewriting history, you will be writing new history and then forget about the old. But it is still there should accidents happen.
        dchest 15y ago
        Branches and tags are just "Stick-it-notes" you attach to the DAG. According to Git. And not if it's a tag object. You won't be rewriting history, you will be writing new history and then forget about the old. This is getting ridiculous. Next we'll be talking about parallel universes.
irahul 15y ago
Or `git checkout file.py` for that sake. git should really create a file.py.orig like hg does or provide some alternate way to undo an incorrect checkout/reset.

by dchest 15y ago

ollysb 15y ago

git reset --hard will only orphan commits, they're still there. git reflog will get you to them fast and I'm sure there's many other more exotic ways to find them. Admittedly garbage collection will remove them at some point but that's generally a lot further away than 'oops'.

dchest 15y ago
Working copy

j_baker 15y ago

You can't rewrite history in git either. You can however make new commits that are different from the old commits somehow. A branch in git is basically just a pointer to a set of immutable commits. http://hackerne.ws/item?id=2524993 http://hackerne.ws/item?id=2524993

dchest 15y ago
It depends on what you mean by "history". Moving refs around is already "modifying history" in Fossil world.
- j_baker 15y ago
  I don't care what Fossil considers rewriting history. Rewriting history means altering a commit that has taken place in the past, which git can't do.
  - dchest 15y ago
    What about branches? Tags? Git's fast-forward? Some people think of the whole DAG as history.
    - jlouis 15y ago
      Branches and tags are just "Stick-it-notes" you attach to the DAG. They can be removed around at whim, but they only serve to mark a point in the DAG for your convenience. The GC process will kill parts of the DAG with no such branch/tag, but it only happens after some days by default. Were git able to rewrite history, it couldn't use SHA1 checksums as names for the content. Note that a rebase alters the SHA1 stack you have, so it is regarded as something different. But you can't do that easily with published stuff as it would render further work impossible. Fast forward is the recognition that a stick-it-note can be moved linearly ahead. You won't be rewriting history, you will be writing new history and then forget about the old. But it is still there should accidents happen.
      - dchest 15y ago
        Branches and tags are just "Stick-it-notes" you attach to the DAG. According to Git. And not if it's a tag object. You won't be rewriting history, you will be writing new history and then forget about the old. This is getting ridiculous. Next we'll be talking about parallel universes.

irahul 15y ago

Or `git checkout file.py` for that sake. git should really create a file.py.orig like hg does or provide some alternate way to undo an incorrect checkout/reset.