Hi,
Troy Benjegerdes:
> My argument for this (besides my personal bias), is that a *feature* of
> mercurial is that history is immutable, while git has the feature which
> allows rewriting history. (my opinion is that's more of a misfeature)
>
Git doesn't rewrite history; it merely allows you to point the branch
name referring to that history to some other history that's not a direct
descendant.
With Mercurial you'd have to somehow roll back the reflog to achieve that;
git keeps the previous history around, it's just hidden.
> >From a security audit point of view,
Auditing this is easy: you can tell the git archive (the one you'd have to
push to, in order to build your software) to not allow non-fast-forward
updates, either globally or (if you decide that playing games with
-experimental is OK but others are not) with a hook script.
NB: Which part of whose email stack did that >From escape escape from‽
I've last needed to do that sometime in the early paleolithic …
> I would much rather have a clear immutable
> history of the archive, which I can get with a bunch of tar.xz files.
plus their SHA* hashes
> I think
> I can get a good audit trail from mercurial, but git starts to make me nervous
> about auditing, especially because I do not like the idea of referring to
> everything by hash, and I'd rather have something clear like Mercurial's
> revlog[1][2] format.
Well, that hash is just a number which unambiguously refers to one place in
the project history. Of course, you need the actual file contents to make
sense of the hash. So, you might consider a Mercurial reflog to be roughly
the same thing as a git hash _plus_ the pack file you get from "git repack
-A -d"ing the repository containing that commit.
--
-- Matthias Urlichs
Attachment:
signature.asc
Description: Digital signature