Mercurial - what is "future auditing"?

Question

I was reading the docs. In the section about Mercurial's bookmarks system, I read this:

Bookmarks can be used as an alternative to NamedBranches for tracking multiple lines of development. Systems like Mercurial, CVS, and Subversion store their branch information as a permanent part of each commit. This is useful for future auditing of long-lived branches, as it’s always possible to identify which branch a commit was introduced on. Git, by contrast, has “branches” that are not stored in history, which is useful for working with numerous short-lived feature branches, but makes future auditing impossible.

I tried searching the web for "future auditing" pertaining to mercurial, but almost every article has the exact same text as quoted above, as if they all ganked this documentation from the same place.

What is this mysterious "future auditing" that is supposedly impossible in git?

Thank you.

It simply means that in the future you will be able to tell which branch a commit belonged to. This information is generally lost in Git once a branch moves away from that commit. — Reimer Behrends, Sep 10 '15 at 05:10

score 4 · Answer 1 · edited May 23 '17 at 12:32

4

This is the same audit than the one mentioned in "Deleting git branch looses audit":

Branches in git can be deleted or renamed at any time.

if the merge was not a fast-forward you will see that the commits were made to a branch that was later merged, but you won't know what the branch was originally called.

You can see it illustrated in More On Mercurial vs. Git (with Graphs!) (2011)

edited May 23 '17 at 12:32

Community

1
1

answered Sep 10 '15 at 05:31

VonC

1,262,500
529
4,410
5,250

FYI - the images in the link appear to not be showing up. Helpful answer, though. +1 – James M. Lay Sep 11 '15 at 00:44
@JamesM.Lay speaking of images, you can see one in my old answer http://stackoverflow.com/a/2850413/6309 – VonC Sep 11 '15 at 05:22

score 3 · Accepted Answer · edited Jun 20 '20 at 09:12

"Future auditing" is not a technical term, it's just another way of saying "for future reference", "for future analysis". That's why googling for mercurial future auditing won't give you that many useful results.

As a side note, in Git, you can achieve a readable history by using the --no-ff option on git merge, which prevents fast-forwarding a branch and forces the creation of a merge commit. That way, you will always have a visible branching in the history, making it easier to know in the context of which feature-branch a particular commit was designed. Popular workflows like Git Flow enforce the use of --no-ff for that reason.

The above image is from the Git Flow website. It show the impact of --no-ff on the history in the case where a fast-forward was possible but the user chose to force a merge commit.

score 2 · Answer 3 · answered Sep 10 '15 at 07:07

If you want some identifier associated with each commit your developers push, have them associate that identifier with each commit they push. Here, here's a commit-msg filter that pulls it out of the repo's config:

    sed -si "/^###audit identifer:.*###/d
         \$ s/.*\$/&\\n###audit identifier: $(printf %s `git config x-workdata.bugid`)###" "$1"

Put that in your commit-msg hook (pace syntax) and every commit records the x-workdata.bugid config item.

But, (a) there's no reason to demand the developers get that id recorded in that particular way, and (b) even less reason to demand that that id be the only branch name they use when working on this particular effort. If they try three different ways, what, they have to go back and rebase the best using a branch named with exactly the right id because there's some mandate that that's the only way to get that id recorded with a commit? It's ridiculous.

Mercurial - what is "future auditing"?

3 Answers3