summaryrefslogtreecommitdiff
path: root/builtin-push.c
AgeCommit message (Collapse)AuthorFilesLines
2009-09-06Merge branch 'maint'Libravatar Junio C Hamano1-3/+3
* maint: push: re-flow non-fast-forward message push: fix english in non-fast-forward message
2009-09-06push: re-flow non-fast-forward messageLibravatar Jeff King1-3/+3
The extreme raggedness of the right edge make this jarring to read. Let's re-flow the text to fill the lines in a more even way. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-06push: fix english in non-fast-forward messageLibravatar Jeff King1-1/+1
We must use an article when referring to the section because it is a non-proper noun, and it must be the definite article because we are referring to a specific section. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12Merge branch 'maint'Libravatar Junio C Hamano1-1/+8
* maint: push: point to 'git pull' and 'git push --force' in case of non-fast forward Documentation: add: <filepattern>... is optional Change mentions of "git programs" to "git commands" Documentation: merge: one <remote> is required help.c: give correct structure's size to memset()
2009-08-12push: point to 'git pull' and 'git push --force' in case of non-fast forwardLibravatar Matthieu Moy1-1/+8
'git push' failing because of non-fast forward is a very common situation, and a beginner does not necessarily understand "fast forward" immediately. Add a new section to the git-push documentation and refer them to it. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05push: add --quiet flagLibravatar Jeff King1-0/+1
Some transports produce output even without "--verbose" turned on. This provides a way to tell them to be more quiet (whereas simply redirecting might lose error messages). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-18push: do not give big warning when no preference is configuredLibravatar Junio C Hamano1-26/+1
If the message said "we will be changing the default in the future, so this is to warn people who want to keep the current default what to do", it would have made some sense, but as it stands, the message is merely an unsolicited advertisement for a new feature, which it is not helpful at all. Squelch it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-27add --porcelain option to git-pushLibravatar Larry D'Anna1-1/+2
If --porcelain is used git-push will produce machine-readable output. The output status line for each ref will be tab-separated and sent to stdout instead of stderr. The full symbolic names of the refs will be given. For example $ git push --dry-run --porcelain master :foobar 2>/dev/null \ | perl -pe 's/\t/ TAB /g' = TAB refs/heads/master:refs/heads/master TAB [up to date] - TAB :refs/heads/foobar TAB [deleted] Signed-off-by: Larry D'Anna <larry@elder-gods.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-09Allow push and fetch urls to be differentLibravatar Michael J Gruber1-4/+13
This introduces a config setting remote.$remotename.pushurl which is used for pushes only. If absent remote.$remotename.url is used for pushes and fetches as before. This is useful, for example, in order to do passwordless fetches (remote update) over the git transport but pushes over ssh. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-25parse-opts: prepare for OPT_FILENAMELibravatar Stephen Boyd1-1/+1
To give OPT_FILENAME the prefix, we pass the prefix to parse_options() which passes the prefix to parse_options_start() which sets the prefix member of parse_opts_ctx accordingly. If there isn't a prefix in the calling context, passing NULL will suffice. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-26Merge branch 'fg/push-default'Libravatar Junio C Hamano1-5/+71
* fg/push-default: builtin-push.c: Fix typo: "anythig" -> "anything" Display warning for default git push with no push.default config New config push.default to decide default behavior for push Conflicts: Documentation/config.txt
2009-03-25builtin-push.c: Fix typo: "anythig" -> "anything"Libravatar Kevin Ballard1-1/+1
Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-17Display warning for default git push with no push.default configLibravatar Finn Arne Gangstad1-0/+23
If a git push without any refspecs is attempted, display a warning. The current default behavior is to push all matching refspecs, which may come as a surprise to new users, so the warning shows how push.default can be configured and what the possible values are. Traditionalists who wish to keep the current behaviour are also told how to configure this once and never see the warning again. Signed-off-by: Finn Arne Gangstad <finnag@pvv.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-17New config push.default to decide default behavior for pushLibravatar Finn Arne Gangstad1-5/+48
When "git push" is not told what refspecs to push, it pushes all matching branches to the current remote. For some workflows this default is not useful, and surprises new users. Some have even found that this default behaviour is too easy to trigger by accident with unwanted consequences. Introduce a new configuration variable "push.default" that decides what action git push should take if no refspecs are given or implied by the command line arguments or the current remote configuration. Possible values are: 'nothing' : Push nothing; 'matching' : Current default behaviour, push all branches that already exist in the current remote; 'tracking' : Push the current branch to whatever it is tracking; 'current' : Push the current branch to a branch of the same name, i.e. HEAD. Signed-off-by: Finn Arne Gangstad <finnag@pvv.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10Give error when no remote is configuredLibravatar Daniel Barkalow1-2/+5
When there's no explicitly-named remote, we use the remote specified for the current branch, which in turn defaults to "origin". But it this case should require the remote to actually be configured, and not fall back to the path "origin". Possibly, the config file's "remote = something" should require the something to be a configured remote instead of a bare repository URL, but we actually test with a bare repository URL. In fetch, we were giving the sensible error message when coming up with a URL failed, but this wasn't actually reachable, so move that error up and use it when appropriate. In push, we need a new error message, because the old one (formerly unreachable without a lot of help) used the repo name, which was NULL. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-08Merge branch 'maint'Libravatar Shawn O. Pearce1-1/+1
* maint: Do not use errno when pread() returns 0 git init: --bare/--shared overrides system/global config git-push.txt: Describe --repo option in more detail git rm: refresh index before up-to-date check Fix a few typos in relnotes
2008-10-08git-push.txt: Describe --repo option in more detailLibravatar Johannes Sixt1-1/+1
The --repo option was described in a way that the reader would have to assume that it is the same as the <repository> parameter. But it actually servers a purpose, which is now written down. Furthermore, the --mirror option was missing from the synopsis. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-08-17Make push more verbose about illegal combination of optionsLibravatar Marek Zawirski1-2/+11
It may be unclear that --all, --mirror, --tags and/or explicit refspecs are illegal combinations for git push. Git was silently failing in these cases, while we can complaint more properly about it. Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-20builtin-push.c: Cleanup - use OPT_BIT() and remove some variablesLibravatar Michele Ballabio1-21/+8
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13Make usage strings dash-lessLibravatar Stephan Beyer1-1/+1
When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-20Add a remote.*.mirror configuration optionLibravatar Paolo Bonzini1-8/+16
This patch adds a remote.*.mirror configuration option that, when set, automatically puts git-push in --mirror mode for that remote. Furthermore, the option is set automatically by `git remote add --mirror'. The code in remote.c to parse remote.*.skipdefaultupdate had a subtle problem: a comment in the code indicated that special care was needed for boolean options, but this care was not used in parsing the option. Since I was touching related code, I did this fix too. [jc: and I further fixed up the "ignore boolean" code.] Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20Resolve value supplied for no-colon push refspecsLibravatar Daniel Barkalow1-9/+0
When pushing a refspec like "HEAD", we used to treat it as "HEAD:HEAD", which didn't work without rewriting. Instead, we should resolve the ref. If it's a symref, further require it to point to a branch, to avoid doing anything especially unexpected. Also remove the rewriting previously added in builtin-push. Since the code for "HEAD" uses the regular refspec parsing, it automatically handles "+HEAD" without anything special. [jc: added a further test to make sure that "remote.*.push = HEAD" works] Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-19push: indicate partialness of error messageLibravatar Jeff King1-1/+1
The existing message indicates that an error occured during push, but it is unclear whether _any_ refs were actually pushed (even though the status table above shows which were pushed successfully and which were not, the message "failed to push" implies a total failure). By indicating that "some refs" failed, we hopefully indicate to the user that the table above contains the details. We could also put in an explicit "see above for details" message, but it seemed to clutter the output quite a bit (both on a line of its own, or at the end of the error line, which inevitably wraps). This could also be made more fancy if the transport mechanism passed back more details on how many refs succeeded and failed: error: failed to push %d out of %d refs to '%s' Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-04Merge branch 'sp/refspec-match'Libravatar Junio C Hamano1-0/+9
* sp/refspec-match: refactor fetch's ref matching to use refname_match() push: use same rules as git-rev-parse to resolve refspecs add refname_match() push: support pushing HEAD to real branch name
2007-11-18push: support pushing HEAD to real branch nameLibravatar Steffen Prohaska1-0/+9
This teaches "push <remote> HEAD" to resolve HEAD on the local side to its real branch name, e.g. master, and then act as if the real branch name was specified. So we have a shorthand for pushing the current branch. Besides HEAD, no other symbolic ref is resolved. Thanks to Daniel Barkalow <barkalow@iabervon.org> for suggesting this implementation, which is much simpler than the implementation proposed before. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14Merge branch 'aw/mirror-push' into jk/send-packLibravatar Junio C Hamano1-2/+12
* aw/mirror-push: git-push: add documentation for the newly added --mirror mode Add tests for git push'es mirror mode git-push: plumb in --mirror mode Teach send-pack a mirror mode send-pack: segfault fix on forced push send-pack: require --verbose to show update of tracking refs receive-pack: don't mention successful updates more terse push output Conflicts: transport.c transport.h
2007-11-11push: teach push to pass --verbose option to transport layerLibravatar Steffen Prohaska1-0/+2
A --verbose option to push should also be passed to the transport layer, i.e. git-send-pack, git-http-push. git push is modified to do so. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-09git-push: plumb in --mirror modeLibravatar Andy Whitcroft1-2/+12
Plumb in the --mirror mode for git-push. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05Use parseopts in builtin-pushLibravatar Daniel Barkalow1-52/+36
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-16Fix 'push --all branch...' error handlingLibravatar Shawn O. Pearce1-3/+5
The builtin-fetch topic changed push's handling of --all to setting the new TRANSPORT_PUSH_ALL flag before starting the push subroutine for the given transport. Unfortunately not all references within builtin-push were changed to test this flag therefore allowing push to incorrectly accept refspecs and --all. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-16Merge branch 'master' into db/fetch-packLibravatar Shawn O. Pearce1-1/+5
There's a number of tricky conflicts between master and this topic right now due to the rewrite of builtin-push. Junio must have handled these via rerere; I'd rather not deal with them again so I'm pre-merging master into the topic. Besides this topic somehow started to depend on the strbuf series that was in next, but is now in master. It no longer compiles on its own without the strbuf API. * master: (184 commits) Whip post 1.5.3.4 maintenance series into shape. Minor usage update in setgitperms.perl manual: use 'URL' instead of 'url'. manual: add some markup. manual: Fix example finding commits referencing given content. Fix wording in push definition. Fix some typos, punctuation, missing words, minor markup. manual: Fix or remove em dashes. Add a --dry-run option to git-push. Add a --dry-run option to git-send-pack. Fix in-place editing functions in convert.c instaweb: support for Ruby's WEBrick server instaweb: allow for use of auto-generated scripts Add 'git-p4 commit' as an alias for 'git-p4 submit' hg-to-git speedup through selectable repack intervals git-svn: respect Subversion's [auth] section configuration values gtksourceview2 support for gitview fix contrib/hooks/post-receive-email hooks.recipients error message Support cvs via git-shell rebase -i: use diff plumbing instead of porcelain ... Conflicts: Makefile builtin-push.c rsh.c
2007-10-15Add a --dry-run option to git-push.Libravatar Brian Ewins1-2/+8
The default behaviour of git-push is potentially confusing for new users, since it will push changes that are not on the current branch. Publishing patches that were still cooking on a development branch is hard to undo. It would also be nice to be able to verify the expansion of refspecs if you've edited them, so that you know what branches matched on the server. Adding a --dry-run flag allows the user to experiment safely and learn how to use git-push properly. Originally suggested by Steffen Prohaska. Signed-off-by: Brian Ewins <brian.ewins@gmail.com> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-19Rename remote.uri to remote.url within remote handling internalsLibravatar Shawn O. Pearce1-4/+4
Anyplace we talk about the address of a remote repository we always refer to it as a URL, especially in the configuration file and .git/remotes where we call it "remote.$n.url" or start the first line with "URL:". Calling this value a uri within the internal C code just doesn't jive well with our commonly accepted terms. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Remove unnecessary 'fetch' argument from transport_get APILibravatar Shawn O. Pearce1-1/+1
We don't actually need to know at the time of transport_get if the caller wants to fetch, push, or do both on the returned object. It is easier to just delay the initialization of the HTTP walker until we know we will need it by providing a CURL specific fetch function in the curl_transport that makes sure the walker instance is initialized before use. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Push code for transport libraryLibravatar Daniel Barkalow1-61/+21
This moves the code to call push backends into a library that can be extended to make matching fetch and push decisions based on the URL it gets, and which could be changed to have built-in implementations instead of calling external programs. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-10Make --no-thin the default in git-push to save server resourcesLibravatar Shawn O. Pearce1-1/+1
1) pushes happen less often than fetches, so the bandwidth saving is much less visible in that case overall. 2) thin packs have to be complemented with missing delta bases to be valid, so many received thin packs will take more disk space. 3) the bother of repacking should be distributed amongst "clients" i.e. fetchers and pushers as much as possible, and not the server being fetched or pushed, to keep disk and CPU usage low on the server. This is why a fetch should get thin packs but a push should not. Both Nico and I have been assuming that --no-thin was the default behavior of git-push ever since Nico introduced --fix-thin into the index-pack process, which allowed fetch and receive-pack to avoid exploding packfiles received during transfer. This patch finally makes it so. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-26Move refspec pattern matching to match_refs().Libravatar Daniel Barkalow1-111/+22
This means that send-pack and http-push will support pattern refspecs, so builtin-push.c doesn't have to expand them, and also git push can just turn --tags into "refs/tags/*", further simplifying builtin-push.c check_ref_format() gets a third "conditionally okay" result for something that's valid as a pattern but not as a particular ref. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Update local tracking refs when pushingLibravatar Daniel Barkalow1-2/+7
This also adds a --remote option to send-pack, which specifies the configured remote being used. It is provided automatically by git-push, and must match the url (which is still needed, since there could be multiple urls). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Move remote parsing into a library file out of builtin-push.Libravatar Daniel Barkalow1-170/+20
The new parser is different from the one in builtin-push in two ways: the default is to use the current branch's remote, if there is one, before "origin"; and config is used in preference to remotes. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-07git-push to multiple locations does not stop at the first failureLibravatar Junio C Hamano1-7/+8
When pushing into multiple repositories with git push, via multiple URL in .git/remotes/$shorthand or multiple url variables in [remote "$shorthand"] section, we used to stop upon the first failure. Continue the operation and report the failure at the end. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-07git-push reports the URL after failing.Libravatar Junio C Hamano1-0/+2
This came up on #git when somebody was getting 'unable to create ./objects/tmp_oXXXX' but sweared he had write permission to that directory. It turned out that the repository URL was changed and he was accessing a repository he does not have a write permission anymore. I am not sure how much this would have helped somebody who believed he was accessing location when the permission of that location was changed while he was looking the other way, though. But giving more information on the error path would be better, and the next change would be helped with this as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-12Use RUN_GIT_CMD to run push backendsLibravatar Shawn O. Pearce1-3/+3
If we hand run_command RUN_GIT_CMD rather than 0 it will use the execv_git_cmd path rather than execvp at the OS level. This is typically the preferred way of running another Git utility. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-11Remove unused run_command variantsLibravatar Shawn O. Pearce1-1/+1
We don't actually use these va_list based variants of run_command anymore. I'm removing them before I make further improvements. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20prefixcmp(): fix-up mechanical conversion.Libravatar Junio C Hamano1-2/+2
Previous step converted use of strncmp() with literal string mechanically even when the result is only used as a boolean: if (!strncmp("foo", arg, 3)) ==> if (!(-prefixcmp(arg, "foo"))) This step manually cleans them up to read: if (!prefixcmp(arg, "foo")) Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Mechanical conversion to use prefixcmp()Libravatar Junio C Hamano1-9/+9
This mechanically converts strncmp() to use prefixcmp(), but only when the parameters match specific patterns, so that they can be verified easily. Leftover from this will be fixed in a separate step, including idiotic conversions like if (!strncmp("foo", arg, 3)) => if (!(-prefixcmp(arg, "foo"))) This was done by using this script in px.perl #!/usr/bin/perl -i.bak -p if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) { s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|; } if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) { s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|; } and running: $ git grep -l strncmp -- '*.c' | xargs perl px.perl Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-06git-push: allow globbing wildcard refspec.Libravatar Junio C Hamano1-32/+82
This allows you to set up mothership-satellite configuration more symmetrically and naturally by allowing the globbing wildcard refspec for git-push. On your satellite machine: [remote "mothership"] url = mothership:project.git fetch = refs/heads/*:refs/remotes/mothership/* push = refs/heads/*:refs/remotes/satellite/* You would say "git fetch mothership" to update your tracking branches under mothership/ to keep track of the progress on the mothership side, and when you are done working on the satellite machine, you would "git push mothership" to update their tracking branches under satellite/. Corresponding configuration on the mothership machine can be used to make "git fetch satellite" update its tracking branch under satellite/. on the mothership. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19rename --exec to --receive-pack for push and send-packLibravatar Uwe Kleine-König1-10/+14
For now it's just to get a more descriptive name. Later we might update the push protocol to run more than one program on the other end. Moreover this matches better the corresponding config option remote.<name>. receivepack. --exec continues to work Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19make --exec=... option to git-push configurableLibravatar Uwe Kleine-König1-0/+11
Having to specify git push --exec=... is annoying if you cannot have git-receivepack in your PATH on the remote side (or don't want to). This introduces the config item remote.<name>.receivepack to override the default value (which is "git-receive-pack"). Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19Update documentation of fetch-pack, push and send-packLibravatar Uwe Kleine-König1-1/+1
add all supported options to Documentation/git-....txt and the usage strings. Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-30Remove unnecessary argc parameter from run_command_v.Libravatar Shawn O. Pearce1-1/+1
The argc parameter is never used by the run_command_v family of functions. Instead they require that the passed argv[] be NULL terminated so they can rely on the operating system's execvp function to correctly pass the arguments to the new process. Making the caller pass the argc is just confusing, as the caller could be mislead into believing that the argc might take precendece over the argv, or that the argv does not need to be NULL terminated. So goodbye argc. Don't come back. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>