On Wed, Feb 20, 2008 at 12:23:06AM -0800, Junio C Hamano wrote:

quoted text
> [long description of shared repository workflow]
> So perhaps we can have "remote.*.push" that says "current" in
> some way.  Tentatively let's say the syntax is like this:

I think everything you said here makes perfect sense; changing the push
refspec to say "push the current" for a particular remote is much more
sensible than an overall default. In fact, I half-expected this to
just work without a patch, since "git push origin HEAD" already works.
However, we don't treat command line refspecs and config refspecs the
same way, which IMHO is a needless inconsistency. How about this:

diff --git a/builtin-push.c b/builtin-push.c
index 9f727c0..ca90150 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -68,8 +68,7 @@ static int do_push(const char *repo, int flags)
 	if (!refspec
 		&& !(flags & TRANSPORT_PUSH_ALL)
 		&& remote->push_refspec_nr) {
-		refspec = remote->push_refspec;
-		refspec_nr = remote->push_refspec_nr;
+		set_refspecs(remote->push_refspec, remote->push_refspec_nr);
 	}
 	errs = 0;
 	for (i = 0; i < remote->url_nr; i++) {

At which point this now works as you described:

  git config remote.origin.push HEAD

quoted text
> I was hoping we can do without the "remote.*.push = HEAD" if we
> can detect the remote is a shared repository while talking to
> it, but I think it is a bit too much magic, because we cannot
> visualize what the pushing side and the receiving side  are
> negotiating.

How are you detecting that the remote is a shared repository? By the
core.sharedrepository config option? I use several shared repositories,
and I never set that variable; instead I use filesystem ACLs (which we
could at least detect). It is my understanding that some people even
have repositories where multiple users share the same filesystem uid but
connect with different ssh keys.  I don't think that is even detectable.

-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html