From: martin f krafft <madduck@madduck.net>
Date: Tue, 02 Aug 2011 21:12:41 GMT
Subject: Re: per-ref data storage
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]:
> 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