aboutsummaryrefslogtreecommitdiff
path: root/git-pull.sh
Commit message (Collapse)AuthorAge
* Sync with maintJunio C Hamano2014-06-12
|\ | | | | | | | | * maint: pull: do not abuse 'break' inside a shell 'case'
| * pull: do not abuse 'break' inside a shell 'case'Jacek Konieczny2014-06-12
| | | | | | | | | | | | | | | | | | | | | | 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>
* | git-pull.sh: use the $( ... ) construct for command substitutionElia Pinto2014-04-23
|/ | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'bc/gpg-sign-everywhere'Junio C Hamano2014-02-27
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * pull: add the --gpg-sign option.brian m. carlson2014-02-11
| | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'da/pull-ff-configuration'Junio C Hamano2014-02-27
|\ \ | |/ |/| | | | | | | | | | | | | "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
| * pull: add --ff-only to the help textDavid Aguilar2014-01-15
| | | | | | | | | | Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * pull: add pull.ff configurationDavid Aguilar2014-01-15
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jk/pull-rebase-using-fork-point'Junio C Hamano2014-01-17
|\ \ | | | | | | | | | | | | | | | | | | | | | 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
| * | pull: suppress error when no remoteref is foundJohn Keeping2014-01-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'jk/pull-rebase-using-fork-point'Junio C Hamano2013-12-27
|\ \ \ | |/ / | | | | | | | | | | | | * jk/pull-rebase-using-fork-point: rebase: use reflog to find common base with upstream pull: use merge-base --fork-point when appropriate
| * | pull: use merge-base --fork-point when appropriateJohn Keeping2013-12-09
| |/ | | | | | | | | | | | | | | | | 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>
* | fetch --tags: fetch tags *in addition to* other stuffMichael Haggerty2013-10-30
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'fc/trivial'Junio C Hamano2013-09-17
|\ | | | | | | | | | | | | | | | | * fc/trivial: pull: use $curr_branch_short more add: trivial style cleanup reset: trivial style cleanup branch: trivial style fix reset: trivial refactoring
| * pull: use $curr_branch_short moreRené Scharfe2013-09-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | pull: allow pull to preserve merges when rebasingStephen Haberman2013-09-04
|/ | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'jk/pull-to-integrate'Junio C Hamano2013-07-12
|\ | | | | | | | | | | * jk/pull-to-integrate: pull: change the description to "integrate" changes push: avoid suggesting "merging" remote changes
| * pull: change the description to "integrate" changesJohn Keeping2013-07-08
| | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jk/pull-into-dirty-unborn'Junio C Hamano2013-06-27
|\ \ | |/ |/| | | | | | | | | | | | | "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
| * pull: merge into unborn by fast-forwarding from empty treeThomas Rast2013-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * pull: update unborn branch tip after indexJeff King2013-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | merge/pull: verify GPG signatures of commits being mergedSebastian Götte2013-03-31
|/ | | | | | | | | | 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>
* pull: Apply -q and -v options to rebase mode as wellPeter Eisentraut2013-03-16
| | | | | | | | | | | | | 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>
* git-pull: Avoid merge-base on detached headPhil Hord2012-10-25
| | | | | | | | | | | | | | | | 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>
* Make git-{pull,rebase} message without tracking information friendlierCarlos Martín Nieto2012-03-04
| | | | | | | | | | | | | | | | | | 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>
* "git pull" doesn't know "--edit"Linus Torvalds2012-02-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'ab/pull-rebase-config'Junio C Hamano2011-12-09
|\ | | | | | | | | * ab/pull-rebase-config: pull: introduce a pull.rebase option to enable --rebase
| * pull: introduce a pull.rebase option to enable --rebaseÆvar Arnfjörð Bjarmason2011-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jk/pull-rebase-with-work-tree'Junio C Hamano2011-10-17
|\ \ | | | | | | | | | | | | | | | | | | | | | * jk/pull-rebase-with-work-tree: pull,rebase: handle GIT_WORK_TREE better Conflicts: git-pull.sh
| * | pull,rebase: handle GIT_WORK_TREE betterJeff King2011-10-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | use -h for synopsis and --help for manpage consistentlyClemens Buchacher2011-10-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'js/i18n-scripts'Junio C Hamano2011-08-25
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | pull: take advantage of eval_gettextlnJon Seymour2011-08-08
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'oa/pull-reflog'Junio C Hamano2011-08-08
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | * oa/pull-reflog: pull: remove extra space from reflog message Conflicts: git-pull.sh
| * | | pull: remove extra space from reflog messageOri Avtalion2011-08-01
| | |/ | |/| | | | | | | | | | | | | | | | | | | 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>
* | | i18n: git-pull eval_gettext + warning messageÆvar Arnfjörð Bjarmason2011-05-21
| | | | | | | | | | | | | | | Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | i18n: git-pull eval_gettext + die messageÆvar Arnfjörð Bjarmason2011-05-21
| | | | | | | | | | | | | | | Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | i18n: git-pull die messagesÆvar Arnfjörð Bjarmason2011-05-21
| | | | | | | | | | | | | | | Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | i18n: git-pull add git-sh-i18nÆvar Arnfjörð Bjarmason2011-05-21
|/ / | | | | | | | | Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'mz/rebase'Junio C Hamano2011-04-28
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 ...
| * | rebase: use @{upstream} if no upstream specifiedMartin von Zweigbergk2011-02-10
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'git rebase' without arguments is currently not supported. Make it default to 'git rebase @{upstream}'. That is also what 'git pull [--rebase]' defaults to, so it only makes sense that 'git rebase' defaults to the same thing. Defaulting to @{upstream} will make it possible to run e.g. 'git rebase -i' without arguments, which is probably a quite common use case. It also improves the scenario where you have multiple branches that rebase against a remote-tracking branch, where you currently have to choose between the extra network delay of 'git pull' or the slightly awkward keys to enter 'git rebase @{u}'. The error reporting when no upstream is configured for the current branch or when no branch is checked out is reused from git-pull.sh. A function is extracted into git-parse-remote.sh for this purpose. Helped-by: Yann Dirson <ydirson@altern.org> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jl/submodule-fetch-on-demand'Junio C Hamano2011-04-04
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | fetch/pull: Add the 'on-demand' value to the --recurse-submodules optionJens Lehmann2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | pull: do not clobber untracked files on initial pullJeff King2011-03-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'jk/merge-rename-ux'Junio C Hamano2011-03-19
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | * 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-21
| |/ | | | | | | | | | | | | | | 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-15
|/ | | | | | | | | | | | 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-16
|\ | | | | | | | | | | | | | | | | | | | | * 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-12
| | | | | | | | | | | | | | | | | | 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-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-16 20:32:38 +0000