summaryrefslogtreecommitdiff
path: root/git-pull.sh
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'jk/merge-rename-ux'Junio C Hamano2011-03-191-2/+4
|\ | | | | | | | | | | | | | | | | | | * jk/merge-rename-ux: pull: propagate --progress to merge merge: enable progress reporting for rename detection add inexact rename detection progress infrastructure commit: stop setting rename limit bump rename limit defaults (again) merge: improve inexact rename limit warning
| * pull: propagate --progress to mergeJeff King2011-02-211-2/+4
| | | | | | | | | | | | | | | | Now that merge understands progress, we should pass it along. While we're at it, pass along --no-progress, too. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | pull: do not display fetch usage on --help-allMichael J Gruber2011-02-151-1/+1
|/ | | | | | | | | | | | Currently, "git pull --help-all" displays the fetch usage info. Make it equivalent to "git pull -h" instead since "--help-all" is documented in gitcli(7). Do not try to sanitize the pull option parser (aka last hair puller). Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jl/fetch-submodule-recursive'Junio C Hamano2010-12-161-2/+8
|\ | | | | | | | | | | | | | | | | | | | | * jl/fetch-submodule-recursive: fetch_populated_submodules(): document dynamic allocation Submodules: Add the "fetchRecurseSubmodules" config option Add the 'fetch.recurseSubmodules' config setting fetch/pull: Add the --recurse-submodules option Conflicts: builtin/fetch.c
| * Add the 'fetch.recurseSubmodules' config settingJens Lehmann2010-11-121-0/+3
| | | | | | | | | | | | | | | | | | This new boolean option can be used to override the default for "git fetch" and "git pull", which is to not recurse into populated submodules and fetch all new commits there too. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * fetch/pull: Add the --recurse-submodules optionJens Lehmann2010-11-121-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now you had to call "git submodule update" (without -N|--no-fetch option) or something like "git submodule foreach git fetch" to fetch new commits in populated submodules from their remote. This could lead to "(commits not present)" messages in the output of "git diff --submodule" (which is used by "git gui" and "gitk") after fetching or pulling new commits in the superproject and is an obstacle for implementing recursive checkout of submodules. Also "git submodule update" cannot fetch changes when disconnected, so it was very easy to forget to fetch the submodule changes before disconnecting only to discover later that they are needed. This patch adds the "--recurse-submodules" option to recursively fetch each populated submodule from the url configured in the .git/config of the submodule at the end of each "git fetch" or during "git pull" in the superproject. The submodule paths are taken from the index. The hidden option "--submodule-prefix" is added to "git fetch" to be able to print out the full paths of nested submodules. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Porcelain scripts: Rewrite cryptic "needs update" error messageRamkumar Ramachandra2010-10-281-4/+1
|/ | | | | | | | | | | | | | Although Git interally has the facility to differentiate between porcelain and plubmbing commands and appropriately print errors, several shell scripts invoke plubming commands triggering cryptic plumbing errors to be displayed on a porcelain interface. This patch replaces the "needs update" message in git-pull and git-rebase, when `git update-index` is run, with a more friendly message. Reported-by: Joshua Jensen <jjensen@workspacewhiz.com> Reported-by: Thore Husfeldt <thore.husfeldt@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'en/rebase-against-rebase-fix'Junio C Hamano2010-08-211-0/+9
|\ | | | | | | | | | | * en/rebase-against-rebase-fix: pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches t5520-pull: Add testcases showing spurious conflicts from git pull --rebase
| * pull --rebase: Avoid spurious conflicts and reapplying unnecessary patchesElijah Newren2010-08-121-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26), pull --rebase would run git rebase $merge_head which resulted in a call to git format-patch ... --ignore-if-in-upstream $merge_head..$cur_branch This resulted in patches from $merge_head..$cur_branch being applied, as long as they did not already exist in $cur_branch..$merge_head. Unfortunately, when upstream is rebased, $merge_head..$cur_branch also refers to "old" commits that have already been rebased upstream, meaning that many patches that were already fixed upstream would be reapplied. This could result in many spurious conflicts, as well as reintroduce patches that were intentionally dropped upstream. So the algorithm was changed in c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26) and d44e712 (pull: support rebased upstream + fetch + pull --rebase, 2009-07-19). Defining $old_remote_ref to be the most recent entry in the reflog for @{upstream} that is an ancestor of $cur_branch, pull --rebase was changed to run git rebase --onto $merge_head $old_remote_ref which results in a call to git format-patch ... --ignore-if-in-upstream $old_remote_ref..$cur_branch The whole point of this change was to reduce the number of commits being reapplied, by avoiding commits that upstream already has or had. In the rebased upstream case, this change achieved that purpose. It is worth noting, though, that since $old_remote_ref is always an ancestor of $cur_branch (by its definition), format-patch will not know what upstream is and thus will not be able to determine if any patches are already upstream; they will all be reapplied. In the non-rebased upstream case, this new form is usually the same as the original code but in some cases $old_remote_ref can be an ancestor of $(git merge-base $merge_head $cur_branch) meaning that instead of avoiding reapplying commits that upstream already has, it actually includes more such commits. Combined with the fact that format-patch can no longer detect commits that are already upstream (since it is no longer told what upstream is), results in lots of confusion for users (e.g. "git is giving me lots of conflicts in stuff I didn't even change since my last push.") Cases where additional commits could be reapplied include forking from a commit other than the tracking branch, or amending/rebasing after pushing. Cases where the inability to detect upstreamed commits cause problems include independent discovery of a fix and having your patches get upstreamed by some alternative route (e.g. pulling your changes to a third machine, pushing from there, and then going back to your original machine and trying to pull --rebase). Fix the non-rebased upstream case by ignoring $old_remote_ref whenever it is contained in $(git merge-base $merge_head $cur_branch). This should have no affect on the rebased upstream case. Acked-by: Santi Béjar <santi@agolina.net> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | pull: do nothing on --dry-runJeff King2010-05-251-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull was never meant to take --dry-run at all. However, it passes unknown arguments to git-fetch, which does do a dry-run. Unfortunately, pull then attempts to merge whatever cruft was in FETCH_HEAD (which the dry-run fetch will not have written to). Even though we never advertise --dry-run as something that should work, it is still worth being defensive because: 1. Other commands (including fetch) take --dry-run, so a user might try it. 2. Rather than simply producing an error, it actually changes the repository in totally unexpected ways. This patch makes "pull --dry-run" equivalent to "fetch --dry-run". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'maint'Junio C Hamano2010-03-201-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Update draft release notes to 1.7.0.3 fetch: Fix minor memory leak fetch: Future-proof initialization of a refspec on stack fetch: Check for a "^{}" suffix with suffixcmp() daemon: parse_host_and_port SIGSEGV if port is specified Makefile: Fix CDPATH problem pull: replace unnecessary sed invocation
| * | pull: replace unnecessary sed invocationStephen Boyd2010-03-201-1/+1
| |/ | | | | | | | | | | | | | | Getting the shortened branch name is as easy as using the shell's parameter expansion. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | fetch and pull: learn --progressTay Ray Chuan2010-02-241-2/+4
|/ | | | | | | | | | | | Note that in the documentation for git-pull, documentation for the --progress option is displayed under the "Options related to fetching" subtitle via fetch-options.txt. Also, update the documentation of the -q/--quiet option for git-pull to mention its effect on progress reporting during fetching. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: re-fix command line generationJunio C Hamano2010-01-241-1/+1
| | | | | | | 14e5d40 (pull: Fix parsing of -X<option>, 2010-01-17) forgot that merge_name needs to stay as a single non-interpolated string. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ap/merge-backend-opts'Junio C Hamano2010-01-201-5/+25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | * ap/merge-backend-opts: Document that merge strategies can now take their own options Extend merge-subtree tests to test -Xsubtree=dir. Make "subtree" part more orthogonal to the rest of merge-recursive. pull: Fix parsing of -X<option> Teach git-pull to pass -X<option> to git-merge git merge -X<option> git-merge-file --ours, --theirs Conflicts: git-compat-util.h
| * pull: Fix parsing of -X<option>Junio C Hamano2010-01-171-7/+14
| | | | | | | | | | | | | | As -X parameter can contain arbitrary $IFS characters, we need to properly quote it from the shell while forming the command line. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Teach git-pull to pass -X<option> to git-mergeAvery Pennarun2010-01-171-2/+15
| | | | | | | | | | | | | | | | This needs the usual sq then eval trick to allow IFS characters in the option. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Be more user-friendly when refusing to do something because of conflict.Matthieu Moy2010-01-121-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Various commands refuse to run in the presence of conflicts (commit, merge, pull, cherry-pick/revert). They all used to provide rough, and inconsistant error messages. A new variable advice.resolveconflict is introduced, and allows more verbose messages, pointing the user to the appropriate solution. For commit, the error message used to look like this: $ git commit foo.txt: needs merge foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169) foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030) foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4) error: Error building trees The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN option to make the output more consistant with the other porcelain commands, and catch the error in return, to stop with a clean error message. The next lines were displayed by a call to cache_tree_update(), which is not reached anymore if we noticed the conflict. The new output looks like: U foo.txt fatal: 'commit' is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm <file>' as appropriate to mark resolution and make a commit, or use 'git commit -a'. Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD exists instead of waiting for merge to complain. The behavior of merge and the test-case are slightly modified to reflect the usual flow: start with conflicts, fix them, and afterwards get rid of MERGE_HEAD, with different error messages at each stage. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'maint'Junio C Hamano2009-12-081-15/+33
|\ \ | | | | | | | | | | | | | | | * maint: add-interactive: fix deletion of non-empty files pull: clarify advice for the unconfigured error case
| * | pull: clarify advice for the unconfigured error caseJan Krüger2009-12-031-15/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When pull --rebase fails because it cannot find what branch to merge against, the error message implies we are trying to merge. Say "rebase against" instead of "merge with" to avoid confusion. The configuration suggested to remedy the situation uses a confusing syntax, with variables specified in the dotted form accepted by 'git config' but separated from their values by the '=' delimiter used by config files. Since the user will have to edit this output anyway, it is more helpful to provide a config file snippet to paste into an editor and modify. Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Revert recent "git merge <msg> HEAD <commit>..." deprecationJunio C Hamano2009-12-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit c0ecb07048ce2123589a2f077d296e8cf29a9570 "git-pull.sh: Fix call to git-merge for new command format" and commit b81e00a965c62ca72a4b9db425ee173de147808d "git-merge: a deprecation notice of the ancient command line syntax". They caused a "git pull" (without any arguments, and without any local commits---only to update to the other side) to warn that commit log message is ignored because the merge resulted in a fast-forward. Another possible solution is to add an extra option to "git merge" so that "git pull" can tell it that the message given is not coming from the end user (the canned message is passed just in case the merge resulted in a non-ff and caused commit), but I think it is easier _not_ to deprecate the old syntax. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | git-pull.sh: Fix call to git-merge for new command formatHorst H. von Brand2009-12-021-3/+3
| |/ |/| | | | | | | | | | | | | Now "git merge <msg> HEAD" is officially deprecated, we should clean our own use as well. Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'fc/doc-fast-forward'Junio C Hamano2009-11-151-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | * fc/doc-fast-forward: Use 'fast-forward' all over the place Conflicts: builtin-merge.c
| * | Use 'fast-forward' all over the placeFelipe Contreras2009-10-241-1/+1
| |/ | | | | | | | | | | | | It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Teach 'git merge' and 'git pull' the option --ff-onlyBjörn Gustavsson2009-10-301-2/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For convenience in scripts and aliases, add the option --ff-only to only allow fast-forwards (and up-to-date, despite the name). Disallow combining --ff-only and --no-ff, since they flatly contradict each other. Allow all other options to be combined with --ff-only (i.e. do not add any code to handle them specially), including the following options: * --strategy (one or more): As long as the chosen merge strategy results in up-to-date or fast-forward, the command will succeed. * --squash: I cannot imagine why anyone would want to squash commits only if fast-forward is possible, but I also see no reason why it should not be allowed. * --message: The message will always be ignored, but I see no need to explicitly disallow providing a redundant message. Acknowledgements: I did look at Yuval Kogman's earlier patch (107768 in gmane), mainly as shortcut to find my way in the code, but I did not copy anything directly. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: improve advice for unconfigured error caseJeff King2009-10-091-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several reasons a git-pull invocation might not have anything marked for merge: 1. We're not on a branch, so there is no branch configuration. 2. We're on a branch, but there is no configuration for this branch. 3. We fetched from the configured remote, but the configured branch to merge didn't get fetched (either it doesn't exist, or wasn't part of the fetch refspec). 4. We fetched from the non-default remote, but didn't specify a branch to merge. We can't use the configured one because it applies to the default remote. 5. We fetched from a specified remote, and a refspec was given, but it ended up not fetching anything (this is actually hard to do; if the refspec points to a remote branch and it doesn't exist, then fetch will fail and we never make it to this code path. But if you provide a wildcard refspec like refs/bogus/*:refs/remotes/origin/* then you can see this failure). We have handled (1) and (2) for some time. Recently, commit a6dbf88 added code to handle case (3). This patch handles cases (4) and (5), which previously just fell under other cases, producing a confusing message. While we're at it, let's rewrap the text for case (3), which looks terribly ugly as it is. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-pull: dead code removalJunio C Hamano2009-10-051-8/+1
| | | | | | | | | | | | | | | | Back when a74b170 (git-pull: disallow implicit merging to detached HEAD, 2007-01-15) added this check, $? referred to the error status of reading HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase, 2007-11-28) moved the command away from where the check is, and nobody noticed the breakage. Ever since, $? has always been 0 (tr at the end of the pipe to find merge_head never fails) and other case arms were never reached. These days, error_on_no_merge_candidates function is prepared to handle a detached HEAD case, which was what the code this patch removes used to handle. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: Clarify "helpful" message for another corner casev1.6.5-rc2Junio C Hamano2009-09-221-1/+6
| | | | | | | | | | | | When the remote branch we asked for merging did not exist in the set of fetched refs, we unconditionally hinted that it was because of lack of configuration. It is not necessarily so, and risks sending users for a wild goose chase. Make sure to check if that is indeed the case before telling a wild guess to the user. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* allow pull --rebase on branch yet to be bornJeff King2009-08-121-5/+13
| | | | | | | | | | | | | When doing a "pull --rebase", we check to make sure that the index and working tree are clean. The index-clean check compares the index against HEAD. The test erroneously reports dirtiness if we don't have a HEAD yet. In such an "unborn branch" case, by definition, a non-empty index won't be based on whatever we are pulling down from the remote, and will lose the local change. Just check if $GIT_DIR/index exists and error out. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: support rebased upstream + fetch + pull --rebaseSanti Béjar2009-07-191-3/+11
| | | | | | | | | | | | | | | | You cannot do a "git pull --rebase" with a rebased upstream, if you have already run "git fetch". Try to behave as if the "git fetch" was not run. In other words, find the fork point of the current branch, where the tip of upstream branch used to be, and use it as the upstream parameter of "git rebase". This patch computes the fork point by walking the reflog to find the first commit which is an ancestor of the current branch. Maybe there are smarter ways to compute it, but this is a straight forward implementation. Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'sb/pull-rebase'Junio C Hamano2009-06-201-5/+2
|\ | | | | | | | | | | | | * sb/pull-rebase: parse-remote: remove unused functions parse-remote: support default reflist in get_remote_merge_branch parse-remote: function to get the tracking branch to be merge
| * parse-remote: function to get the tracking branch to be mergeSanti Béjar2009-06-111-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The only user of get_remote_refs_for_fetch was "git pull --rebase" and it only wanted the tracking branch to be merge. So, add a simple function (get_remote_merge_branch) with this new meaning. No behavior changes. The new function behaves like the old code in "git pull --rebase". In particular, it only works with the default refspec mapping and with remote branches, not tags. Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | pull, rebase: simplify to use die()Stephen Boyd2009-06-141-4/+2
|/ | | | | Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Convert to use quiet option when availableDan Loewenherz2009-04-221-1/+1
| | | | | | | | A minor fix that eliminates usage of "2>/dev/null" when --quiet or -q has already been implemented. Signed-off-by: Dan Loewenherz <daniel.loewenherz@yale.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2009-04-081-17/+25
|\ | | | | | | | | | | | | | | | | | | * maint: Start 1.6.2.3 preparation process_{tree,blob}: Remove useless xstrdup calls git-pull.sh: better warning message for "git pull" on detached head. Conflicts: RelNotes
| * git-pull.sh: better warning message for "git pull" on detached head.Matthieu Moy2009-04-081-17/+25
| | | | | | | | | | | | | | | | | | Otherwise, git complains about not finding a branch to pull from in 'branch..merge', which is hardly understandable. While we're there, reword the sentences slightly. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-pull: Allow --stat and --no-stat to be used with --rebaseTor Arne Vestbø2009-03-021-5/+5
|/ | | | | | | Forwards the --stat, --no-stat, and --summary options on to git-rebase. Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* disallow providing multiple upstream branches to rebase, pull --rebaseJay Soffian2009-02-181-0/+5
| | | | | | | | It does not make sense to provide multiple upstream branches to either git pull --rebase, or to git rebase, so disallow both. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: use git rev-parse -qMiklos Vajna2008-12-031-4/+4
| | | | | Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Retain multiple -q/-v occurrences in git pullTuncer Ayaz2008-11-181-2/+2
| | | | | | | | To support counting -q/-v options in git pull retain them by concatenating. Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Teach/Fix pull/fetch -q/-v optionsTuncer Ayaz2008-11-141-3/+7
| | | | | | | | Implement git-pull --quiet and git-pull --verbose by adding the options to git-pull and fixing verbosity handling in git-fetch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: allow "git pull origin $something:$current_branch" into an unborn branchJunio C Hamano2008-10-171-2/+2
| | | | | | | | | | | | | | | | | | Some misguided documents floating on the Net suggest this sequence: mkdir newdir && cd newdir git init git remote add origin $url git pull origin master:master "git pull" has known about misguided "pull" that lets the underlying fetch update the current branch for a long time. It also has known about "git pull origin master" into a branch yet to be born. These two workarounds however were not aware of the existence of each other and did not work well together. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Ignore dirty submodule states in "git pull --rebase"Johannes Schindelin2008-07-231-3/+3
| | | | | | | | This is a companion patch to 6848d58c(Ignore dirty submodule states during rebase and stash). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make usage strings dash-lessStephan Beyer2008-07-131-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>
* pull --rebase: exit early when the working directory is dirtyJohannes Schindelin2008-05-221-0/+5
| | | | | | | | | | | When rebasing fails during "pull --rebase", you cannot just clean up the working directory and call "pull --rebase" again, since the remote branch was already fetched. Therefore, die early when the working directory is dirty. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* merge, pull: add '--(no-)log' command line optionSZEDER Gábor2008-04-121-3/+5
| | | | | | | | | | | These are the command line option equivalents of the 'merge.log' config variable. The patch also updates documentation and bash completion accordingly, and adds a test. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* merge, pull: introduce '--(no-)stat' optionSZEDER Gábor2008-04-121-9/+7
| | | | | | | | | | | | This option has the same effect as '--(no-)summary' (i.e. whether to show a diffsat at the end of the merge or not), and it is consistent with the '--stat' option of other git commands. Documentation, tests, and bash completion are updaed accordingly, and the old --summary option is marked as being deprected. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: pass --strategy along to to rebaseJay Soffian2008-02-221-1/+2
| | | | | | | rebase supports --strategy, so pull should pass the option along to it. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull --rebase: be cleverer with rebased upstream branchesJohannes Schindelin2008-01-261-1/+11
| | | | | | | | | When the upstream branch is tracked, we can detect if that branch was rebased since it was last fetched. Teach git to use that information to rebase from the old remote head onto the new remote head. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* "git pull --tags": error out with a better message.Junio C Hamano2007-12-281-26/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When "git pull --tags" is run without any other arguments, the standard error message "You told me to fetch and merge stuff but there is nothing to merge! You might want to fix your config" is given. While the error may be technically correct, fixing the config would not help, as "git pull --tags" itself tells "git fetch" not to use the configured refspecs. This commit makes "git pull --tags" to issue a different error message to avoid confusion. This is merely an interim solution. In the longer term, it would be a better approach to change the semantics of --tags option to make "git fetch" and "git pull" to: (1) behave as if no --tags was given (so an explicit refspec on the command line overrides configured ones, or no explicit refspecs on the command line takes configured ones); but (2) no auto-following of tags is made even when using configured refspecs; and (3) fetch all tags as not-for-merge entries". Then we would not need to have this separate error message, as the ordinary merge will happen even with the --tags option. Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status