[PATCH 0/4] Build in some more things

[PATCH 0/4] Build in some more things

[Daniel Barkalow]

The main effect of this series is removing the fork/exec from pushing via 
the git protocol (aside from the later fork/exec in connect.c of course).

It also heads off some tempting transport-related fetch bugs, which I will 
not introduce in a later patch.

* Miscellaneous const changes and utilities
  Adds two small utility functions, and marks a bunch of stuff as const; 
  the const stuff is to keep builtin-fetch from getting messed up without 
  a warning, because it wants some lists not to change.

* Build-in peek-remote, using transport infrastructure.
* Build-in send-pack, with an API for other programs to call.
* Use built-in send-pack.

 Makefile                               |    4 ++-
 builtin-fetch.c                        |   10 +++---
 peek-remote.c => builtin-peek-remote.c |   55 +++++++++++++---------------
 send-pack.c => builtin-send-pack.c     |   46 ++++++++++++++++--------
 builtin.h                              |    2 +
 cache.h                                |    2 +-
 connect.c                              |   10 +++++-
 git.c                                  |    2 +
 http-push.c                            |    2 +-
 remote.c                               |   32 +++++++++++-----
 remote.h                               |   10 ++++--
 send-pack.h                            |   18 +++++++++
 transport.c                            |   63 +++++++++-----------------------
 transport.h                            |    6 ++--
 14 files changed, 146 insertions(+), 116 deletions(-)

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 0/4] Build in some more things

[Johannes Sixt]

Daniel Barkalow schrieb:
> The main effect of this series is removing the fork/exec from pushing via 
> the git protocol (aside from the later fork/exec in connect.c of course).
> 
> It also heads off some tempting transport-related fetch bugs, which I will 
> not introduce in a later patch.
> 
> * Miscellaneous const changes and utilities
>   Adds two small utility functions, and marks a bunch of stuff as const; 
>   the const stuff is to keep builtin-fetch from getting messed up without 
>   a warning, because it wants some lists not to change.
> 
> * Build-in peek-remote, using transport infrastructure.
> * Build-in send-pack, with an API for other programs to call.
> * Use built-in send-pack.

I assume this goes on top of current master or db/fetch-pack. The patches 
have some conflicts with js/forkexec (nothing serious, though). Maybe it 
makes sense to rebase on top of that.

-- Hannes

Re: [PATCH 0/4] Build in some more things

[Junio C Hamano]

I've merged this to 'pu', but honestly speaking, the conflicts
are geting a bit more "interesting" than I care to keep
repeating even with help from rerere, with four people
simultaneously touching the neighbouring code in their topics.

Topics involved are:

** db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
 . Use built-in send-pack.
 . Build-in send-pack, with an API for other programs to call.
 . Build-in peek-remote, using transport infrastructure.
 . Miscellaneous const changes and utilities

*  jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits
 + t5516: test update of local refs on push
 + send-pack: don't update tracking refs on error

*  js/forkexec (Fri Oct 19 21:48:06 2007 +0200)
 + Use start_command() in git_connect() instead of explicit
   fork/exec.
 + Change git_connect() to return a struct child_process instead of a
   pid_t.

** sp/push-refspec (Sun Oct 28 18:46:21 2007 +0100)
 . push: teach push to pass --verbose option to transport layer
 . push: use same rules as git-rev-parse to resolve refspecs
 . add ref_abbrev_matches_full_with_rev_parse_rules() comparing
   abbrev with full ref name
 . rename ref_matches_abbrev() to
   ref_abbrev_matches_full_with_fetch_rules()

Could you please check the result after I push it out?

Re: [PATCH 0/4] Build in some more things

[Daniel Barkalow]

On Tue, 30 Oct 2007, Junio C Hamano wrote:

> I've merged this to 'pu', but honestly speaking, the conflicts
> are geting a bit more "interesting" than I care to keep
> repeating even with help from rerere, with four people
> simultaneously touching the neighbouring code in their topics.

I mostly actually care about [PATCH 1/4] which is also probably the 
easiest to validate (since it really shouldn't change anything that 
matters except to make things work in more cases). If I could get that in 
early, I'd be fine with pushing the rest off until other people are out of 
that code. The reason I care about 1/4 is that it also sets up an 
extensive patch to make the fetch side of transport use the same git 
connection for getting the initial list of remote refs and for fetching 
their content (still with a second connection for auto-following tags, 
since I couldn't figure out how to request more content after examining 
some fetched content); this patch miraculously doesn't seem to 
significantly conflict with anything currently in pu, and actually 
provides a user-visible benefit (ssh transport with no special 
infrastructure doesn't require typing the password multiple times for a 
single logical operation most of the time).

On the other hand, [PATCH 2/4] might be worth floating earlier in pu, 
since its conflicts are to simply remove all of the code that the other 
patches update (since that code duplicates code in transport.c that can be 
used instead).

For the builtin-send-pack stuff, I might as well redo the same logical 
changes to the code once it settles down, since the edit sequence for 3/4 
is really not all that well represented by diff, being very nearly "rename 
a bunch of static globals; mark a bunch of things const; move a 
function call down; split a function in half", and I can just redo that 
after all the other changes.

> Topics involved are:
> 
> ** db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
>  . Use built-in send-pack.
>  . Build-in send-pack, with an API for other programs to call.
>  . Build-in peek-remote, using transport infrastructure.
>  . Miscellaneous const changes and utilities
> 
> *  jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits
>  + t5516: test update of local refs on push
>  + send-pack: don't update tracking refs on error
> 
> *  js/forkexec (Fri Oct 19 21:48:06 2007 +0200)
>  + Use start_command() in git_connect() instead of explicit
>    fork/exec.
>  + Change git_connect() to return a struct child_process instead of a
>    pid_t.
> 
> ** sp/push-refspec (Sun Oct 28 18:46:21 2007 +0100)
>  . push: teach push to pass --verbose option to transport layer
>  . push: use same rules as git-rev-parse to resolve refspecs
>  . add ref_abbrev_matches_full_with_rev_parse_rules() comparing
>    abbrev with full ref name
>  . rename ref_matches_abbrev() to
>    ref_abbrev_matches_full_with_fetch_rules()
> 
> Could you please check the result after I push it out?

I agree with all of the conflict resolutions, although I didn't make sure 
that parts that didn't get conflicts merged correctly (but, if it builds, 
it's almost certainly right).

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 0/4] Build in some more things

[Daniel Barkalow]

On Tue, 30 Oct 2007, Johannes Sixt wrote:

> Daniel Barkalow schrieb:
> > The main effect of this series is removing the fork/exec from pushing via
> > the git protocol (aside from the later fork/exec in connect.c of course).
> > 
> > It also heads off some tempting transport-related fetch bugs, which I will
> > not introduce in a later patch.
> > 
> > * Miscellaneous const changes and utilities
> >   Adds two small utility functions, and marks a bunch of stuff as const; the
> >   const stuff is to keep builtin-fetch from getting messed up without a
> >   warning, because it wants some lists not to change.
> > 
> > * Build-in peek-remote, using transport infrastructure.
> > * Build-in send-pack, with an API for other programs to call.
> > * Use built-in send-pack.
> 
> I assume this goes on top of current master or db/fetch-pack. The patches have
> some conflicts with js/forkexec (nothing serious, though). Maybe it makes
> sense to rebase on top of that.

Current master. As I said to Junio a moment ago (and forgot to cc you, 
oops), I think 1/4 should go before js/forkexec, being trivial, and 2/4 
should also, since it simply removes duplicate code that js/forkexec 
updates; I should redo 3/4 after the code settles down, and 4/4 is trivial 
but depends on 3/4.

	-Daniel
*This .sig left intentionally blank*