Re: updating only changed files source directory?

[Shawn Pearce <spearce@spearce.org>]

Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> For a VCS, this is slightly nonstandard use, as we don't do any work
> in the working dir, we just compile from it, but have many working
> directories.

Its not nonstandard use.  A lot of projects perform rolling builds
which trigger anytime there are changes; very active projects
would always be building and thus would always want to have the
VCS only update those files which actually changed, to minimize
the compile time.
 
> I have some questions and remarks
> 
> * Is there a command analogous to git-clone for updating a repository?
> Right now, I'm using a combination of

Yes, its called git-fetch and git-pull.  Which leads us to...
 
>   git-http-fetch -a <branch>  <url>
>   wget <url>/refs/head/<branch>    ## dump to <myrepo>/refs/head/<branch>
> 
> for all branches I want to know about.  I was looking for a command
> that would update the heads of all branches.

Why not use git-fetch?

Create a .git/remotes file named 'origin' and put in there the URL
you want to fetch from and the list of branches you want to download
and keep current.

Then downloading the changes to the build repository is as simple
as running `git-fetch` with no parameters (as it defaults to reading
the origin file).

> * How do I update a source directory?

Always keep the source directory on a branch that is not listed
in the .git/remotes/origin file.  This way the fetch will always
succeed without failure.

Then you can do after the fetch:

	git-reset --hard <committish>

and the source directory will be updated to <committish> (which
could just be a branch name of one of those branches you fetch,
or could be a full SHA1, or a tag, etc.).

The reset --hard process will only change the files that really have
to change.  This means it will run in linear time proportional to the
number of files needing to be updated; and only those files which are
different between the working directory and <committish> will have
new modification dates.  Therefore incremental rebuilds will work.
 
> * As far as I can see, there is no reason to have only one index in a
> git repository. Why isn't it possible to specify an alternate
> index-file with an option similar to --git-dir ?

The index is key to getting the fast update of the working directory.
You can change the index with the (rather undocuments) GIT_INDEX_FILE
environment variable.  I do this in a few tools I have written
around Git, but I don't do it very often.

-- 
Shawn.