Re: per-ref data storage (was: Storing additional information in commit headers)
- From
Jeff King <peff@peff.net>
- Date
- Aug 4, 2011, 03:41 UTC
- Message-ID
- <20110804034114.GB4534@sigill.intra.peff.net>
- In-Reply-To
- <20110802192727.GB20239@fishbowl.rw.madduck.net>
On Tue, Aug 02, 2011 at 09:27:28PM +0200, martin f krafft wrote:
Show 10 quoted lines
> [sorry, my previous message was a total reply FAIL] > > also sprach martin f krafft <madduck@madduck.net> [2011.08.02.2106 +0200]: > > It just seems to me that per-ref storage is a lot further away than > > per-commit storage, and I'd really like to move forward with TopGit… > > refs/heads/master is a file, containing its payload in the first > line by format definition, right? > > I mean: the storage is right there, isn't it?
Yes, and I think git will even ignore other stuff in the file. But I don't think you can count on git not obliterating the other stuff when it updates the ref. Nor would it be passed over a clone or fetch.
> Of course this opens a whole new can of worms: merging per-ref data.
Yes. That's the tricky part. And that's something you'll have to deal with no matter how you store it, I expect.
-Peff