patch, 8 partsVCS helpers

This is the next version of the db/vcs-helper series in pu.

The first patch is new, a rework of the remote-curl build to produce "remote-curl" and call it as a special case for the sorts of URLs that we accept as indicating something that it now handled by this helper.

The series is rebased onto current next, with some conflicts resolved.

Two patches have been dropped: a memory leak fix for code that was removed entirely by the first patch, and the "mark" helper capability, which is not needed (I believe) due to the "option" fast-import command.

Daniel Barkalow (8):
  Make the "traditionally-supported" URLs a special case
  Use a clearer style to issue commands to remote helpers
  Use a function to determine whether a remote is valid
  Allow fetch to modify refs
  Allow programs to not depend on remotes having urls
  Add a config option for remotes to specify a foreign vcs
  Add support for "import" helper command
  Allow helpers to report in "list" command that the ref is unchanged

 Documentation/config.txt             |    4 +
 Documentation/git-remote-helpers.txt |   14 ++++-
 Makefile                             |   17 +-----
 builtin-clone.c                      |    6 +-
 builtin-fetch.c                      |    7 ++-
 builtin-ls-remote.c                  |    4 +-
 builtin-push.c                       |   67 +++++++++++++--------
 remote.c                             |   15 ++++-
 remote.h                             |    2 +
 transport-helper.c                   |  107 +++++++++++++++++++++++++++++-----
 transport.c                          |   23 +++++--
 transport.h                          |   43 +++++++++++++-
 12 files changed, 234 insertions(+), 75 deletions(-)

Daniel Barkalow <barkalow@iabervon.org> writes:

Thanks.

Because the theme of the topic does not have anything to do with fixing the deepening of shallow clones nor giving an extended error message from non-fast-forward git-push, I queued the series after reverse-rebasing onto old db/vcs-helper~8, in order to keep the topic branch pure, instead of merging unrelated topics from maint, master or next into it. The result merged in 'pu' obviously has to match what you expected by applying the patches on top of 'next', and I am reasonably sure it does.

Johan's cvs-helper series were depending on the previous iteration of this series, but I thought it is being rerolled, so I'd drop it from pu for now.

On Fri, 4 Sep 2009, Junio C Hamano wrote:

I'd thought that topics in pu were carried as based on next, particularly once they depend on something (e.g., the beginning of the series) in next. I suppose there's better options, but what do you do to find them? (Feel free to refer me to the "note from the maintainer" if it's there, but I don't remember that detail)

FWIW, there was a semantic mismerge in the original basing of this series on 07a4a3b496, which I finally fixed in this version; the code to handle NULL urls in builtin-fetch was after a new conversion of the url.

In any case, I think both the reverse-rebase and merge are correct.

You could probably stick the "mark" patch into the start of the cvs-helper series until it gets rerolled if you want to keep that series in pu meanwhile; it was at the end of the series, and doesn't have subtle interactions or interact with anything that's changed.

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow <barkalow@iabervon.org> writes:

Oh, I was *not* complaining that you gave a patch based on 'next'. I was merely explaining what I did to your patch, in case somebody wonders why the output of "log -p -8 db/vcs-helper" looks different from what you posted on the list. I also wanted you to verify the result.

Thanks. Actually, the fact your patch was based on 'next' did help me verify the result of the rebase and the merge.

It is a good discipline to spend some extra effort to keep a topic pure if and only if the other topics that the topic textually depends on were of more dubious quality than the topioc itself. In such a case, there is no guarantee that they graduate ever, and the topic will be blocked without major effort later.

It does not matter in practice when we are reasonably sure that other topics that the topic depends on are likely to be already in when the topic is completed. In this particular case, many of the changes the reverse rebase needed to remove are in fact already in master and some are even in maint, and in retrospect, there was not much point doing this only to risk mistakes.

In fact, I originally merged the commits whose changes overlapped and were already in master (Nico's "deepening shallow", Matthieu's "give better warning to non-fast-forward push", to name a few) on top of the part of db/vcs-helper that was already in 'next', and then applied your patches on top of the result, as a middle ground solution. The topic would not have been as pure as the result I pushed out, but it would still have been much better than merging the whole master before applying the series.

The principle of keeping the topic branch pure in this case may fall into my OCD ;-).