user/sven/git.git/git-pull.sh, branch v1.8.0.2

git-pull: Avoid merge-base on detached head

2012-10-25T09:32:11Z

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 Signed-off-by: Jeff King

Make git-{pull,rebase} message without tracking information friendlier

2012-03-05T07:00:57Z

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 . 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 Signed-off-by: Junio C Hamano

"git pull" doesn't know "--edit"

2012-02-13T03:24:47Z

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 [] [ [...]] or: git fetch [] or: git fetch --multiple [] [( | )...] or: git fetch --all [] -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 Signed-off-by: Junio C Hamano

Merge branch 'ab/pull-rebase-config'

2011-12-09T21:37:01Z

* ab/pull-rebase-config: pull: introduce a pull.rebase option to enable --rebase

pull: introduce a pull.rebase option to enable --rebase

2011-11-07T16:43:11Z

Currently we either need to set branch..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..rebase, i.e. we could set pull.rebase=true and branch..rebase=false and the latter configuration option would win. Reviewed-by: Sverre Rabbelier Reviewed-by: Fernando Vezzosi Reviewed-by: Eric Herman Signed-off-by: Ævar Arnfjörð Bjarmason Liked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'jk/pull-rebase-with-work-tree'

2011-10-18T04:37:14Z

* jk/pull-rebase-with-work-tree: pull,rebase: handle GIT_WORK_TREE better Conflicts: git-pull.sh

pull,rebase: handle GIT_WORK_TREE better

2011-10-13T19:16:36Z

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 Signed-off-by: Junio C Hamano

use -h for synopsis and --help for manpage consistently

2011-10-05T17:47:10Z

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 Signed-off-by: Junio C Hamano

Merge branch 'js/i18n-scripts'

2011-08-25T23:00:16Z

* 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

Merge branch 'oa/pull-reflog'

2011-08-08T19:33:36Z

* oa/pull-reflog: pull: remove extra space from reflog message Conflicts: git-pull.sh