Hi everyone,
On Sat, Nov 05, 2016 at 12:04:08AM +0100, Christian Couder wrote:
> On Fri, Nov 4, 2016 at 10:19 PM, Josh Triplett wrote:
> > On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote:
> >>
> >> Couldn't a RefTree be used to store refs that point to the base
> >> commit, the t
Josh Triplett writes:
>> This would definitely need protocol extension when transferring
>> objects across repositories.
>
> It'd also need a repository format extension locally. Otherwise, if you
> ever touched that repository with an older git (or a tool built on an
> older libgit2 or JGit or
On Mon, Nov 07, 2016 at 04:42:04PM +0700, Duy Nguyen wrote:
> On Mon, Nov 7, 2016 at 8:18 AM, Josh Triplett wrote:
> > Once we have gitrefs, you have both alternatives: reachable (gitref) or
> > not reachable (gitlink).
> >
> > However, if you want some way to mark reachable objects as not
> > rea
On Mon, Nov 7, 2016 at 8:18 AM, Josh Triplett wrote:
> Once we have gitrefs, you have both alternatives: reachable (gitref) or
> not reachable (gitlink).
>
> However, if you want some way to mark reachable objects as not
> reachable, such as for a sparse checkout, external large-object storage,
>
On Sun, Nov 6, 2016 at 5:18 PM, Josh Triplett wrote:
> Once we have gitrefs, you have both alternatives: reachable (gitref) or
> not reachable (gitlink).
>
> However, if you want some way to mark reachable objects as not
> reachable, such as for a sparse checkout, external large-object storage,
>
On Sun, Nov 06, 2016 at 12:17:10PM -0800, Jacob Keller wrote:
> On Sun, Nov 6, 2016 at 9:33 AM, Josh Triplett wrote:
> > On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote:
> >> Josh Triplett writes:
> >> > We could, but if we (or one of the many third-party git implementations)
> >>
On Sun, Nov 6, 2016 at 9:33 AM, Josh Triplett wrote:
> On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote:
>> Josh Triplett writes:
>> > We could, but if we (or one of the many third-party git implementations)
>> > miss a case, gitlinks+reachability may appear to work in many cases wi
On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote:
> Josh Triplett writes:
> > We could, but if we (or one of the many third-party git implementations)
> > miss a case, gitlinks+reachability may appear to work in many cases with
> > dataloss afterward, while gitrefs will fail early an
Josh Triplett writes:
> We could, but if we (or one of the many third-party git implementations)
> miss a case, gitlinks+reachability may appear to work in many cases with
> dataloss afterward, while gitrefs will fail early and not appear
> functional.
I wonder what happens if we do not introduc
On Sat, Nov 05, 2016 at 09:50:07PM -0700, Jacob Keller wrote:
> On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett wrote:
> > On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote:
> >> On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett
> >> wrote:
> >> > On Sat, Nov 05, 2016 at 01:45:27PM +010
On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett wrote:
> On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote:
>> On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett wrote:
>> > On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:
>> >> And with what Peff says above it looks like
On Fri, Nov 4, 2016 at 10:19 PM, Josh Triplett wrote:
> On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote:
>> On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano wrote:
>> >
>> > Imagine we invent a new tree entry type, "gitref", that is similar
>> > to "gitlink" in that it can record a
On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote:
> On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett wrote:
> > On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:
> >> And with what Peff says above it looks like we will need ways
> >> configure and tweak commit reachabi
On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett wrote:
> On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:
>> And with what Peff says above it looks like we will need ways
>> configure and tweak commit reachability with gitlink/gitref anyway. So
>> the point of gitref compared to git
On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:
> And with what Peff says above it looks like we will need ways
> configure and tweak commit reachability with gitlink/gitref anyway. So
> the point of gitref compared to gitlink would be that they just have a
> different reachabilit
On Sat, Nov 5, 2016 at 1:17 PM, Christian Couder
wrote:
> On Sat, Nov 5, 2016 at 5:42 AM, Junio C Hamano wrote:
>> Christian Couder writes:
>>
>>> Couldn't a RefTree be used to store refs that point to the base
>>> commit,
>>
>> I think it is the other way around. With the new "gitref" thing
>>
On Sat, Nov 5, 2016 at 5:42 AM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> Couldn't a RefTree be used to store refs that point to the base
>> commit,
>
> I think it is the other way around. With the new "gitref" thing
> that is a pointer to an in-repository commit, RefTree can be
> na
Junio C Hamano writes:
>> I think the main complication is that the reachability rules are used
>> during object transfer.
One should not type after spending 20+ waking hours on plane and
airport. I missed it when I wrote my first response, but yes, the
reachability that originates from inside
On Fri, Nov 04, 2016 at 09:41:06PM -0700, Junio C Hamano wrote:
> > I think the main complication is that the reachability rules are used
> > during object transfer. So you'd probably want to introduce some
> > protocol extension to say "I understand gitrefs", so that when one side
> > says "I hav
Christian Couder writes:
> Couldn't a RefTree be used to store refs that point to the base
> commit,
I think it is the other way around. With the new "gitref" thing
that is a pointer to an in-repository commit, RefTree can be
naturally implemented.
On Fri, Nov 04, 2016 at 09:55:23PM -0600, Josh Triplett wrote:
> >> Is it possible currently for a protocol extension to result in "oh
> >the
> >> server doesn't support this so I'm going to stop pushing"?
> >
> >Yes, it would be easy for the client to abort if the server fails to
> >advertise a p
Jeff King writes:
> On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote:
>
>> I agree with your assessment here. The main difficulty in implementing
>> gitrefs is to ensure that they actually do get picked up by
>> reachability checks to prevent dropping commits. I'm not sure how easy
>>
On November 4, 2016 7:48:17 PM MDT, Jeff King wrote:
>On Fri, Nov 04, 2016 at 04:34:34PM -0700, Jacob Keller wrote:
>
>> > You might also want fallback rules for storing gitrefs on "old"
>servers
>> > (e.g., backfilling gitrefs you need if the server didn't them in
>the
>> > initial fetch). But I
On Fri, Nov 04, 2016 at 04:34:34PM -0700, Jacob Keller wrote:
> > You might also want fallback rules for storing gitrefs on "old" servers
> > (e.g., backfilling gitrefs you need if the server didn't them in the
> > initial fetch). But I guess storing any gitrefs on such a server is
> > inherently
On Fri, Nov 04, 2016 at 04:37:34PM -0700, Jacob Keller wrote:
> On Fri, Nov 4, 2016 at 2:55 PM, Josh Triplett wrote:
> > That said, I'd *love* to have gitrefs available, for a wide variety of
> > applications, and I can see an argument for introducing them and waiting
> > a few years for them to b
On Fri, Nov 4, 2016 at 2:55 PM, Josh Triplett wrote:
> That said, I'd *love* to have gitrefs available, for a wide variety of
> applications, and I can see an argument for introducing them and waiting
> a few years for them to become universally available, similar to the
> process gitlinks went th
On Fri, Nov 4, 2016 at 12:49 PM, Jeff King wrote:
> I think the main complication is that the reachability rules are used
> during object transfer. So you'd probably want to introduce some
> protocol extension to say "I understand gitrefs", so that when one side
> says "I have sha1 X and its reach
On Fri, Nov 4, 2016 at 10:19 PM, Josh Triplett wrote:
> On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote:
>> On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano wrote:
>> >
>> > Imagine we invent a new tree entry type, "gitref", that is similar
>> > to "gitlink" in that it can record a
On Fri, Nov 04, 2016 at 03:49:07PM -0400, Jeff King wrote:
> On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote:
>
> > I agree with your assessment here. The main difficulty in implementing
> > gitrefs is to ensure that they actually do get picked up by
> > reachability checks to prevent
On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote:
> On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano wrote:
> >
> > Imagine we invent a new tree entry type, "gitref", that is similar
> > to "gitlink" in that it can record a commit object name in a tree,
> > but unlike "gitlink" it do
On Fri, Nov 04, 2016 at 10:57:09AM -0700, Junio C Hamano wrote:
> After your talk at LPC2016, I was thinking about your proposal to
> give an option to hide certain parents from "git log" traversal.
>
> While I do not think we would terribly mind a new feature in the
> core to support third-party
On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote:
> I agree with your assessment here. The main difficulty in implementing
> gitrefs is to ensure that they actually do get picked up by
> reachability checks to prevent dropping commits. I'm not sure how easy
> this is, but I would much
On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano wrote:
>
> Imagine we invent a new tree entry type, "gitref", that is similar
> to "gitlink" in that it can record a commit object name in a tree,
> but unlike "gitlink" it does imply reachability. And you do not add
> phony parents to your commit ob
On Fri, Nov 4, 2016 at 10:57 AM, Junio C Hamano wrote:
> I think this is backwards. The root cause of the issue you have
> with "gitk" is because you added something that is *NOT* a parent to
> your commit. We shouldn't have to add a mechanism to filter
> something that shouldn't have been added
After your talk at LPC2016, I was thinking about your proposal to
give an option to hide certain parents from "git log" traversal.
While I do not think we would terribly mind a new feature in the
core to support third-party additions like "git series" better, I
think this particular one is a big m
35 matches
Mail list logo
