Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.

After the 1.6.5 cycle, the next release will be 1.7.0, and we will push
out the planned "push safety" change.  1.7.0 would be a good time to
introduce "justifiable" changes that are not strictly backward compatible.

During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.

--------------------------------------------------
[Graduated to "master"]

* aj/fix-read-tree-from-scratch (2009-08-17) 1 commit
  (merged to 'next' on 2009-08-20 at 7a04133)
 + read-tree: Fix regression with creation of a new index file.

* jc/maint-checkout-index-to-prefix (2009-08-16) 1 commit
  (merged to 'next' on 2009-08-20 at 2f6aea2)
 + check_path(): allow symlinked directories to checkout-index --prefix

* jl/submodule-summary-diff-files (2009-08-15) 2 commits
  (merged to 'next' on 2009-08-15 at 165bd8e)
 + Documentaqtion/git-submodule.txt: Typofix
  (merged to 'next' on 2009-08-14 at a702e78)
 + git submodule summary: add --files option

* lh/short-decorate (2009-08-15) 1 commit
  (merged to 'next' on 2009-08-18 at b8c1d96)
 + git-log: allow --decorate[=short|full]

* oa/stash-na (2009-08-11) 1 commit
  (merged to 'next' on 2009-08-14 at 12c2e2b)
 + git stash: Give friendlier errors when there is nothing to apply
--------------------------------------------------
[New Topics]

* np/maint-1.6.3-deepen (2009-08-24) 1 commit.
  (merged to 'next' on 2009-08-25 at 8e383d4)
 + fix simple deepening of a repo

* jk/maint-1.6.3-checkout-unborn (2009-08-24) 1 commit.
  (merged to 'next' on 2009-08-25 at 5f29625)
 + checkout: do not imply "-f" on unborn branches

* mr/gitweb-snapshot (2009-08-25) 3 commits
 - gitweb: add t9501 tests for checking HTTP status codes
 - gitweb: split test suite into library and tests
 - gitweb: improve ...
[ message continues ]

Please don't.

There is an off-git ML thread running between the various DVCS
tool developers who work on the fast-import/fast-export tools for
the respective DVCSes.  In that thread we have decided to slightly
change this grammar and this series needs to be respun.

If you are itching to do something, eject it from pu and wait for
the respin.
 
-- 
Shawn.
--

[ message continues ]

Heya,


Speaking of which, do you want me to add the feature command to the
grammar and rebase this on top of that? I got the impression we were
far enough discussing that for at least an RPC patch?

-- 
Cheers,

Sverre Rabbelier
--

[ message continues ]

RFC patch.  And yes, because I think we already agreed in that
thread that the date-format option is actually a feature command,
and not an option command.  The other feature commands being kicked
around can be held for another series.

-- 
Shawn.
--

[ message continues ]

Heya,


Done, see v5a of the series (I messed up v5).

-- 
Cheers,

Sverre Rabbelier
--

[ message continues ]

Can you squash this into your 'iffy' workaround to help platforms
(Solaris 7, IRIX 6.5) without the 'yes' utility?

---
 t/t9001-send-email.sh |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 960d7d8..641d0c3 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -505,6 +505,14 @@ test_expect_success '--suppress-cc=cc' '
 	test_suppression cc
 '
 
+yes () {
+	test -n "$*" && y="$*" || y='y'
+	while echo "$y"
+	do
+		:
+	done
+}
+
 test_confirm () {
 	yes | \
 		GIT_SEND_EMAIL_NOTTY=1 \
-- 
1.6.4

--

[ message continues ]

Not in this form, for two reasons ;-)

(1) t7610-mergetool.sh,also seems to use "yes".  Perhaps define something
    in test-lib.sh?


Shouldn't it be

	if test $# = 0
        then
        	y=y
	else
        	y="$*"
	fi

so that

	yes ""

would give runs of empty lines?        
--

[ message continues ]

Looks good, I'll rework it sometime if you don't beat me to it.


--

[ message continues ]

From: Brandon Casey <drafnel@gmail.com>

Some platforms (IRIX 6.5, Solaris 7) do not provide the 'yes' utility.
Currently, some tests, including t7610 and t9001, try to call this program.
Due to the way the tests are structured, the tests still pass even though
this program is missing.  Rather than succeeding by chance, let's provide
an implementation of the simple 'yes' utility in shell for all platforms to
use.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 t/test-lib.sh |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index a5b8d03..f2ca536 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -685,6 +685,21 @@ do
 	esac
 done
 
+# Provide an implementation of the 'yes' utility
+yes () {
+	if test $# = 0
+	then
+		y=y
+	else
+		y="$*"
+	fi
+
+	while echo "$y"
+	do
+		:
+	done
+}
+
 # Fix some commands on Windows
 case $(uname -s) in
 *MINGW*)
-- 
1.6.4

--

[ message continues ]

I believe the outcome of that discussion was:

 - We want to keep supporting using regular location URLs that are URLs of 
   git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git), 
   and we probably want to do it with a helper which runs when 
   run_command() is given "remote-<scheme>". I think installing hardlinks 
   in EXECPATH ended up being the best implementation here. This is 
   currently a special case, because these URLs have push handled 
   internally (or, rather, with internal code calling a different external 
   program), but I think we want to make it no longer special at all, so 
   that people can install the handling for access to native repos via 
   dumb filesystem-like protocols separately. This is in next.

 - We want to support a separate "vcs" option for cases where repositories 
   in the foreign system need to be addressed through the combination of a 
   bunch of options, which will be read from the configuration by the 
   helper. The helper which gets run is "remote-<value of vcs option>". 
   This is in pu.

 - We want to support URLs of some sort leading to using helpers 
   appropriate for foreign systems that use URLs and are most conveniently 
   located this way. We didn't come to any concensus on what this should 
   do, but we also haven't had any helpers proposed yet that would use it, 
   and the series doesn't include any code that would lead to running a 
   helper other than in one of the above two cases. (jh's cvs helper 
   clearly wants "cvsroot" and "cvsmodule" options, and my p4 helper wants 
   "port" and "codeline" options; SVN is the big use cases for URLs, but 
   nobody's tackled that as a helper)

So I think this issue is squarely in "future work" anyway, and the current 
part of the series should be able to move forward, unless I've missed some 
other issue.

Of course, there are a bunch of things that are beyond the present 
contents of the series, but I think there's nothing wrong in the series as ...
[ message continues ]

That is different from what I recall.

I think you said <scheme> in the above to mean that in the general URL
syntax, <scheme> refers to the token before the colon, and you would be
feeding the rest (i.e. after the colon, and for many <scheme>'s it
typically begins with //) to the scheme.

A flaw with this that was pointed out was that this conflicts with the
scp-like syntax.  A remote.$name.url of foo:bar/baz could name
$HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the
source "foo" helper recognizes with the name bar/baz.

If I recall correctly, suggestions made later in the discussion were to
use either <helper>+ or <helper>:: as the prefix to avoid this issue, and
use it to choose remote-<helper> (and I think I probably would vote for
double-colon, if only to avoid confusion with our own earlier misdesigned
syntax git+ssh://), so the canonical syntax would be:

	<helper>::<whatever is fed to the helper, typicall a URL>

while we would support obvious short-hands for transports we traditionally
supported without explicit "<helper>::" prefix when we choose to eject it
from "built-in" set of transports.

E.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl
based walker, so if you spell it in the very canonical form, the url would
be curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to
use it.  Instead, the transport dispatcher internally recognizes http://
and picks the curl based walker helper, which is remote-curl without any
extra hardlinks.

And from my point of view, this is what is blocking the series; and there
still is no -rc0 yet (I've been hoping to do a 1.6.5 mid September before
I leave for Japan for about a week), because I think it is pointless to do

After you explained this in the thread (I think for the second time), I
see no problem with this, except that I think to support this we should
notice and raise an error when we see a remote has both vcs and url,
because the only reason we would want to ...
[ message continues ]

Just to make my position clear.

I brought up the issue of "should we leave it as a single colon that
confuses scp-like syntax and forces us to have three extra hardlinks?" in
the message I am following up to, not because I firmly am on that side of
the argument, but because I thought your version of "outcome" did not
match my recollection around that particular issue.  I am more or less
neutral myself.  Avoiding the confusion seems obviously the simple and
right thing to do, and I cannot think of obvious downsides of such a
change, but there probably are some downsides you have in mind, and I can
well imagine the issue may become "perfect is the enemy of good".

And I said "blocking the series", not in the sense that _I_ demand to
change it from colon to something else, but in the sense that I recall the
issue hasn't been settled in the discussion.

--

[ message continues ]

(with the syntax <helper>+, "git+ssh://" would specify the helper "git", 

If the policy is that we're going to have "traditionally supported" 
schemes, where the internal code knows what helper supports them, I can 
fix up the series so that the curl-based helper is named "curl", and we 
can say that the check for "http://", "ftp://", and "https://" is 
recognizing traditionally-supported schemes, and we can defer coming up 
with what the syntax for the explicit handler selection is. (For that 
matter, if there's a // after the colon, it's obviously not a 
handy ssh-style location, since the second slash would do nothing)

I think you're right that we decided that things we used to support 
internally are a special case, and there's no need to try to generalize 
them to be the general mechanism (even though I think we simultaneously 
worked out how to implement the design we were abandoning, which confused 

A user who mostly uses Perforce as a foreign repositories but is using a 
SVN repo on occasion might want to use "vcs" regardless, but I agree with 
forcing the helper to use a different option for the case of a URL that 
git isn't going to look at. That is, you ought to be able to use:

[remote "origin"]
	vcs = svn
	(something) = http://svn.savannah.gnu.org/...

But "(something)" shouldn't be "url".

So my changes will be:

 - name the curl-based helper executable "git-remote-curl", and run it for 
   traditionally supported schemes by special-case.
 - prohibit using both "vcs" and "url" in a remote.

Agreed?

	-Daniel
*This .sig left intentionally blank*
--

[ message continues ]

Sure but how would you explain "ssh+git://" then ;-)?

Luckily neither is advertised in our documentation set as far as I can
tell, so I do not think it is a huge deal between + vs ::, but as Peff
says in

    http://thread.gmane.org/gmane.comp.version-control.git/125615

I think the latter is probably less problematic.

With plus, a helper that talks with a Subversion repository whose native
URL is http://host/path would look like svn+http://host/path, which is
reasonable.  When talking the Subversion protocol over SSH, however, the
native URL for the repository would be svn+ssh://host/path, so the URL
with helper name on our side becomes svn+svn+ssh://host/path.  We could
recognize "svn+" part and implicitly pass the whole thing to svn helper
upon seeing svn+ssh://host/path, but I do not think we would want to make
the dispatcher too familiar with what the backends do.  Using something

That sounds like a sane approach to first get the "eject curl from
builtin" out the door.  We might extend the dispatcher in the future by
changing "traditionally supported" criterion to "commonly used",
e.g. recognize "svn+ssh://" as something the svn helper would want to
handle, but that is a future extension we do not have to address right

I actuallly do not have a strong opinion on this one either way.  I said
"I think" when I suggested it, but it was actually without thinking too
deeply, hoping that you would come up with a good counter-argument.

For example, if we envision that for most of the helpers there will be one
primary string that identifies the repository, but the primary string
alone is not enough for the helper without some auxiliary information, it
would be natural to use remote.$name.url for that primary string.  I do
not know if that would be the case, but I was hoping that you would have a
better intuition[*1*], as you have thought this topic through a lot longer
and deeper than I have.  So I'd rather leave the decision on that "no
vcs/url at the same time ...
[ message continues ]

That's just weird, and looks wrong to me, like ssh tunnelled over the git 
native protocol. I think, if we support it, it would have to be another 

I was thinking that the dispatcher would always pass the whole thing, and 
the svn helper would have to deal with svn+http:// and svn+svn:// as well 
as svn+ssh://. The dispatcher shouldn't be familiar with what the backends 
do, but the backends could stand to be familiar with what might be there 
just to get to them. On the other hand, I don't have a good intuition for 
what makes sense to users of such systems, since I've only extensively 



I don't really have a particularly good guess about the case of vcs and a 
URL, because I haven't used systems that are not git and use URLs.

	-Daniel
*This .sig left intentionally blank*
--

[ message continues ]