Re: New release?

From: Junio C Hamano <junkio@cox.net>
Date: Jun 6, 2006, 10:27 UTC
Message-ID: <7virnevath.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0606061019440.11478@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 11 quoted lines

> On Mon, 5 Jun 2006, Junio C Hamano wrote:
>
>>          - letting fetch-pack ask for an arbitrary commit object the
>>            user obtained out of band (Eric W Biederman) -- waiting for
>>            updated patch.  We would need a corresponding one-liner patch
>>            to upload-pack when we do this.
>> 
>> This can wait.
>
> I think that this could be an important step towards a sensible "shallow 
> clone"...

I did not say we are not interested in doing this ever. The "arbitrary commit" thing is easy but I do not think it is all that important to hold all the good stuff back that happened since 1.3.0 and delay 1.4.0.

Also, what you talk about the "lazy clone" is a lot more involved than what Eric wanted to have. It is _never_ shallow clones that normal users would want -- making it shallow to explicitly say certain operations break is a cop-out for implementors. What the users really want is to be in total control -- ranging from completely on-demand ala CVS and SVN to "down to this commit in the history I would want to be cached on the local machine so that I can go offline and still do useful things with the history", with new failure modes for history traversing commands to exit gracefully when offline. That _is_ the ideal but I know it won't be within reach anytime soon.

Show 7 quoted lines

>>          - using ~/.gitrc to give a fall-back default when
>>            $GIT_DIR/config does not have values.
>> 
>> I suspect this would be more involved than Pasky's initial
>> patch; but it can wait.
>
> I think that this is quite important for the aliases to be useful.

I am not saying this is unimportant. Again, however, it is not that important to hold other good stuff.