working prototype of orphan parent commits as datastores (was: Storing additional information in commit headers)

From: martin f krafft <madduck@madduck.net>
Date: Aug 2, 2011, 15:03 UTC
Message-ID: <20110802150321.GA1390@fishbowl.rw.madduck.net>
In-Reply-To: <20110802082810.GC29887@fishbowl.rw.madduck.net>

also sprach martin f krafft <madduck@madduck.net> [2011.08.02.1028 +0200]:

Show 32 quoted lines

> What do you think about using the idea of orphan parent commits
> (OPC) for now? These are conceptually closest to the x-*-ref
> pointers, do not require extra setup, pollute history only a little
> bit (IMHO), and slot in with Git and fsck/gc alright.
> 
> Here's the idea again, graphically:
> 
>   o--o--o--●
>        /
>       #
> 
> while at HEAD, I would backtrack history until I found HEAD^, which
> has a parent with a well-defined commit message and holding the data
> I am looking for.
> 
> Later, when x-*-ref is mainline, instead of parent pointers, it can
> be used in place.
> 
> When there is a merge and the TopGit data need updating, a new
> OPC is slotted into place, on the merge commit. In
> the following graph, the user then decided also at a later point to
> update e.g. the TopGit patch description (.topmsg), which is also
> stored in this OPC:
> 
>        o--o-o
>       /      \      maint       master
>   o--o--o--o--+--o--O--o--o--o--●
>        /     /           /
>       #     #           #
> 
> To keep things simple, every OPC copies the unchanged data from the
> previous one as well (compression will reduce the overhead).

I have published a working prototype of this kind of datastore, in case people are interested:

  http://git.madduck.net/v/code/topgit-ng.git

Here's a bit of synopsis:

% ./tg-datastore list
I: returns non-zero if no datastore found at given commit.
I: prints contents of datastore otherwise.
message: this is a proof-of-concept

% ./tg-datastore find commitref
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
dc58ec49df849ec1aef6929cd40c759a6018e056

% git commit --allow-empty -mone [master 78918bb] one

% git commit --allow-empty -mtwo [master 7eca0cd] two

% ./tg-datastore find message
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
this is a proof-of-concept

% ./tg-datastore find commitref
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
dc58ec49df849ec1aef6929cd40c759a6018e056

% ./tg-datastore add message='this is a new message'
I: returns non-zero if there is already a datastore on HEAD.
I: adding the following data to the datastore of HEAD:
I:   message: this is a new message

% ./tg-datastore find commitref
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
8e6179050a1aca5485f3e1702780f1b555d8643b

% ./tg-datastore find message
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
this is a new message

  tig output now:
    2011-08-02 16:52 martin f. krafft   M─┐ [master] two
    2011-08-02 16:54 TopGit             │ I TopGit data node
    2011-08-02 16:52 martin f. krafft   I one
    2011-08-02 16:50 martin f. krafft   M─┐ [origin/master] import first prototype
    2011-08-02 16:50 TopGit             │ I TopGit data node
    2011-08-02 16:48 martin f. krafft   I Initial (empty) root commit

% ./tg-datastore remove
I: always returns zero, even if there was nothing to remove.

% ./tg-datastore find message
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
this is a proof-of-concept

Note three things:

  1. I am actually using a x-* header in the TopGit data node commit
     object to help identify it as a commit. This could be done
     differently (e.g. parse the commit message for some magic), but
     I chose to do this on purpose to see how well it fares.

  2. If Git grew x-*-ref headers (refs to objects in general),
     I could use that instead and drop the parent pointer, which
     would make the DAG cleaner.

  3. Right now, you cannot add parent orphan commits to orphans
     themselves, but it would be trivial to enable. I just couldn't
     be bothered.

Enjoy, and comments of course welcome.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
windoze nt crashed.
i am the blue screen of death.
no one hears your screams.
 
spamtraps: madduck.bogus@madduck.net