git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Soffian <jaysoffian@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: git push usage
Date: Fri, 20 Feb 2009 04:16:26 -0500	[thread overview]
Message-ID: <76718490902200116n73e00b62sbe7bb774bcc058c5@mail.gmail.com> (raw)

The man page for git push claims:

 --repo=<repository>
     This option is only relevant if no <repository> argument is passed
     in the invocation. In this case, git-push derives the remote name
     from the current branch: If it tracks a remote branch, then that
     remote repository is pushed to. Otherwise, the name "origin" is
     used. For this latter case, this option can be used to override the
     name "origin". In other words, the difference between these two
     commands

         git push public         #1
         git push --repo=public  #2

     is that #1 always pushes to "public" whereas #2 pushes to "public"
     only if the current branch does not track a remote branch. This is
     useful if you write an alias or script around git-push.

However, I'm sitting here looking at the code and I don't see how this
is possible. I've also done some testing. So I think the man page lies
and that forms (1) and (2) are equivalent as shown.

cmd_push() is:

  const char *repo = NULL; /* default repository */
  struct option options[] = {
    ...
    OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
    ...
  }

  argc = parse_options(argc, argv, options, push_usage, 0);

  if (argc > 0) {
    repo = argv[0];
    set_refspecs(argv + 1, argc - 1);
  }

  rc = do_push(repo, flags);

So if the user specifies --repo, then its value is assigned to *repo by
parse_options. If the user otherwise specifies a repository w/o --repo, that
will be argv[0] after parse_options, so it will get assigned to *repo. Assuming
no other arguments, set_refspecs gets called with argc = 0 and returns w/o doing
anything.

So the only difference I can see is that form #1 allows the user to specify a
refspec on the command line. Form #2 does not since the first
non-dashed argument gets assigned to *repo, so:

$ git push --repo src:dst

would assign src:dst to *repo, which would choke.

So, what's the point of the --repo dashed-option then?

j.

             reply	other threads:[~2009-02-20  9:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-20  9:16 Jay Soffian [this message]
2009-02-21  9:32 ` git push usage Jay Soffian
2009-02-24 17:40   ` [RFC] add test cases for the --repo option to git push Michael J Gruber
2009-02-25 21:58     ` Junio C Hamano
2009-02-26  9:26       ` Michael J Gruber
2009-02-26 17:09         ` Junio C Hamano
2009-02-26 17:48           ` Michael J Gruber
2009-02-26 22:11             ` Jay Soffian
2009-02-27 10:42           ` Michael J Gruber
2009-02-27 17:34             ` Junio C Hamano
2009-02-27 20:48             ` Jay Soffian
2009-02-27 21:00               ` Linus Torvalds
2009-02-27 21:21                 ` Jay Soffian

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=76718490902200116n73e00b62sbe7bb774bcc058c5@mail.gmail.com \
    --to=jaysoffian@gmail.com \
    --cc=git@vger.kernel.org \
    /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).