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

git-pull: disallow implicit merging to detached HEAD

2007-01-15T23:37:22Z

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

Allow whole-tree operations to be started from a subdirectory

2007-01-13T00:54:38Z

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

Disallow working directory commands in a bare repository.

2007-01-10T23:03:09Z

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

fail pull/merge early in the middle of conflicted merge

2007-01-01T22:35:16Z

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

Allow git-merge to select the default strategy.

2006-12-28T09:08:06Z

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

Ensure `git-pull` fails if `git-merge` fails.

2006-12-28T09:07:37Z

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

Use GIT_REFLOG_ACTION environment variable instead.

2006-12-28T09:05:15Z

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

Move "no merge candidate" warning into git-pull

2006-12-19T09:53:02Z

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

git-pull: allow pulling into an empty repository

2006-11-17T07:45:48Z

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

git-pull: we say commit X, not X commit.

2006-10-11T06:00:29Z

Signed-off-by: Junio C Hamano