Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)

Linus Torvalds <torvalds@osdl.org> writes:

Actually, it does help Porcelain to be able to mark unrelated crud as 'note'. Sane people (including git barebone Porcelainish) would just ignore it. Unless --pretty=raw is used the 'note' headers will not be shown. It would unclutter things for us.

If different Porcelains use "the existing comment field" by defining certain mark-up to embed their own data, it has the same "weak semantics causing confusion down the line" issue, _and_ the crud will be shown to the end user by "git log".

So I am starting to be actually in favor of the 'note' header.

Earlier somebody wondered if that has impact on merge semantics. I think we do _not_ care. The core level does not track how things changed (the operation to make preimage to postimage), but tracks what the results of changes are (the content).

Some "misguided" set of Porcelains may come up with a convention to record renames and token-replaces in the 'note' header to say:

	tree 0000000000000000000000000000000000000000
        parent 0000000000000000000000000000000000000000
	author A U Thor <author@example.com> 000000000 +0000
	committer C O Mitter <comitter@example.com> 000000000 +0000
	note rename hello.c world.c
        note token-replace s/cache/index/

        Replaced old nomenclature 'cache' to 'index'.  Oh, while
        at it, I renamed hello.c to world.c.

But unlike systems that records the transformation from preimage to postimage, we record the postimage (on "tree" header) and preimage (by the way of "parent" header). We (as the core and Porcelain that do not use "note") do not even need to look at what 'note' says. The Porcelains that _do_ look at the note may try to take advantage of it, and if they make better result that would be a good thing. I suspect such 'note rename' provided by the end user is not trustworthy at times, so a Porcelain that relies on that may make silent mismerge. You may claim that is the reason why you do not want to pull from a tree managed with such a Porcelain.

But at the end of the day what matters is the content, and people.

You will not be using such a Porcelain yourself, but when you fetch the above commit, which records its tree and its parents, git barebone Porcelainish merge will just do what it has always done, without even looking at 'note'. It's not like use of 'note' on the other end is forcing you to take a note on them.

Refusing to merge from a tree that is managed with a Porcelain that uses the information in 'note rename' for its own operation (maybe because we believe such Porcelain tends to make silent mismerges more often) does not make much more sense than refusing to merge from a tree whose developer uses vi (because it tends to lose "missing LF at the end of file"). The content matters, so you would check the merge result; and 'note' thing is opt-in, which we opt out.

Also you ultimately trust people -- "I will pull from his tree, because I know he is careful and has good taste". Now the tool they use _may_ be part of their taste, but any tool can be misused (remember you stayed away from pulling things that have Octopus?)

I am less (a lot less) sure about the 'related' header now, which will be the topic of a separate message.