summaryrefslogtreecommitdiff
path: root/git-pull.sh
AgeCommit message (Collapse)AuthorFilesLines
2009-12-03pull: clarify advice for the unconfigured error caseLibravatar Jan Krüger1-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>
2009-10-09pull: improve advice for unconfigured error caseLibravatar Jeff King1-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>
2009-10-05git-pull: dead code removalLibravatar Junio C Hamano1-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>
2009-09-22pull: Clarify "helpful" message for another corner caseLibravatar Junio C Hamano1-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>
2009-08-12allow pull --rebase on branch yet to be bornLibravatar Jeff King1-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>
2009-07-19pull: support rebased upstream + fetch + pull --rebaseLibravatar Santi Béjar1-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>
2009-06-20Merge branch 'sb/pull-rebase'Libravatar Junio C Hamano1-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
2009-06-14pull, rebase: simplify to use die()Libravatar Stephen Boyd1-4/+2
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-11parse-remote: function to get the tracking branch to be mergeLibravatar Santi Béjar1-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>
2009-04-22Convert to use quiet option when availableLibravatar Dan Loewenherz1-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>
2009-04-08Merge branch 'maint'Libravatar Junio C Hamano1-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
2009-04-08git-pull.sh: better warning message for "git pull" on detached head.Libravatar Matthieu Moy1-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>
2009-03-02git-pull: Allow --stat and --no-stat to be used with --rebaseLibravatar Tor Arne Vestbø1-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>
2009-02-18disallow providing multiple upstream branches to rebase, pull --rebaseLibravatar Jay Soffian1-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>
2008-12-03pull: use git rev-parse -qLibravatar Miklos Vajna1-4/+4
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-18Retain multiple -q/-v occurrences in git pullLibravatar Tuncer Ayaz1-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>
2008-11-14Teach/Fix pull/fetch -q/-v optionsLibravatar Tuncer Ayaz1-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>
2008-10-17pull: allow "git pull origin $something:$current_branch" into an unborn branchLibravatar Junio C Hamano1-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>
2008-07-23Ignore dirty submodule states in "git pull --rebase"Libravatar Johannes Schindelin1-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>
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-05-22pull --rebase: exit early when the working directory is dirtyLibravatar Johannes Schindelin1-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>
2008-04-12merge, pull: add '--(no-)log' command line optionLibravatar SZEDER Gábor1-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>
2008-04-12merge, pull: introduce '--(no-)stat' optionLibravatar SZEDER Gábor1-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>
2008-02-22pull: pass --strategy along to to rebaseLibravatar Jay Soffian1-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>
2008-01-26pull --rebase: be cleverer with rebased upstream branchesLibravatar Johannes Schindelin1-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>
2007-12-28"git pull --tags": error out with a better message.Libravatar Junio C Hamano1-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>
2007-11-28Teach 'git pull' about --rebaseLibravatar Johannes Schindelin1-1/+10
When calling 'git pull' with the '--rebase' option, it performs a fetch + rebase instead of a fetch + merge. This behavior is more desirable than fetch + pull when a topic branch is ready to be submitted and needs to be update. fetch + rebase might also be considered a better workflow with shared repositories in any case, or for contributors to a centrally managed repository, such as WINE's. As a convenience, you can set the default behavior for a branch by defining the config variable branch.<name>.rebase, which is interpreted as a bool. This setting can be overridden on the command line by --rebase and --no-rebase. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-06scripts: Add placeholders for OPTIONS_SPECLibravatar Junio C Hamano1-0/+1
--text follows this line-- These commands currently lack OPTIONS_SPEC; allow people to easily list with "git grep 'OPTIONS_SPEC=$'" what they can help improving. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29Teach git-pull about --[no-]ff, --no-squash and --commitLibravatar Lars Hjemli1-3/+11
These options are supported by git-merge, but git-pull didn't know about them. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02Make git-pull complain and give advice when there is nothing to merge withLibravatar Federico Mena Quintero1-4/+18
Signed-off-by: Federico Mena Quintero <federico@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23Supplant the "while case ... break ;; esac" idiomLibravatar David Kastrup1-3/+3
A lot of shell scripts contained stuff starting with while case "$#" in 0) break ;; esac and similar. I consider breaking out of the condition instead of the body od the loop ugly, and the implied "true" value of the non-matching case is not really obvious to humans at first glance. It happens not to be obvious to some BSD shells, either, but that's because they are not POSIX-compliant. In most cases, this has been replaced by a straight condition using "test". "case" has the advantage of being faster than "test" on vintage shells where "test" is not a builtin. Since none of them is likely to run the git scripts, anyway, the added readability should be worth the change. A few loops have had their termination condition expressed differently. Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-8/+8
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-24Add a configuration option to control diffstat after mergeLibravatar Alex Riesen1-0/+3
The diffstat can be controlled either with command-line options (--summary|--no-summary) or with merge.diffstat. The default is left as it was: diffstat is active by default. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15git-pull: disallow implicit merging to detached HEADLibravatar Jeff King1-2/+11
Instead, we complain to the user and suggest that they explicitly specify the remote and branch. We depend on the exit status of git-symbolic-ref, so let's go ahead and document that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12Allow whole-tree operations to be started from a subdirectoryLibravatar Junio C Hamano1-1/+3
This updates five commands (merge, pull, rebase, revert and cherry-pick) so that they can be started from a subdirectory. This may not actually be what we want to do. These commands are inherently whole-tree operations, and an inexperienced user may mistakenly expect a "git pull" from a subdirectory would merge only the subdirectory the command started from. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10Disallow working directory commands in a bare repository.Libravatar Shawn O. Pearce1-0/+1
If the user tries to run a porcelainish command which requires a working directory in a bare repository they may get unexpected results which are difficult to predict and may differ from command to command. Instead we should detect that the current repository is a bare repository and refuse to run the command there, as there is no working directory associated with it. [jc: updated Shawn's original somewhat -- bugs are mine.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-01fail pull/merge early in the middle of conflicted mergeLibravatar Junio C Hamano1-0/+3
After a pull that results in a conflicted merge, a new user often tries another "git pull" in desperation. When the index is unmerged, merge backends correctly bail out without touching either index nor the working tree, so this does not make the wound any worse. The user will however see several lines of messsages during this process, such as "filename: needs merge", "you need to resolve your current index first", "Merging...", and "Entry ... would be overwritten by merge. Cannot merge.". They are unnecessarily alarming, and cause useful conflict messages from the first pull scroll off the top of the terminal. This changes pull and merge to run "git-ls-files -u" upfront and stop them much earlier than we currently do. Old timers may know better and would not to try pulling again before cleaning things up; this change adds extra overhead that is unnecessary for them. But this would be worth paying for to save new people from needless confusion. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28Allow git-merge to select the default strategy.Libravatar Shawn O. Pearce1-18/+0
Now that git-merge knows how to use the pull.{twohead,octopus} configuration options to select the default merge strategy there is no reason for git-pull to do the same immediately prior to invoking git-merge. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28Ensure `git-pull` fails if `git-merge` fails.Libravatar Shawn O. Pearce1-1/+1
If git-merge exits with a non-zero exit status so should git-pull. This way the caller of git-pull knows the task did not complete successfully simply by checking the process exit status. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28Use GIT_REFLOG_ACTION environment variable instead.Libravatar Shawn O. Pearce1-3/+3
Junio rightly pointed out that the --reflog-action parameter was starting to get out of control, as most porcelain code needed to hand it to other porcelain and plumbing alike to ensure the reflog contained the top-level user action and not the lower-level actions it invoked. At Junio's suggestion we are introducing the new set_reflog_action function to all shell scripts, allowing them to declare early on what their default reflog name should be, but this setting only takes effect if the caller has not already set the GIT_REFLOG_ACTION environment variable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19Move "no merge candidate" warning into git-pullLibravatar Josef Weidendorfer1-0/+4
The warning triggered even when running "git fetch" only when resulting .git/FETCH_HEAD only contained branches marked as 'not-for-merge'. Signed-off-by: Josef Weidendorfer <weidendo@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-16git-pull: allow pulling into an empty repositoryLibravatar Linus Torvalds1-2/+14
We used to complain that we cannot merge anything we fetched with a local branch that does not exist yet. Just treat the case as a natural extension of fast forwarding and make the local branch'es tip point at the same commit we just fetched. After all an empty repository without an initial commit is an ancestor of any commit. [jc: I added a trivial test. We've become sloppy but we should stick to the discipline of covering new behaviour with new tests. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-10git-pull: we say commit X, not X commit.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-11Log ref changes made by git-merge and git-pull.Libravatar Shawn Pearce1-1/+2
When git-merge updates HEAD as a result of a merge record what happened during the merge into the reflog associated with HEAD (if any). The log reports who caused the update (git-merge or git-pull, by invoking git-merge), what the remote ref names were and the type of merge process used. The merge information can be useful when reviewing a reflog for a branch such as `master` where fast forward and trivial in index merges might be common as the user tracks an upstream. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10Log ref changes made by git-fetch and git-pull.Libravatar Shawn Pearce1-1/+1
When git-fetch updates a reference record in the associated reflog what type of update took place and who caused it (git-fetch or git-pull, by invoking git-fetch). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27Fix expr usage for FreeBSDLibravatar Dennis Stosberg1-1/+1
Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24git-merge --squashLibravatar Junio C Hamano1-2/+5
Some people tend to do many little commits on a topic branch, recording all the trials and errors, and when the topic is reasonably cooked well, would want to record the net effect of the series as one commit on top of the mainline, removing the cruft from the history. The topic is then abandoned or forked off again from that point at the mainline. The barebone porcelainish that comes with core git tools does not officially support such operation, but you can fake it by using "git pull --no-merge" when such a topic branch is not a strict superset of the mainline, like this: git checkout mainline git pull --no-commit . that-topic-branch : fix conflicts if any rm -f .git/MERGE_HEAD git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged This however does not work when the topic branch is a fast forward of the mainline, because normal "git pull" will never create a merge commit in such a case, and there is nothing special --no-commit could do to begin with. This patch introduces a new option, --squash, to support such a workflow officially in both fast-forward case and true merge case. The user-level operation would be the same in both cases: git checkout mainline git pull --squash . that-topic-branch : fix conflicts if any -- naturally, there would be : no conflict if fast forward. git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged When the current branch is already up-to-date with respect to the other branch, there truly is nothing to do, so the new option does not have any effect. This was brought up in #git IRC channel recently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24git-pull: abort when fmt-merge-msg fails.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-22git-pull: reword "impossible to fast-forward" message.Libravatar Junio C Hamano1-1/+7
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-22git-pull: further safety while on tracking branch.Libravatar Junio C Hamano1-1/+3
Running 'git pull' while on the tracking branch has a built-in safety valve to fast-forward the index and working tree to match the branch head, but it errs on the safe side too cautiously. Signed-off-by: Junio C Hamano <junkio@cox.net>