Re: per-ref data storage
- From
- martin f krafft <madduck@madduck.net>
- Date
- Aug 2, 2011, 21:12 UTC
- Message-ID
- <20110802211241.GA29029@fishbowl.rw.madduck.net>
- In-Reply-To
- <20110802192727.GB20239@fishbowl.rw.madduck.net>
also sprach martin f krafft <madduck@madduck.net> [2011.08.02.2127 +0200]:
Show 6 quoted lines
> 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? > > Of course this opens a whole new can of worms: merging per-ref data.
origin/master can contain a different set of per-ref data than master, and the consolidation would need to happen during the normal merge.
But unless there's always a new commit associated with a change of those data, git-push will happily overwrite those data on the remote.
… unless the remote refuses to accept a ref update if the data have changed. Conceivably that's could lead into a control path similar to what happens on a non-fast-forward push — unless receive.nonFastForwards is on.
What then?
-- martin | http://madduck.net/ | http://two.sentenc.es/ seminars, n.: from "semi" and "arse", hence, any half-assed discussion. spamtraps: madduck.bogus@madduck.net