Re: [RFC] deprecating and eventually removing "git relink"?

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [RFC] deprecating and eventually removing "git relink"?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:52:28

Jeff King [off-list ref] writes:
On Mon, Nov 14, 2011 at 12:18:25PM -0800, Junio C Hamano wrote:
quoted
quoted
Yes, I think that is sensible. I'm not sure there is even any core git
code to be written. I think a wrapper that does the following would
probably work:
I agree with your outline, which I find is in line with what I had in mind
in the message Miles responded.

The approach is different from what Miles alluded to, which is to have
"clients" create objects in the "central" place in the first place,
though.
It seems to me that is simply an optimization that can come later.
I did not mean "it is wrong because it does not match what Miles said" by
that. In fact, I think it is a better approach to put things in clients
first and consolidating possible duplicates at the central one purely as
optimization, and I do not necessarily see "write to central from the
beginning" as a particularly good "optimization".

Re: [RFC] deprecating and eventually removing "git relink"?

From: Miles Bader <hidden>
Date: 2016-06-15 22:52:28

Junio C Hamano [off-list ref] writes:
I did not mean "it is wrong because it does not match what Miles said"
by that. In fact, I think it is a better approach to put things in
clients first and consolidating possible duplicates at the central one
purely as optimization, and I do not necessarily see "write to central
from the beginning" as a particularly good "optimization".
FWIW, this seems reasonable to me...

-Miles

-- 
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help