Re: Feedback outside of the user survey

[Christian Jaeger <christian@jaeger.mine.nu>]

Richard Hartmann wrote:
> On Thu, Oct 16, 2008 at 13:56, Garry Dolley <gdolley@arpnetworks.com> wrote:
>
>   
>> I know from an external point of view, it seems pulling a subdir
>> wouldn't be a big deal; but if you look at git internals, you start
>> to realize why it's an option that isn't on the table.
>>     

Hm, I don't see a fundamental technical problem which would prevent one 
from implementing the ability to checkout only a subdirectory into the 
working directory (i.e. to add options to Git to make it reflect the 
working directory as being a subdirectory of what is in Git's database). 
At this level I don't see anything inherently different from SVN--except 
maybe for directory renames: if someone else is renaming the directory 
you've checked out, what should happend with your checkout? Git's 
filebased rename tracking would just lead to everything vanishing from 
your checkout. I don't know what happens in SVN, maybe it keeps track of 
the directory rename and still sends you the changes of the directory 
you've checked out even if it has now a different name on the server?

Anyway, an unavoidable difference is that you have to always clone the 
whole Git *database*. With SVN the database stays on the server, with 
Git it is being cloned. Just as I expect SVN to need the whole database 
to be able to work (tracking renames across directories etc.), Git needs 
the whole database too. So implementing subdirectory workingdir 
checkouts wouldn't help reduce the bandwidth and storage necessary for 
getting at the database.

>
> That's my understanding as well. And you can simply branch
> out a subdir when you want to work on it.
>   

I guess what you are referring to is

 $ git clone git://foo.com/bar.git
 $ cd bar
 $ rm -rf *
 $ git checkout somesubdir

Now you've got only somesubdir/ below bar/. This solves the rename 
problem insofar, as somesubdir will just be renamed if someone else 
commits a "git mv somesubdir somethingelse" and you pull that change. 
But there's also another caveat: "git status" will of course report the 
other files as deleted, which is an accident waiting to happen when you 
next run "git commit -a".

(In any case, this is just thinking louder than I deserve, as there's no 
code at all in Git written by me.)

Christian.