summaryrefslogtreecommitdiff
path: root/git-pull.sh
AgeCommit message (Collapse)Author
2015-05-19Merge branch 'jc/merge'Junio C Hamano
"git merge FETCH_HEAD" learned that the previous "git fetch" could be to create an Octopus merge, i.e. recording multiple branches that are not marked as "not-for-merge"; this allows us to lose an old style invocation "git merge <msg> HEAD $commits..." in the implementation of "git pull" script; the old style syntax can now be deprecated. * jc/merge: merge: deprecate 'git merge <message> HEAD <commit>' syntax merge: handle FETCH_HEAD internally merge: decide if we auto-generate the message early in collect_parents() merge: make collect_parents() auto-generate the merge message merge: extract prepare_merge_message() logic out merge: narrow scope of merge_names merge: split reduce_parents() out of collect_parents() merge: clarify collect_parents() logic merge: small leakfix and code simplification merge: do not check argc to determine number of remote heads merge: clarify "pulling into void" special case t5520: test pulling an octopus into an unborn branch t5520: style fixes merge: simplify code flow merge: test the top-level merge driver
2015-04-29merge: deprecate 'git merge <message> HEAD <commit>' syntaxJunio C Hamano
We had this in "git merge" manual for eternity: 'git merge' <msg> HEAD <commit>... [This] syntax (<msg> `HEAD` <commit>...) is supported for historical reasons. Do not use it from the command line or in new scripts. It is the same as `git merge -m <msg> <commit>...`. With the update to "git merge" to make it understand what is recorded in FETCH_HEAD directly, including Octopus merge cases, we now can rewrite the use of this syntax in "git pull" with a simple "git merge FETCH_HEAD". Also there are quite a few fallouts in the test scripts, and it turns out that "git cvsimport" also uses this old syntax to record a merge. Judging from this result, I would not be surprised if dropping the support of the old syntax broke scripts people have written and been relying on for the past ten years. But at least we can start the deprecation process by throwing a warning message when the syntax is used. With luck, we might be able to drop the support in a few years. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01*.sh: respect $GIT_INDEX_FILENguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-28merge, pull: stop advising 'commit -a' in case of conflictMatthieu Moy
'git commit -a' is rarely a good way to mark conflicts as resolved: the user anyway has to go manually through the list of conflicts to do the actual resolution, and it is usually better to use "git add" on each files after doing the resolution. On the other hand, using 'git commit -a' is potentially dangerous, as it makes it very easy to mistakenly commit conflict markers without noticing, and even worse, the user may have started a merge while having local changes that do not overlap with it in the working tree. While we're there, synchronize the 'git pull' and 'git merge' messages: the first was ending with '... and make a commit.', but not the latter. Eventually, git should detect that conflicts have been resolved in the working tree and tailor these messages further. Not only "use git commit -a" could be resurected, but "Fix them up in the work tree" should be dropped when it happens. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-12Sync with maintJunio C Hamano
* maint: pull: do not abuse 'break' inside a shell 'case'
2014-06-12pull: do not abuse 'break' inside a shell 'case'Jacek Konieczny
It is not C. The code would break under mksh when 'pull.ff' is set: $ git pull /usr/lib/git-core/git-pull[67]: break: can't break Already up-to-date. Signed-off-by: Jacek Konieczny <jajcus@jajcus.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-23git-pull.sh: use the $( ... ) construct for command substitutionElia Pinto
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-27Merge branch 'bc/gpg-sign-everywhere'Junio C Hamano
Teach "--gpg-sign" option to many commands that create commits. * bc/gpg-sign-everywhere: pull: add the --gpg-sign option. rebase: add the --gpg-sign option rebase: parse options in stuck-long mode rebase: don't try to match -M option rebase: remove useless arguments check am: add the --gpg-sign option am: parse options in stuck-long mode git-sh-setup.sh: add variable to use the stuck-long mode cherry-pick, revert: add the --gpg-sign option
2014-02-27Merge branch 'da/pull-ff-configuration'Junio C Hamano
"git pull" learned to pay attention to pull.ff configuration variable. * da/pull-ff-configuration: pull: add --ff-only to the help text pull: add pull.ff configuration
2014-02-11pull: add the --gpg-sign option.brian m. carlson
git merge already allows us to sign commits, and git rebase has recently learned how to do so as well. Teach git pull to parse the -S/--gpg-sign option and pass this along to merge or rebase, as appropriate. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-17Merge branch 'jk/pull-rebase-using-fork-point'Junio C Hamano
Finishing touches so that an expected error message will not leak to the UI. * jk/pull-rebase-using-fork-point: pull: suppress error when no remoteref is found
2014-01-17pull: suppress error when no remoteref is foundJohn Keeping
Commit 48059e4 (pull: use merge-base --fork-point when appropriate, 2013-12-08) incorrectly assumes that get_remote_merge_branch will either yield a non-empty string or return an error, but there are circumstances where it will yield an empty string. The previous code then invoked git-rev-list with no arguments, which results in an error suppressed by redirecting stderr to /dev/null. Now we invoke git-merge-base with an empty branch name, which also results in an error. Suppress this in the same way. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-16pull: add --ff-only to the help textDavid Aguilar
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-16pull: add pull.ff configurationDavid Aguilar
Add a `pull.ff` configuration option that is analogous to the `merge.ff` option. This allows us to control the fast-forward behavior for pull-initiated merges only. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-27Merge branch 'jk/pull-rebase-using-fork-point'Junio C Hamano
* jk/pull-rebase-using-fork-point: rebase: use reflog to find common base with upstream pull: use merge-base --fork-point when appropriate
2013-12-09pull: use merge-base --fork-point when appropriateJohn Keeping
Since commit d96855f (merge-base: teach "--fork-point" mode, 2013-10-23) we can replace a shell loop in git-pull with a single call to git-merge-base. So let's do so. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch --tags: fetch tags *in addition to* other stuffMichael Haggerty
Previously, fetch's "--tags" option was considered equivalent to specifying the refspec "refs/tags/*:refs/tags/*" on the command line; in particular, it caused the remote.<name>.refspec configuration to be ignored. But it is not very useful to fetch tags without also fetching other references, whereas it *is* quite useful to be able to fetch tags *in addition to* other references. So change the semantics of this option to do the latter. If a user wants to fetch *only* tags, then it is still possible to specifying an explicit refspec: git fetch <remote> 'refs/tags/*:refs/tags/*' Please note that the documentation prior to 1.8.0.3 was ambiguous about this aspect of "fetch --tags" behavior. Commit f0cb2f137c 2012-12-14 fetch --tags: clarify documentation made the documentation match the old behavior. This commit changes the documentation to match the new behavior. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17Merge branch 'fc/trivial'Junio C Hamano
* fc/trivial: pull: use $curr_branch_short more add: trivial style cleanup reset: trivial style cleanup branch: trivial style fix reset: trivial refactoring
2013-09-08pull: use $curr_branch_short moreRené Scharfe
One of the first things git-pull.sh does is setting $curr_branch to the target of HEAD and $curr_branch_short to the same but with the leading "refs/heads/" removed. Simplify the code by using $curr_branch_short instead of setting $curr_branch to the same shortened value. The only other use of $curr_branch in that function doesn't have to be replaced with $curr_branch_short because it just checks if the string is empty. That property is the same with or without the prefix unless HEAD points to "refs/heads/" alone, which is invalid. Noticed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04pull: allow pull to preserve merges when rebasingStephen Haberman
If a user is working on master, and has merged in their feature branch, but now has to "git pull" because master moved, with pull.rebase their feature branch will be flattened into master. This is because "git pull" currently does not know about rebase's preserve merges flag, which would avoid this behavior, as it would instead replay just the merge commit of the feature branch onto the new master, and not replay each individual commit in the feature branch. Add a --rebase=preserve option, which will pass along --preserve-merges to rebase. Also add 'preserve' to the allowed values for the pull.rebase config setting. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12Merge branch 'jk/pull-to-integrate'Junio C Hamano
* jk/pull-to-integrate: pull: change the description to "integrate" changes push: avoid suggesting "merging" remote changes
2013-07-08pull: change the description to "integrate" changesJohn Keeping
Since git-pull learned the --rebase option it has not just been about merging changes from a remote repository (where "merge" is in the sense of "git merge"). Change the description to use "integrate" instead of "merge" in order to reflect this. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-27Merge branch 'jk/pull-into-dirty-unborn'Junio C Hamano
"git pull" into nothing trashed "local changes" that were in the index, and this avoids it. * jk/pull-into-dirty-unborn: pull: merge into unborn by fast-forwarding from empty tree pull: update unborn branch tip after index
2013-06-20pull: merge into unborn by fast-forwarding from empty treeThomas Rast
The logic for pulling into an unborn branch was originally designed to be used on a newly-initialized repository (d09e79c, git-pull: allow pulling into an empty repository, 2006-11-16). It thus did not initially deal with uncommitted changes in the unborn branch. The case of an _unstaged_ untracked file was fixed by 4b3ffe5 (pull: do not clobber untracked files on initial pull, 2011-03-25). However, it still clobbered existing staged files, both when the file exists in the merged commit (it will be overwritten), and when it does not (it will be deleted). We fix this by doing a two-way merge, where the "current" side of the merge is an empty tree, and the "target" side is HEAD (already updated to FETCH_HEAD at this point). This amounts to claiming that all work in the index was done vs. an empty tree, and thus all content of the index is precious. Note that this use of read-tree just gives us protection against overwriting index and working tree changes. It will not actually result in a 3-way merge conflict in the index. This is fine, as this is a rare situation, and the conflict would not be interesting anyway (it must, by definition, be an add/add conflict with the whole content conflicting). And it makes it simpler for the user to recover, as they have no HEAD to "git reset" back to. Reported-by: Stefan Schüßler <mail@stefanschuessler.de> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-20pull: update unborn branch tip after indexJeff King
When commit d09e79c taught git to pull into an unborn branch, it first updated the unborn branch to point at the pulled commit, and then used read-tree to update the index and working tree. That ordering made sense, since any failure of the latter step would be due to filesystem errors, and one could then recover with "git reset --hard". Later, commit 4b3ffe5 added extra safety for existing files in the working tree by asking read-tree to bail out when it would overwrite such a file. This error mode is much less "your pull failed due to random errors" and more like "we reject this pull because it would lose data". In that case, it makes sense not to update the HEAD ref, just as a regular rejected merge would do. This patch reverses the order of the update-ref and read-tree calls, so that we do not touch the HEAD ref at all if a merge is rejected. This also means that we would not update HEAD in case of a transient filesystem error, but those are presumably less rare (and one can still recover by repeating the pull, or by accessing FETCH_HEAD directly). While we're reorganizing the code, we can drop the "exit 1" from the end of our command chain. We exit immediately either way, and just calling exit without an argument will use the exit code from the last command. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01merge/pull: verify GPG signatures of commits being mergedSebastian Götte
When --verify-signatures is specified on the command-line of git-merge or git-pull, check whether the commits being merged have good gpg signatures and abort the merge in case they do not. This allows e.g. auto-deployment from untrusted repo hosts. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-17pull: Apply -q and -v options to rebase mode as wellPeter Eisentraut
git pull passed -q and -v only to git merge, but they can be useful for git rebase as well, so pass them there, too. In particular, using -q shuts up the "Already up-to-date." message. Especially, a new test script runs the same "pull --rebase" twice to make sure both cases are quiet, when it has something to fetch and when it is already up to date. Signed-off-by: Peter Eisentraut <peter@eisentraut.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-25git-pull: Avoid merge-base on detached headPhil Hord
git pull --rebase does some clever tricks to find the base for $upstream, but it forgets that we may not have any branch at all. When this happens, git merge-base reports its "usage" help in the middle of an otherwise successful rebase operation, because git-merge is called with one too few parameters. Since we do not need the merge-base trick in the case of a detached HEAD, detect this condition and bypass the clever trick and the usage noise. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Jeff King <peff@peff.net>
2012-03-05Make git-{pull,rebase} message without tracking information friendlierCarlos Martín Nieto
The current message is too long and at too low a level for anybody to understand it if they don't know about the configuration format already. The text about setting up a remote is superfluous and doesn't help understand or recover from the error that has happened. Show the usage more prominently and explain how to set up the tracking information. If there is only one remote, that name is used instead of the generic <remote>. Also simplify the message we print on detached HEAD to remove unnecessary information which is better left for the documentation. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-13"git pull" doesn't know "--edit"Linus Torvalds
Ok, so now "git merge" defaults to editing when interactive - lovely. But when testing that, I noticed that while you can say git merge --[no-]edit ..branch.. that does not work with "git pull". You get a message like error: unknown option `no-edit' usage: git fetch [<options>] [<repository> [<refspec>...]] or: git fetch [<options>] <group> or: git fetch --multiple [<options>] [(<repository> | <group>)...] or: git fetch --all [<options>] -v, --verbose be more verbose -q, --quiet be more quiet --all fetch from all remotes ... which is because that stupid shell script doesn't know about the new flags, and just passes it to "git fetch" instead. Now, I really wanted to just make "git pull" a built-in instead of that nasty shell script, but I'm lazy. So here's the trivial updates to git-pull.sh to at least teach it about -e/--edit/--no-edit. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'ab/pull-rebase-config'Junio C Hamano
* ab/pull-rebase-config: pull: introduce a pull.rebase option to enable --rebase
2011-11-07pull: introduce a pull.rebase option to enable --rebaseÆvar Arnfjörð Bjarmason
Currently we either need to set branch.<name>.rebase for existing branches if we'd like "git pull" to mean "git pull --rebase", or have the forethought of setting "branch.autosetuprebase" before we create the branch. Introduce a "pull.rebase" option to globally configure "git pull" to mean "git pull --rebase" for any branch. This option will be considered at a lower priority than branch.<name>.rebase, i.e. we could set pull.rebase=true and branch.<name>.rebase=false and the latter configuration option would win. Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com> Reviewed-by: Fernando Vezzosi <buccia@repnz.net> Reviewed-by: Eric Herman <eric@freesa.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-18Merge branch 'jk/pull-rebase-with-work-tree'Junio C Hamano
* jk/pull-rebase-with-work-tree: pull,rebase: handle GIT_WORK_TREE better Conflicts: git-pull.sh
2011-10-13pull,rebase: handle GIT_WORK_TREE betterJeff King
You can't currently run git-pull or git-rebase from outside of the work tree, even with GIT_WORK_TREE set, due to an overeager require_work_tree function. Commit e2eb527 documents this problem and provides the infrastructure for a fix, but left it to later commits to audit and update individual scripts. Changing these scripts to use require_work_tree_exists is easy to verify. We immediately call cd_to_toplevel, anyway. Therefore no matter which function we use, the state afterwards is one of: 1. We have a work tree, and we are at the top level. 2. We don't have a work tree, and we have died. The only catch is that we must also make sure no code that ran before the cd_to_toplevel assumed that we were already in the working tree. In this case, we will only have included shell libraries and called set_reflog_action, neither of which care about the current working directory at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05use -h for synopsis and --help for manpage consistentlyClemens Buchacher
A few scripted Porcelain implementations pretend as if the routine to show their own help messages are triggered upon "git cmd --help", but a command line parser of "git" will hijack such a request and shows the manpage for the cmd subcommand. Leaving the code to handle such input is simply misleading. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-25Merge branch 'js/i18n-scripts'Junio C Hamano
* js/i18n-scripts: submodule: take advantage of gettextln and eval_gettextln. stash: take advantage of eval_gettextln pull: take advantage of eval_gettextln git-am: take advantage of gettextln and eval_gettextln. gettext: add gettextln, eval_gettextln to encode common idiom
2011-08-08Merge branch 'oa/pull-reflog'Junio C Hamano
* oa/pull-reflog: pull: remove extra space from reflog message Conflicts: git-pull.sh
2011-08-08pull: take advantage of eval_gettextlnJon Seymour
Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-01pull: remove extra space from reflog messageOri Avtalion
When executing "git pull" with no arguments, the reflog message was: "pull : Fast-forward" Signed-off-by: Ori Avtalion <ori@avtalion.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-pull eval_gettext + warning messageÆvar Arnfjörð Bjarmason
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-pull eval_gettext + die messageÆvar Arnfjörð Bjarmason
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-pull die messagesÆvar Arnfjörð Bjarmason
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-pull add git-sh-i18nÆvar Arnfjörð Bjarmason
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-28Merge branch 'mz/rebase'Junio C Hamano
* mz/rebase: (34 commits) rebase: define options in OPTIONS_SPEC Makefile: do not install sourced rebase scripts rebase: use @{upstream} if no upstream specified rebase -i: remove unnecessary state rebase-root rebase -i: don't read unused variable preserve_merges git-rebase--am: remove unnecessary --3way option rebase -m: don't print exit code 2 when merge fails rebase -m: remember allow_rerere_autoupdate option rebase: remember strategy and strategy options rebase: remember verbose option rebase: extract code for writing basic state rebase: factor out sub command handling rebase: make -v a tiny bit more verbose rebase -i: align variable names rebase: show consistent conflict resolution hint rebase: extract am code to new source file rebase: extract merge code to new source file rebase: remove $branch as synonym for $orig_head rebase -i: support --stat rebase: factor out call to pre-rebase hook ...
2011-04-04Merge branch 'jl/submodule-fetch-on-demand'Junio C Hamano
* jl/submodule-fetch-on-demand: fetch/pull: Describe --recurse-submodule restrictions in the BUGS section submodule update: Don't fetch when the submodule commit is already present fetch/pull: Don't recurse into a submodule when commits are already present Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option config: teach the fetch.recurseSubmodules option the 'on-demand' value fetch/pull: Add the 'on-demand' value to the --recurse-submodules option fetch/pull: recurse into submodules when necessary Conflicts: builtin/fetch.c submodule.c
2011-03-25pull: do not clobber untracked files on initial pullJeff King
For a pull into an unborn branch, we do not use "git merge" at all. Instead, we call read-tree directly. However, we used the --reset parameter instead of "-m", which turns off the safety features. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-20Merge branch 'jk/merge-rename-ux'Junio C Hamano
* 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
2011-03-09fetch/pull: Add the 'on-demand' value to the --recurse-submodules optionJens Lehmann
Until now the --recurse-submodules option could only be used to either fetch all populated submodules recursively or to disable recursion completely. As fetch and pull now by default just fetch those submodules for which new commits have been fetched in the superproject, a command line option to enforce that behavior is needed to be able to override configuration settings. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21pull: propagate --progress to mergeJeff King
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>
2011-02-15pull: do not display fetch usage on --help-allMichael J Gruber
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>