git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Steffen Prohaska <prohaska@zib.de>,
	Martin Langhoff <martin.langhoff@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Minor annoyance with git push
Date: Wed, 20 Feb 2008 09:03:07 -0500	[thread overview]
Message-ID: <20080220140306.GA6928@sigill.intra.peff.net> (raw)
In-Reply-To: <7vzltwavf9.fsf@gitster.siamese.dyndns.org>

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

> [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

> 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

  parent reply	other threads:[~2008-02-20 14:03 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08  4:44 Minor annoyance with git push Martin Langhoff
2008-02-08  4:50 ` Martin Langhoff
2008-02-08  7:48   ` Junio C Hamano
2008-02-09 11:22     ` Steffen Prohaska
2008-02-10  3:44       ` Junio C Hamano
2008-02-10 12:21         ` Johannes Schindelin
2008-02-08 11:52   ` Johannes Schindelin
2008-02-08 22:23     ` Martin Langhoff
2008-02-08 22:27       ` Mike Hommey
2008-02-08  5:38 ` Sean
2008-02-08  6:29   ` Steffen Prohaska
2008-02-08 11:50 ` Johannes Schindelin
2008-02-08 22:27   ` Martin Langhoff
2008-02-08 22:57     ` Johannes Schindelin
2008-02-09  2:46     ` Jeff King
2008-02-09  2:54       ` Jeff King
2008-02-09 13:04         ` Johannes Schindelin
2008-02-09 13:22           ` Jeff King
2008-02-09 11:22       ` Steffen Prohaska
2008-02-09  3:00 ` Jeff King
2008-02-09  3:24   ` Junio C Hamano
2008-02-09  3:55     ` Jeff King
2008-02-09 11:50     ` Martin Langhoff
2008-02-09 13:06       ` Johannes Schindelin
2008-02-10  2:24       ` Junio C Hamano
2008-02-10 10:13         ` Jeff King
2008-02-10 12:22           ` Johannes Schindelin
2008-02-17  1:08         ` [RFC] checkout to notice forks (Re: Minor annoyance with git push) Junio C Hamano
2008-02-17  3:31           ` Daniel Barkalow
2008-02-17  4:11             ` Junio C Hamano
2008-02-17  6:39               ` Daniel Barkalow
2008-02-17  7:37                 ` Junio C Hamano
2008-02-17 17:36                   ` Daniel Barkalow
2008-02-17 12:28           ` Jeff King
2008-02-20 16:01             ` Santi Béjar
2008-02-19 17:03           ` Martin Langhoff
2008-02-20 23:05             ` [PATCH] checkout: tone down the "forked status" diagnostic messages Junio C Hamano
2008-02-21  1:45               ` Jeff King
2008-02-21  3:42                 ` [PATCH] checkout: updates to tracking report Junio C Hamano
2008-02-21  5:27                   ` Jay Soffian
2008-02-21 17:02                   ` Daniel Barkalow
2008-02-21  2:56               ` [PATCH] checkout: tone down the "forked status" diagnostic messages Jay Soffian
2008-02-09 10:53   ` Minor annoyance with git push Steffen Prohaska
2008-02-09 13:10     ` Johannes Schindelin
2008-02-10  2:07       ` Junio C Hamano
2008-02-10  2:15         ` Johannes Schindelin
2008-02-10 10:17           ` Jeff King
2008-02-10 12:20             ` Johannes Schindelin
2008-02-10 12:23               ` Jeff King
2008-02-10 13:04                 ` Johannes Schindelin
2008-02-10 13:07                   ` Jeff King
2008-02-20  8:23                   ` Junio C Hamano
2008-02-20 13:06                     ` Johannes Schindelin
2008-02-20 15:20                       ` Jay Soffian
2008-02-20 15:38                         ` Johannes Schindelin
2008-02-21 22:35                           ` Steven Walter
2008-02-22  0:11                             ` Johannes Schindelin
2008-02-20 14:03                     ` Jeff King [this message]
2008-02-20 17:54                       ` Junio C Hamano
2008-02-20 18:15                         ` Jeff King
2008-02-20 18:17                           ` Jeff King
2008-02-20 18:19                           ` Junio C Hamano
2008-02-20 18:23                             ` Jeff King
2008-02-10 14:03           ` Wincent Colaiuta
2008-02-10 15:02             ` Steven Walter
2008-02-10 16:29               ` Johannes Schindelin
2008-02-10 16:26             ` Johannes Schindelin
2008-02-10 18:18               ` Wincent Colaiuta
2008-02-10 22:34                 ` Jeff King
2008-02-10 22:59                   ` Junio C Hamano
2008-02-10 23:29                     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080220140306.GA6928@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.langhoff@gmail.com \
    --cc=prohaska@zib.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).