Re: Does content provenance matter?

Kelly Dean [off-list ref] writes:

[copying B/X over to C/X is not recorded as such], on the theory that
just content, not provenance, is what matters.

[merging branches *is* recorded], on the theory that not only content,
but also provenance, matters.

The basic question is, if provenance doesn't matter, then why does a
git commit record its parent(s)? Why not omit this information, and
figure it out at search time (by looking at all commits with older
timestamps), the same as you're supposed to figure out renames at
search time and figure out the movement of lines within/among files at
search time (by looking at all files in the parent commit(s))?

What's the difference between the following series of commits?

  Foo
  Bar
  Revert Bar

and

  Foo

You claim that they're the same, because the tree state after each is
the same.  But I learned that Bar was broken, and recorded it for all to
see.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

--- On Mon, 5/7/12, Thomas Rast <trast@student.ethz.ch> wrote:

What's the difference between the following series of
commits?

  Foo
  Bar
  Revert Bar

and

  Foo

You claim that they're the same, because the tree state
after each is
the same.  But I learned that Bar was broken, and
recorded it for all to see.

No, I don't claim they're the same. Different commits have different timestamps (and different commit messages, but that's not useful for automatic searching to find which commits are derived from which others). Consider if "Revert Bar" and "Bar" didn't point to their parents; could you still deduce from them that Bar was broken? Yes--on the basis of the commit timestamps (which shows their temporal order) and the contents of the trees which the commits point to (which shows that Revert Bar undoes a change made in Bar).

On Mon, May 7, 2012 at 2:43 PM, Kelly Dean [off-list ref] wrote:

But there could be any number of unrelated commits newer than "Bar"
but older than "Revert Bar" on other branches.  Even if you could
trust the timestamps to be accurate (you can't), you still can't
determine a commit's parent unambiguously.

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

--- On Mon, 5/7/12, PJ Weisberg <pj@irregularexpressions.net> wrote:

But there could be any number of unrelated commits newer than "Bar"
but older than "Revert Bar" on other branches.  Even if you could
trust the timestamps to be accurate (you can't), you still can't
determine a commit's parent unambiguously.

Therefore, provenance does matter, and it must be explicitly recorded because it can't necessarily be correctly and fully deduced from content alone. And git does record inter-commit provenance.
However, git doesn't record intra-commit provenance, as I mentioned in my original message. My question is: why this discrepancy? Either provenance matters, or it doesn't; why record it in one case but not the other?

On 8 May 2012 09:13, Kelly Dean [off-list ref] wrote:

I don't think it is firmly decided that provenance is not important in
the intra-commit scope, rather that as you stated such information is
not available to us.

My understanding is that git makes a best guess effort to track the
flow of content through the repository. If the content is moved, by
deleting in one place and adding in another it is easy to see that in
git, however if content is merely added, and that same content occurs
in multiple places in the repository, there is no sane way of knowing
where that content came from.
Even if the content that was added only occurred in one other place,
you would need to check every single file for every single hunk added
every single commit in order to be able to determine just where this
content came from. Why stop there though? It's possible we are copying
the content from some other branch we don't have checked out at the
moment, so every time we commit, let's search the entire repositories
history for an occurrence of each hunk we are adding. This way is
madness.

With regards to file renames, all that has been shown so far is that
provenance matters for commit renames. Nothing about the similarities
between the commit parent and rename situations you mention leads me
to concluded that because provenance is important to one it is
important to the other.

Indeed, one of the arguments against provenance being important in the
file rename case is that generally we can determine this information
from the existing information, as opposed to the general commit parent
case. There are additional arguments, such as simply recording file
name changes doesn't capture many situations we would like to know
about, for example when a single file is split into two files.
Tracking the content of those files, and hence being able to deduce
where their content came from, solves this and the general rename
situation. Trying to guess which file was 'renamed' and which is 'new'
when a file is actually split into two new files would lead to
misleading and incomplete information in the end.

So just because provenance matters in some situations doesn't mean it
matters in all (at least in the way we have been applying 'matters'),
furthermore there are additional reasons why the existing
content-tracking system is beneficial. Extra layers of rename encoding
or the 'heritage of data chunks' would be extra work with little added
benefit (though there are a few corner cases, from memory, where
automatic rename detection fails and so /some/ benefit would be seen).

Regards,

Andrew Ardill

From: "Kelly Dean" <redacted> Sent: Tuesday, May 08, 2012 12:13
AM

 Either provenance matters, or it doesn't;

The logic error is here. There are many other available choices as to
deciding the points at which the many provenance quality levels decay. (e.g.
see [1]).

People eventually give up caring at some level of detail/history, each in a
different place ;-) It's a choice. e.g. Have you noticed all high
performance cars (Porche?) need brightly coloured brake cylinders with
carefully specified paint jobs - why? At some point we give up caring how
someone got a few (how few?) characters into a file... It's not right, but
it's not wrong either.

I've worked with systems (e.g. DOORS) that record every keystroke, and
recored every hunk at the undo/redo level, but for little benefit.

Git takes the approach of having lightweight (easy) branching with easy
commits, with local history re-writing (rebase), to give users the ability
to balance between their WIP (work in progress), and their public record.
But with strong verification of any given history (e.g. "My Master"). It's a
choice as to who and where to blame.

    why record it in one case but not the other?

Philip
[1] Measuring and Managing Technological Knowledge,
IEEE Engineering Management Review Winter 1997 p77-88.
Reprinted from  Sloan Management Review, Fall 1994
http://sloanreview.mit.edu/the-magazine/1994-fall/3615/measuring-and-managing-technological-knowledge/