Linus Torvalds <torvalds@xxxxxxxx> writes:
> On Tue, 25 Apr 2006, sean wrote:
>
>> On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)
>> Linus Torvalds <torvalds@xxxxxxxx> wrote:
>>
>> > Which is exactly what I told you to do. Just don't make it a git header.
>>
>> Well I just don't see how making it a header, or plopping it at the
>> end of a commit message makes an iota of difference to git, while it
>> can help porcelain.
>
> It can't help porcelain.
>
> If we have undefined or bad semantics for it, the only thing it can do is
> _hurt_ porcelain, because it will cause confusion down the line.
>
> Semantics for data objects are _the_ most important part of a SCM. Pretty
> much any project, in fact.
>
> And bad or weakly defined semantics will invariably cause problems later.
>
>> But that's exactly the point, it's no different than extending git to be
>> able to store more than one comment.
>
> So why argue for it?
>
> Just use the existing comment field.
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@xxxxxxxxxxx> 000000000 +0000
committer C O Mitter <comitter@xxxxxxxxxxx> 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.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html