On Tue, Oct 23, 2012 at 03:06:59PM -0700, Marc Gauthier wrote:
> Can a later commit be eventually be made to reference some set
> of notes added so far, so they become part of the whole history
> signed by the HEAD SHA1? hence pulled/pushed automatically as
> well. Otherwise do you not end up with a forever growing separate
> tree of notes that loses some of the properties of being behind
> the head SHA1 (and perhaps less scalable in manageability)?
> Also that way notes are separate only temporarily.
Interesting idea. It would be tough to do with existing objects. There
are really only two ways for a commit to reference objects:
1. Via a parent header. But we would not want to include the notes
tree as a separate parent. The semantics are all wrong, and would
make your commit look like a nonsense merge.
2. As an entry in a tree. But we do not enforce connectivity of
commits referenced in trees, because that is the way that
submodules are implemented.
So I think we would have to add a new header that says "also, here are
some notes for my history". That has two problems:
1. It's not backwards compatible. People with the new version of git
will expect to have objects referenced by the new header, but older
servers may not provide those objects (and vice versa). We can add
a protocol extension to communicate this, but fundamentally you are
going to lose the object connection any time it passes through a
repo running an older git.
2. It's impure from the perspective of git's data model. Adding in the
notes reference is not really a property of the commit. It's more
like saying "Oh, these other things happened to _past_ commits, and
I'm just now mentioning them". So you pick an arbitrary commit to
attach it to. What are the semantics with relation to that commit's
position in the history graph? If I have a commit that is identical
but without the notes reference, it will have a different sha1. But
is it the same commit?
So it's a bit ugly. I think I'd rather build out the transfer
infrastructure to pass the notes references around more gracefully
without trying to shoehorn them into the commit graph.
> As for automating the inclusion of notes in the flow, can that
> be conditional on some pattern in the note, so that e.g. the
> Acked-by's get included and folded in automatically, whereas
> others do not, according to settings?
Yeah. You can store arbitrary data in notes (e.g., one of the existing
uses of notes is to record metadata on the patch emails that led to a
commit). Right now you typically separate it out by data type into
separate refs, and then you ask git log to show you particular ones (so
we see refs/notes/commits with "--notes", but you can do "--notes=foo"
to see refs/notes/foo, or even show multiple refs).
For the fold-on-rebase idea, I'd think you would want something similar,
like setting rebase.foldNotes to "foo" to say "refs/notes/foo contains
pseudo-headers that should be folded in like a signed-off-by".
-Peff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
