Re: per-ref data storage (was: Storing additional information in commit headers)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 02, 2011 at 09:27:28PM +0200, martin f krafft wrote:

> [sorry, my previous message was a total reply FAIL]
> 
> also sprach martin f krafft <madduck@xxxxxxxxxxx> [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
--
To unsubscribe from this list: 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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]