summaryrefslogtreecommitdiff
path: root/git-pull.sh
Commit message (Collapse)AuthorAgeFilesLines
* pull: remove redirection to git-pull.shPaul Tan2015-06-181-333/+0
| | | | | | | | | | | | | | At the beginning of the rewrite of git-pull.sh to C, we introduced a redirection to git-pull.sh if the environment variable _GIT_USE_BUILTIN_PULL was not defined in order to not break test scripts that relied on a functional git-pull. Now that all of git-pull's functionality has been re-implemented in builtin/pull.c, remove this redirection, and retire the old git-pull.sh into contrib/examples/. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'pt/pull-ff-vs-merge-ff'Junio C Hamano2015-05-261-1/+4
|\ | | | | | | | | | | | | | | | | The pull.ff configuration was supposed to override the merge.ff configuration, but it didn't. * pt/pull-ff-vs-merge-ff: pull: parse pull.ff as a bool or string pull: make pull.ff=true override merge.ff
| * pull: parse pull.ff as a bool or stringpt/pull-ff-vs-merge-ffPaul Tan2015-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since b814da8 (pull: add pull.ff configuration, 2014-01-15) git-pull supported setting --(no-)ff via the pull.ff configuration value. However, as it only matches the string values of "true" and "false", it does not support other boolean aliases such as "on", "off", "1", "0". This is inconsistent with the merge.ff setting, which supports these aliases. Fix this by using the bool_or_string_config function to retrieve the value of pull.ff. Signed-off-by: Paul Tan <pyokagan@gmail.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * pull: make pull.ff=true override merge.ffPaul Tan2015-05-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since b814da8 (pull: add pull.ff configuration, 2014-01-15), running git-pull with the configuration pull.ff=false or pull.ff=only is equivalent to passing --no-ff and --ff-only to git-merge. However, if pull.ff=true, no switch is passed to git-merge. This leads to the confusing behavior where pull.ff=false or pull.ff=only is able to override merge.ff, while pull.ff=true is unable to. Fix this by adding the --ff switch if pull.ff=true, and add a test to catch future regressions. Furthermore, clarify in the documentation that pull.ff overrides merge.ff. Signed-off-by: Paul Tan <pyokagan@gmail.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'pt/pull-log-n'Junio C Hamano2015-05-261-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | "git pull --log" and "git pull --no-log" worked as expected, but "git pull --log=20" did not. * pt/pull-log-n: pull: handle --log=<n>
| * | pull: handle --log=<n>pt/pull-log-nPaul Tan2015-05-181-2/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since efb779f (merge, pull: add '--(no-)log' command line option, 2008-04-06) git-pull supported the (--no-)log switch and would pass it to git-merge. 96e9420 (merge: Make '--log' an integer option for number of shortlog entries, 2010-09-08) implemented support for the --log=<n> switch, which would explicitly set the number of shortlog entries. However, git-pull does not recognize this option, and will instead pass it to git-fetch, leading to "unknown option" errors. Fix this by matching --log=* in addition to --log and --no-log. Implement a test for this use case. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'pt/pull-tags-error-diag'Junio C Hamano2015-05-221-9/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | There was a dead code that used to handle "git pull --tags" and show special-cased error message, which was made irrelevant when the semantics of the option changed back in Git 1.9 days. * pt/pull-tags-error-diag: pull: remove --tags error in no merge candidates case
| * | pull: remove --tags error in no merge candidates casept/pull-tags-error-diagPaul Tan2015-05-141-9/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 441ed41 ("git pull --tags": error out with a better message., 2007-12-28), git pull --tags would print a different error message if git-fetch did not return any merge candidates: It doesn't make sense to pull all tags; you probably meant: git fetch --tags This is because at that time, git-fetch --tags would override any configured refspecs, and thus there would be no merge candidates. The error message was thus introduced to prevent confusion. However, since c5a84e9 (fetch --tags: fetch tags *in addition to* other stuff, 2013-10-30), git fetch --tags would fetch tags in addition to any configured refspecs. Hence, if any no merge candidates situation occurs, it is not because --tags was set. As such, this special error message is now irrelevant. To prevent confusion, remove this error message. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/merge'Junio C Hamano2015-05-191-2/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
| * | merge: deprecate 'git merge <message> HEAD <commit>' syntaxjc/mergeJunio C Hamano2015-04-291-2/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | *.sh: respect $GIT_INDEX_FILENguyễn Thái Ngọc Duy2014-12-011-1/+1
|/ | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* merge, pull: stop advising 'commit -a' in case of conflictmm/discourage-commit-a-to-finish-conflict-resolutionMatthieu Moy2014-08-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | '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>
* Sync with maintJunio C Hamano2014-06-121-2/+0
|\ | | | | | | | | * maint: pull: do not abuse 'break' inside a shell 'case'
| * pull: do not abuse 'break' inside a shell 'case'Jacek Konieczny2014-06-121-2/+0
| | | | | | | | | | | | | | | | | | | | | | 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-231-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | 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-271-1/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.bc/gpg-sign-everywherebrian m. carlson2014-02-111-1/+12
| | | | | | | | | | | | | | | | | | 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-271-1/+16
|\ \ | |/ |/| | | | | | | | | | | | | "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 textda/pull-ff-configurationDavid Aguilar2014-01-151-1/+1
| | | | | | | | | | Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * pull: add pull.ff configurationDavid Aguilar2014-01-151-0/+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-171-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | 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 foundjk/pull-rebase-using-fork-pointJohn Keeping2014-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-271-9/+1
|\ \ \ | |/ / | | | | | | | | | | | | * 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-091-9/+1
| |/ | | | | | | | | | | | | | | | | 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-301-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-171-3/+2
|\ | | | | | | | | | | | | | | | | * 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-081-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 rebasingsh/pull-rebase-preserveStephen Haberman2013-09-041-5/+26
|/ | | | | | | | | | | | | | | | | | | 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-121-1/+1
|\ | | | | | | | | | | * jk/pull-to-integrate: pull: change the description to "integrate" changes push: avoid suggesting "merging" remote changes
| * pull: change the description to "integrate" changesjk/pull-to-integrateJohn Keeping2013-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | 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-271-2/+9
|\ \ | |/ |/| | | | | | | | | | | | | "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-201-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-311-2/+8
|/ | | | | | | | | | 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-161-1/+1
| | | | | | | | | | | | | 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-251-0/+1
| | | | | | | | | | | | | | | | 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 friendliercn/pull-rebase-messageCarlos Martín Nieto2012-03-041-1/+1
| | | | | | | | | | | | | | | | | | 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"lt/pull-no-editLinus Torvalds2012-02-121-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-091-0/+4
|\ | | | | | | | | * ab/pull-rebase-config: pull: introduce a pull.rebase option to enable --rebase
| * pull: introduce a pull.rebase option to enable --rebaseab/pull-rebase-configÆvar Arnfjörð Bjarmason2011-11-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-171-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | * 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-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 consistentlycb/do-not-pretend-to-hijack-long-helpClemens Buchacher2011-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-251-5/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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-081-5/+2
| | | | | | | | | | | | | | | | | | | | 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-081-1/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | * oa/pull-reflog: pull: remove extra space from reflog message Conflicts: git-pull.sh
| * | | pull: remove extra space from reflog messageOri Avtalion2011-08-011-1/+1
| | |/ | |/| | | | | | | | | | | | | | | | | | | 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-211-3/+6
| | | | | | | | | | | | | | | 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-211-3/+3
| | | | | | | | | | | | | | | 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-211-9/+9
| | | | | | | | | | | | | | | Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status