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.
next 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).