[PATCH 00/11] Build in clone

[PATCH 00/11] Build in clone

[Daniel Barkalow]

This series is getting closer to being ready, and I think a number of
the initial patches are ready. In particular, 1-3 are tests that work
unexceptionally with the current implementation, and point out
potential bugs in a C version (which I've fixed); 4-7 are changes and
additions that should be pretty uncontraversial, which later code will
need; 8 is a potentially more contraversial library feature.

9 gives API access to init-db, and may or may not be ready, although I
think it looks promising now; 10 builds in clone and probably needs
more work; and 11 adds support for figuring out what the user means
with a bundle and should probably get squashed into 10.

(Unrelated note: it might actually be good to use some sort of log
instead of shortlog in --cover-letter, at least as an option, in order
to list the contents of the series with the patch numbers and order
they have)

Daniel Barkalow (8):
      Test that --reference actually suppresses fetching referenced objects
      Mark the list of refs to fetch as const
      Add a library function to add an alternate to the alternates file
      Add a function to set a non-default work tree
      Have a constant extern refspec for "--tags"
      Allow for having for_each_ref() list some refs that aren't local
      Provide API access to init_db()
      Build in clone

Johan Herland (2):
      Add test for cloning with "--reference" repo being a subset of source repo
      Add a test for another combination of --reference

Johannes Schindelin (1):
      Support bundles in builtin-clone

 Makefile                      |    2 +-
 builtin-clone.c               |  553 +++++++++++++++++++++++++++++++++++++++++
 builtin-fetch.c               |   10 +-
 builtin-init-db.c             |  183 +++++++-------
 builtin.h                     |    1 +
 cache.h                       |    6 +
 contrib/examples/git-clone.sh |  518 ++++++++++++++++++++++++++++++++++++++
 environment.c                 |    6 +
 git-clone.sh                  |  518 --------------------------------------
 git.c                         |    1 +
 refs.c                        |   18 ++
 refs.h                        |    9 +
 remote.c                      |    9 +
 remote.h                      |    2 +
 sha1_file.c                   |   19 ++
 t/t5700-clone-reference.sh    |   35 +++-
 transport.c                   |   16 +-
 transport.h                   |    4 +-
 18 files changed, 1283 insertions(+), 627 deletions(-)
 create mode 100644 builtin-clone.c
 create mode 100755 contrib/examples/git-clone.sh
 delete mode 100755 git-clone.sh

Re: [PATCH 00/11] Build in clone

[Johannes Schindelin]

Hi,

On Sat, 8 Mar 2008, Daniel Barkalow wrote:

> and 11 adds support for figuring out what the user means with a bundle 
> and should probably get squashed into 10.

Yes, it should be squashed into 10, methinks.


>  contrib/examples/git-clone.sh |  518 ++++++++++++++++++++++++++++++++++++++
>  git-clone.sh                  |  518 --------------------------------------

I thought I squashed that bug?

Ciao,
Dscho

Re: [PATCH 00/11] Build in clone

[Daniel Barkalow]

On Sun, 9 Mar 2008, Johannes Schindelin wrote:

> Hi,
> 
> On Sat, 8 Mar 2008, Daniel Barkalow wrote:
> 
> > and 11 adds support for figuring out what the user means with a bundle 
> > and should probably get squashed into 10.
> 
> Yes, it should be squashed into 10, methinks.
> 
> 
> >  contrib/examples/git-clone.sh |  518 ++++++++++++++++++++++++++++++++++++++
> >  git-clone.sh                  |  518 --------------------------------------
> 
> I thought I squashed that bug?

I haven't updated my installed version, and didn't notice until I'd 
written the blurb.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 00/11] Build in clone

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> (Unrelated note: it might actually be good to use some sort of log
> instead of shortlog in --cover-letter, at least as an option, in order
> to list the contents of the series with the patch numbers and order
> they have)

Certainly, I think that is a good idea.