* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jason Riedy @ 2006-04-25 22:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e2lrk5$ed5$1@sea.gmane.org>
And Jakub Narebski writes:
- I don't mean we shouldn't define semantic for each use of "related" or
- "note" header. Just like email X-* headres have detailed form and semantic
- (long, long time ago Sender was X-Sender for example ;-). It's just a
- toolkit.
You just proved Linus's point. Ever have to parse
archives of old mail? There are many different ways
of saying the same thing, and many of the same way
of saying different things. It's pure hell.
And people expect you to get the X-* headers correct
for whatever definition of correct they happen to have
at the moment. ugh. You have many de-facto semantics
for the same headers, and no way to disambiguate them.
People will need to parse and understand git archives
thirty+ years from now. Don't place this curse on
them.
Jason
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodypv3gz.fsf@assigned-by-dhcp.cox.net>
On Tue, 25 Apr 2006, Junio C Hamano wrote:
> >
> > Sure it does. It's an integral part of logging: we not only verify the
> > format, we also have multiple different ways of showing it. So it
> > definitely changes the way we "act", very fundamentally.
>
> Unfair ;-). I'd consider "git log" semi-Porcelain and consider
> rev-list and cat-file the true core level.
Well, "git log" is really just "git-rev-list --pretty", so whichever way
you turn, it's there.
I come from a slightly different background, where "core git" in many ways
originally was about "what I use" and the whole "porcelain" side ends up
being "what people who need hand-holding use" ;)
Of course, it expanded a bit from that original definition ;)
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Junio C Hamano @ 2006-04-25 19:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604251233340.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 25 Apr 2006, Junio C Hamano wrote:
>>
>> Then we should drop the author header and make it part of free
>> form text. The core does not give any meaning to it.
>
> Sure it does. It's an integral part of logging: we not only verify the
> format, we also have multiple different ways of showing it. So it
> definitely changes the way we "act", very fundamentally.
Unfair ;-). I'd consider "git log" semi-Porcelain and consider
rev-list and cat-file the true core level.
But you already made it clear that you are not opposed to 'note'
with a clear semantics "we _ignore_ it", the point was moot.
Sorry for the noise.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 19:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslo1v4zw.fsf@assigned-by-dhcp.cox.net>
On Tue, 25 Apr 2006, Junio C Hamano wrote:
>
> Then we should drop the author header and make it part of free
> form text. The core does not give any meaning to it.
Sure it does. It's an integral part of logging: we not only verify the
format, we also have multiple different ways of showing it. So it
definitely changes the way we "act", very fundamentally.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Junio C Hamano @ 2006-04-25 19:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604251155530.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And the rule is: git cares about the commit header, but not about the
> free-form. Which means that anything it doesn't care about, it goes into
> the free-form section, not into some "X-header" section.
>
> Whatever you build on TOP of git can have its own rules in that free-form
> section. For example, the kernel project has this "X-header" thing called
> the "sign-off", and git itself picked it up. There's even some support to
> add it automatically to commits (the same way we add the "revert" info
> automatically to commits), but nobody claims that git should "parse" that
> information, or that it should be part of the "header".
Then we should drop the author header and make it part of free
form text. The core does not give any meaning to it. And the
name <email> part of the commit header as well. The only thing
used by the core is the timestamp of the commit.
My initial 'related' without 'note' was flawed - it used
cherry-pick as an example of 'related' when it clearly should
have been 'note' (no connectivitiy required).
Having said what I wanted to say about 'note', let's clarify
what I have in mind about the 'related' that _means_
connectivity. As I said, I am far less convinced it is a good
thing than I am about 'note' by now, but just for the sake of
completeness of the discussion.
I tend to agree with you that ability to misuse 'related' (I'd
call it 'link' to make it clear that it means connectivity) to
fetch/push "related" objects, with an unclear definition of
related-ness, is a bad thing. Even if we fetched the objects
that are claimed to be related to the main project, if we do not
know what to do with them, it is not useful.
And for well defined connectivity, we could give separate names,
just like we have 'tree' and 'parent' in the commit header.
That's how "bind commit" was initially proposed. It was not
'link bind'.
The suggestion of 'link bind' came primarily from the pain I
experienced when I taught rev-list --objects and fsck-objects
about it in the jc/bind branch. If the only thing asked to the
core by 'link' is to make sure the related objects are made
available, and Porcelains take responsibility after they are
made available, we would be better off teaching the commit
parser how to parse 'link' (regardless of its nature of linkage)
and teach rev-list --objects and fsck-objects to do connectivity
just once, rather than adding 'bind' now and then having to do
the same backward incompatible change when adding something else
that requires connectivity.
There definitely needs to be an ability to specify a list of
"nature of links this repository accepts", if we were to do
'link'. It probably should default to an empty set. rev-list
--objects would include objects pointed by 'link' only when the
repository wants such links to be honored. fsck-objects will
declare an object that is reachable only by a 'link' that is not
accepted by the repository "uninteresting" and let git-prune
remove it.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr73lwkdt.fsf@assigned-by-dhcp.cox.net>
On Tue, 25 Apr 2006, Junio C Hamano wrote:
>
> Actually, it does help Porcelain to be able to mark unrelated
> crud as 'note'.
A "note" header that explicitly has no meaning _what-so-ever_ for git
would be fine. Then the semantics are well-defined, and they really do
boil down to: random strings that git will ignore, and that won't normally
be shown by "git log".
Those are actually real semantics, the same way the current "content" is
real semantics: we don't care about it at all, and we _guarantee_ that we
don't care about it.
The problem with the proposed "related" thing was that it was somethign
that git was supposed to care about, but since it had no sane semantics,
there was no way to _make_ git care about it sanely. That was the problem.
So I'm not objecting to adding headers. I'm objecting to adding headers
that have insane or badly defined semantics where we might be asked to do
something for them and different versions of git migth do different
things.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jakub Narebski @ 2006-04-25 19:00 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604251151350.3701@g5.osdl.org>
Linus Torvalds wrote:
>
>
> On Tue, 25 Apr 2006, Jakub Narebski wrote:
>>
>> Additionally, in "related" links we require that object exist (core git),
>> regardless of detailed semantics.
And history browsers (gitk, qgit) can use it, drawing line, regardless of
semantics.
> And as I've now mentioned a hundred times, that's just unacceptable to me.
> No suggested use of this has actually been useful, that I can tell.
I don't mean we shouldn't define semantic for each use of "related" or
"note" header. Just like email X-* headres have detailed form and semantic
(long, long time ago Sender was X-Sender for example ;-). It's just a
toolkit.
As to suggested "related" (requiring object to exists) headers: "bind",
"prior", and perhaps "revert".
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Junio C Hamano @ 2006-04-25 19:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604251125010.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 25 Apr 2006, sean wrote:
>
>> On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)
>> Linus Torvalds <torvalds@osdl.org> 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@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.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 19:00 UTC (permalink / raw)
To: sean; +Cc: jnareb, git
In-Reply-To: <BAYC1-PASMTP03E0B5376ACFF165B29ED1AEBF0@CEZ.ICE>
On Tue, 25 Apr 2006, sean wrote:
>
> It's no different for a bug tracker or other 3rd party software that wants
> to interface with git, it's bad design to force them to parse a single
> free form text comment into individual pieces to extract their meta data.
> Especially when git could easily add the ability to add multple comments
> to each commit.
Git _does_ make that easy. It's called the "tree". It's where you add any
arbitrary files to a commit.
The point here is that core git should do one thing, and one thing only.
You can then build up any policy you want on top of that. But in order for
core git to be stable, it has to have nice rules about what it cares
about, and what it does not.
And the rule is: git cares about the commit header, but not about the
free-form. Which means that anything it doesn't care about, it goes into
the free-form section, not into some "X-header" section.
Whatever you build on TOP of git can have its own rules in that free-form
section. For example, the kernel project has this "X-header" thing called
the "sign-off", and git itself picked it up. There's even some support to
add it automatically to commits (the same way we add the "revert" info
automatically to commits), but nobody claims that git should "parse" that
information, or that it should be part of the "header".
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 18:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e2lqf1$a5k$1@sea.gmane.org>
On Tue, 25 Apr 2006, Jakub Narebski wrote:
>
> Additionally, in "related" links we require that object exist (core git),
> regardless of detailed semantics.
And as I've now mentioned a hundred times, that's just unacceptable to me.
No suggested use of this has actually been useful, that I can tell.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: sean @ 2006-04-25 18:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jnareb, git
In-Reply-To: <Pine.LNX.4.64.0604251125010.3701@g5.osdl.org>
On Tue, 25 Apr 2006 11:26:25 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> 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.
Take your example of how git-revert works today, it copies the comment from
the original, thus keeping this semantic-free meta-data intact between
related commits. However, you'd have to jump through hoops to accomplish
this same simple task with any third party meta data, unless it was
burried inside the commit message text.
> So why argue for it?
>
> Just use the existing comment field.
The last argument you and I had was me taking the other side, saying that
it was fine for git to parse the free form text area to extract information;
you rightfully showed me why that was wrong.
It's no different for a bug tracker or other 3rd party software that wants
to interface with git, it's bad design to force them to parse a single
free form text comment into individual pieces to extract their meta data.
Especially when git could easily add the ability to add multple comments
to each commit.
Sean
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jakub Narebski @ 2006-04-25 18:41 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604251125010.3701@g5.osdl.org>
Linus Torvalds wrote:
> So why argue for it?
>
> Just use the existing comment field.
For the same reason there exist X-* _header_ fields in email.
Additionally, in "related" links we require that object exist (core git),
regardless of detailed semantics.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jakub Narebski @ 2006-04-25 18:34 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP04D82622D9D5DA7E352079AEBF0@CEZ.ICE>
sean wrote:
> On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)
> Linus Torvalds <torvalds@osdl.org> 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
> [storing information in X-* like header] can help porcelain.
And [graphical] history browsers like gitk or qgit.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 18:26 UTC (permalink / raw)
To: sean; +Cc: jnareb, git
In-Reply-To: <BAYC1-PASMTP04D82622D9D5DA7E352079AEBF0@CEZ.ICE>
On Tue, 25 Apr 2006, sean wrote:
> On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)
> Linus Torvalds <torvalds@osdl.org> 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.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jakub Narebski @ 2006-04-25 18:24 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604251058490.3701@g5.osdl.org>
Linus Torvalds wrote:
> On Tue, 25 Apr 2006, Linus Torvalds wrote:
>>
>> The "track it with pull/push" thing is NOT one such thing, however much
>> you protest. We already _have_ that thing. It's called a "ref", and it's
>> really really easy to create anywhere in .git/refs/, and the tools
>> already know how to use it.
I agree(d) that tracking pull/push with extra commit header fields is not a
good example.
> Btw, there are other cases for that. For example, "parent" is a
> well-specified thing that actually has very clear and unambiguous meaning.
In single parent case, "parent" means that we modified tree pointed by the
parent. Multiple parent case suggests that we combined trees pointed by
parents, most probable by merge. I'd rather we not use parent for anything
else.
> And we had a much better proposals (in the sense that it had real
> suggested _meaning_ and semantics) over the last few months for things
> like sub-projects (trees that point to other commits)
Wasn't it commits pointing to other trees (or to commits)? "bind" field
proposal suggests it. And it could be implemented using 'X-*' "related"
headers in commit.
related a0e7d36193b96f552073558acf5fcc1f10528917 bind linux-2.6
vs. proposed
bind f6a8248420395bc9febd66194252fc9957b0052d linux/
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Rene Scharfe @ 2006-04-25 18:22 UTC (permalink / raw)
To: Geert Bosch; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20060424025741.GA636@adacore.com>
Geert Bosch schrieb:
> On Sat, Apr 22, 2006 at 02:36:04PM +0200, Rene Scharfe wrote:
>> You can use "indent -npro -kr -i8 -ts8 -l80 -ss -ncs" to reformat your
>> code into a similar style as used in the rest of git (settings taken
>> from Lindent which is shipped with the Linux source).
> Although I cringe at 8-space indenting, and find much of the GIT
> code close to unreadable for lack of design-level comments, I'll
> gladly reformat any code to conform to existing code standards.
> Please let me know if you've got documentation on that, as it would
> be helpful for me to know what the standard is. (No flame intended. :-)
I'm not aware of a document mandating a certain formatting. The output
of that indent call should come close to a "standard format", because
Linus followed this style from the beginning and Junio didn't go astray.
Don't worry too much about it. I just wanted to point out an easy way
to reformat your code to use sane indenting. :->
René
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: sean @ 2006-04-25 18:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jnareb, git
In-Reply-To: <Pine.LNX.4.64.0604251106400.3701@g5.osdl.org>
On Tue, 25 Apr 2006 11:08:31 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> 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.
> We do that already. Look at "git revert". Ooh. Aah. It works today.
Nice. Gotta love git.
> Just don't make it something that changes semantics, and that git parses
> and "understands". Because git clearly doesn't understand it at all, since
> you didn't define it to have any meaning that _can_ be understood.
But that's exactly the point, it's no different than extending git to be
able to store more than one comment. Comment1 Comment2 Comment3.
Pure content that git need not give any semantic meaning. Git has a
limitation of only a single comment today, there's no semantic damage
to extending git to allow multiple comments. And there are a few
applications, like bug tracking etc, which could use such a feature
to good effect.
Sean
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 18:08 UTC (permalink / raw)
To: sean; +Cc: jnareb, git
In-Reply-To: <BAYC1-PASMTP091348C4C33C5A0E83C012AEBF0@CEZ.ICE>
On Tue, 25 Apr 2006, sean wrote:
> On Tue, 25 Apr 2006 10:11:13 -0700 (PDT)
> Linus Torvalds <torvalds@osdl.org> wrote:
>
> > Once you start adding data that has no clear semantics, you're screwed. At
> > that point, it's a "track guesses" game, not a "track contents" game.
>
> Then shouldn't Git stop tracking commit comments; they're just developer
> guesses. ;o)
No, they are pure content, and git doesn't actually give them any semantic
meaning.
WHICH IS OK. I even suggested that you put this thing into that "pure
content" part.
> Adding a free-form header is no different than adding a few more lines
> of free form text at the bottom of the commit message, in neither case
> does it change the nice clean git semantics.
Which is exactly what I told you to do. Just don't make it a git header.
We do that already. Look at "git revert". Ooh. Aah. It works today.
Just don't make it something that changes semantics, and that git parses
and "understands". Because git clearly doesn't understand it at all, since
you didn't define it to have any meaning that _can_ be understood.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 18:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604251053100.3701@g5.osdl.org>
On Tue, 25 Apr 2006, Linus Torvalds wrote:
>
> The "track it with pull/push" thing is NOT one such thing, however much
> you protest. We already _have_ that thing. It's called a "ref", and it's
> really really easy to create anywhere in .git/refs/, and the tools already
> know how to use it.
Btw, there are other cases for that. For example, "parent" is a
well-specified thing that actually has very clear and unambiguous meaning.
And we had a much better proposals (in the sense that it had real
suggested _meaning_ and semantics) over the last few months for things
like sub-projects (trees that point to other commits) or last year a
discussion about "container objects" (like the current tags, but listing
multiple objects instead of just one).
All of which had clear and unambiguous semantics (but were not done for
other reasons - maybe the sub-project still remains on the horizon, the
"container objects" thing doesn't seem to have gone anywhere).
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 17:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e2lmm3$rts$1@sea.gmane.org>
On Tue, 25 Apr 2006, Jakub Narebski wrote:
>
> Erm, further on we did agree
Hell no "we" didn't.
Since I totally refuse to touch anything like that.
I even told you exactly why, for things like the suggested "cherry-pick"
thing.
Which still remains the "best" example. And I say "best", because as an
example it totally sucks. Again, for reasons I made very clear.
The fact is, there is _zero_ reason for this field to exist. Nobody has
actually mentioned a single use that is really valid and that people can
agree on across different uses.
So here's the challenge: name _one_ thing that people actually can agree
on, and that adds real measurable _value_ from a core git standpoint.
Something where the semantics actually change what git does.
The "track it with pull/push" thing is NOT one such thing, however much
you protest. We already _have_ that thing. It's called a "ref", and it's
really really easy to create anywhere in .git/refs/, and the tools already
know how to use it.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: sean @ 2006-04-25 17:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jnareb, git
In-Reply-To: <Pine.LNX.4.64.0604251004410.3701@g5.osdl.org>
On Tue, 25 Apr 2006 10:11:13 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> Once you start adding data that has no clear semantics, you're screwed. At
> that point, it's a "track guesses" game, not a "track contents" game.
Then shouldn't Git stop tracking commit comments; they're just developer
guesses. ;o) Adding a free-form header is no different than adding a
few more lines of free form text at the bottom of the commit message, in
neither case does it change the nice clean git semantics.
Sean
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jakub Narebski @ 2006-04-25 17:36 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604251004410.3701@g5.osdl.org>
Linus Torvalds wrote:
> On Tue, 25 Apr 2006, Jakub Narebski wrote:
>>
>> The generic commit links "related" which is fsck-able at least and "note"
>> which is not. It is idea somewhat on the level of providing _extended
>> attributes_ in VFS in Linux kernel, IMVHO.
>
> And nobody actually uses extended attributes either, do they?
Fedora's SELinux does use them, IIRC.
Well, people do use X-* headers in mail (sean's example), and some of them
got promoted from X-* to ordinary mail header status.
> Plus it's _not_ fsck'able, since the thing doesn't even have any valid
> semantics. You guys can't even agree on whether the object must exist or
> not.
Erm, further on we did agree
http://permalink.gmane.org/gmane.comp.version-control.git/19142
(Message-Id: <7vmzeax9gj.fsf@assigned-by-dhcp.cox.net>).
"related" links means that object must exist. "note" is what name says, just
note and doesn't even need to point to object.
> For exactly the same reason, git should not track it when a developer says
> "I think this commit is related to that commit". It's not hard data, that
> has hard and clear semantics.
>
> Once you start adding data that has no clear semantics, you're screwed. At
> that point, it's a "track guesses" game, not a "track contents" game.
Well, the best example, i.e. remembering cherry picking has well defined
semantic (added when cherry-picking, used when merging, object does need
not to exist) but not well defined form. Currently the convention for
free-form is used, which has its advantages and disadvantages as pointed
out by Junio.
[somewhat unrelated note]
> Git tracks contents, and the well-defined history of how those contents
> came to be. Git does NOT track "additional notes" left by the developer
> that have weak semantics. Git does not track when a developer says "I
> renamed a file".
But I'd like Git to remember when I corrected false positives in "rename"
detection during merge, and added undetected automatically renames/file
contents copying and/or moving. Whether it would be done by saving the
information in commit header, commit free-for, or somewhere else...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 17:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e2lijt$aco$1@sea.gmane.org>
On Tue, 25 Apr 2006, Jakub Narebski wrote:
>
> The generic commit links "related" which is fsck-able at least and "note"
> which is not. It is idea somewhat on the level of providing _extended
> attributes_ in VFS in Linux kernel, IMVHO.
And nobody actually uses extended attributes either, do they?
Plus it's _not_ fsck'able, since the thing doesn't even have any valid
semantics. You guys can't even agree on whether the object must exist or
not.
Anyway, I'm not interested. I'm violently opposed to the mess that is
darcs and other crapola. The WHOLE point of git is to have well-defined
semantics and get away from the horrors that other systems have done,
where they have allowed any random crap to "make sense".
If you want darcs-like semantics where there are no rules, just use darcs,
for chrissake! And if you want to base it on git because you've noticed
that git is (a) stable, (b) fast and (c) has developed remarkably well,
then think for a second _why_ git is stable, fast, and well-developed.
It's that exactly because it has clear semantics, and no room for random
crud.
Git tracks contents, and the well-defined history of how those contents
came to be. Git does NOT track "additional notes" left by the developer
that have weak semantics. Git does not track when a developer says "I
renamed a file".
For exactly the same reason, git should not track it when a developer says
"I think this commit is related to that commit". It's not hard data, that
has hard and clear semantics.
Once you start adding data that has no clear semantics, you're screwed. At
that point, it's a "track guesses" game, not a "track contents" game.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Linus Torvalds @ 2006-04-25 17:04 UTC (permalink / raw)
To: sean; +Cc: junkio, git, jnareb
In-Reply-To: <BAYC1-PASMTP086A906CFB378AB229C2D8AEBF0@CEZ.ICE>
On Tue, 25 Apr 2006, sean wrote:
>
> It's a fair point. But adding a separate database to augment the core
> information has some downsides. That is, that information isn't pulled,
> cloned, or pushed automatically; it doesn't get to ride for free on top
> of the core.
But the point is, we don't generally _want_ to pull, push, or clone this
crud.
I for one would literally have to add code to say "if any commit we poll
has this random field, I refuse to pull".
There's two ways to have true interoperability (and in a distributed
system, that's the thing that matters):
- keep on piling on the sh*t
- keep it simple so that people know exactly what the rules are.
Guess which one I am religiously in favour of.
That's my whole point: the "rules" for this suggested "prior" or "related"
field simply don't exist, and it doesn't even seem to be the case that
people can agree what it _means_ in that nobody has actually explained
what the thing would do and why you would use it.
If you cannot explain to the other side what a field is used for, then
that field - by definition - is not useful for the other side. It will
just result in confusion, because different users will have different
notions of what to do with the field (if anything).
So some users might consider it to have meaning, and actually do different
things when it exists. Others would ignore it entirely. Yet thirds would
ignore it, but consider it a link that must exist - which would break
whenever those people would interact with the people who ignore it, and
think that it's superfluous.
This is why it has to have real meaning. If there are no rules, things
will break. Some things will pull them, others won't, yet third things
will do random things.
If you just want to have something that "follows" an archive, it's easy
enough to do: have a totally separate ref, that is a real branch, but may
not even contain any files at all. You can - perfectly validly - have a
chain of commits where all the information is in the "free-form" text area
as far as git is concerned, but where the trees are all empty.
You'll find that all git users can pull such a commit, and you can use all
the normal git ops on them, and you can hide your own metadata in there.
And it would still be a valid git tree - your metadata would be your
private thing, and you can keep it along-side the "normal" git data, and
you can have your own "extended fsck", and "git pull/push" still continues
to work.
Junio does something like that with the "todo" branch, for example (it's
human-readable, not automated, but that doesn't really change anything).
You can do
git ls-tree todo
git cat-file blob todo:Porcelainistas | less -S
and in general do anything you damn well please there. WITHOUT making
up any new (and unnecessary) format semantics that nobody else cares
about and that don't have very well-specified meaning.
Linus
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
From: Jakub Narebski @ 2006-04-25 16:27 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604250833540.3701@g5.osdl.org>
Linus Torvalds wrote:
> On Tue, 25 Apr 2006, Linus Torvalds wrote:
>>
>> I want the git objects to have clear and unambiguous semantics. I want
>> people to be able to explain exactly what the fields _mean_. No "this
>> random field could be used this random way" crud, please.
>
> Btw, if the whole point is a "leave random porcelain a field that they can
> use any way they want", then I say "Hell NO!".
The generic commit links "related" which is fsck-able at least and "note"
which is not. It is idea somewhat on the level of providing _extended
attributes_ in VFS in Linux kernel, IMVHO.
"note" can be considere cruft, "related" is fsck-able and pull-able so has
meaning for core (even if not all "note" and/or "related" links have any
repercussion for merging for example).
So far there are following core git ideas of using this feature (akin to
using extended attributes for ACL, or SELinux properties):
1. "related" link "bind" for better support of subprojects. Useful if some
parts of project are developed independently (e.g. lm_sensors or ALSA was
in Linux kernel, xdiff for git, somelibrary or somemodule for someproject
etc.).
2. "note" link "cherrypicked" for cherry-picking, rebase etc., for example
to not apply the same commit twice. Useful in merging after cherry picking.
Additionally there are following less certain ideas
3. "prior" link in the sense of prior state of frequently rebased branch
like git's "pu" (case (1) in first post in this thread)
4. "depend" link for creating darc-esque dependency partial ordering of
commits (patches), for better merge perhaps
5. "note" link "rename" (or more generic "contents related") for remembering
renames/file moving, file splitting, contents moving and copying, including
correcting automatic "rename" detection at merge (i.e. remembering false
positives and false negatives). Useful in subsequent merges and information
commands (log, whatchanged, annotate/blame, diff).
6. "note" link "origin" to remember for where the commit was pulled.
Note that none of those are non-core Porcelain ideas.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox