path: root/
AgeCommit message (Collapse)Author
2007-01-01fail pull/merge early in the middle of conflicted mergeJunio C Hamano
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 <>
2006-12-28Allow git-merge to select the default strategy.Shawn O. Pearce
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 <>
2006-12-28Ensure `git-pull` fails if `git-merge` fails.Shawn O. Pearce
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 <>
2006-12-28Use GIT_REFLOG_ACTION environment variable instead.Shawn O. Pearce
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 <>
2006-12-19Move "no merge candidate" warning into git-pullJosef Weidendorfer
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 <>
2006-11-17git-pull: allow pulling into an empty repositoryLinus Torvalds
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 <>
2006-10-11git-pull: we say commit X, not X commit.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2006-07-11Log ref changes made by git-merge and git-pull.Shawn Pearce
When git-merge updates HEAD as a result of a merge record what happened during the merge into the reflog associated with HEAD (if any). The log reports who caused the update (git-merge or git-pull, by invoking git-merge), what the remote ref names were and the type of merge process used. The merge information can be useful when reviewing a reflog for a branch such as `master` where fast forward and trivial in index merges might be common as the user tracks an upstream. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2006-07-11Log ref changes made by git-fetch and git-pull.Shawn Pearce
When git-fetch updates a reference record in the associated reflog what type of update took place and who caused it (git-fetch or git-pull, by invoking git-fetch). Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2006-06-27Fix expr usage for FreeBSDDennis Stosberg
Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <> Signed-off-by: Junio C Hamano <>
2006-06-24git-merge --squashJunio C Hamano
Some people tend to do many little commits on a topic branch, recording all the trials and errors, and when the topic is reasonably cooked well, would want to record the net effect of the series as one commit on top of the mainline, removing the cruft from the history. The topic is then abandoned or forked off again from that point at the mainline. The barebone porcelainish that comes with core git tools does not officially support such operation, but you can fake it by using "git pull --no-merge" when such a topic branch is not a strict superset of the mainline, like this: git checkout mainline git pull --no-commit . that-topic-branch : fix conflicts if any rm -f .git/MERGE_HEAD git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged This however does not work when the topic branch is a fast forward of the mainline, because normal "git pull" will never create a merge commit in such a case, and there is nothing special --no-commit could do to begin with. This patch introduces a new option, --squash, to support such a workflow officially in both fast-forward case and true merge case. The user-level operation would be the same in both cases: git checkout mainline git pull --squash . that-topic-branch : fix conflicts if any -- naturally, there would be : no conflict if fast forward. git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged When the current branch is already up-to-date with respect to the other branch, there truly is nothing to do, so the new option does not have any effect. This was brought up in #git IRC channel recently. Signed-off-by: Junio C Hamano <>
2006-06-24git-pull: abort when fmt-merge-msg fails.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2006-03-22git-pull: reword "impossible to fast-forward" message.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2006-03-22git-pull: further safety while on tracking branch.Junio C Hamano
Running 'git pull' while on the tracking branch has a built-in safety valve to fast-forward the index and working tree to match the branch head, but it errs on the safe side too cautiously. Signed-off-by: Junio C Hamano <>
2006-03-18git-pull: run repo-config with dash form.Junio C Hamano
... as discussed on the list for consistency. Signed-off-by: Junio C Hamano <>
2006-03-16Let merge set the default strategy.Mark Hollomon
If the user does not set a merge strategy for git-pull, let git-merge calculate a default strategy. [jc: with minor stylistic tweaks] Signed-off-by: Mark Hollomon <> Signed-off-by: Junio C Hamano <>
2006-02-12Avoid using "git-var -l" until it gets fixed.Junio C Hamano
This is to be nicer to people with unusable GECOS field. "git-var -l" is currently broken in that when used by a user who does not have a usable GECOS field and has not corrected it by exporting GIT_COMMITTER_NAME environment variable it dies when it tries to output GIT_COMMITTER_IDENT (same thing for AUTHOR). "git-pull" used "git-var -l" only because it needed to get a configuration variable before "git-repo-config --get" was introduced. Use the latter tool designed exactly for this purpose. "git-sh-setup" used "git-var GIT_AUTHOR_IDENT" without actually wanting to use its value. The only purpose was to cause the command to check and barf if the repository format version recorded in the $GIT_DIR/config file is too new for us to deal with correctly. Instead, use "repo-config --get" on a random property and see if it die()s, and check if the exit status is 128 (comes from die -- missing variable is reported with exit status 1, so we can tell that case apart). Signed-off-by: Junio C Hamano <>
2005-12-14Trivial usage string
Signed-off-by: Fredrik Kuivinen <> Signed-off-by: Junio C Hamano <>
2005-11-25git-sh-setup: die if outside git repository.Junio C Hamano
Now all the users of this script detect its exit status and die, complaining that it is outside git repository. So move the code that dies from all callers to git-sh-setup script. Signed-off-by: Junio C Hamano <>
2005-11-10Make git-recursive the default strategy for git-pull.Junio C Hamano
This does two things: - It changes the hardcoded default merge strategy for two-head git-pull from resolve to recursive. - .git/config file acquires two configuration items. pull.twohead names the strategy for two-head case, and pull.octopus names the strategy for octopus merge. IOW you are paranoid, you can have the following lines in your .git/config file and keep using git-merge-resolve when pulling one remote: [pull] twohead = resolve OTOH, you can say this: [pull] twohead = resolve twohead = recursive to try quicker resolve first, and when it fails, fall back to recursive. Signed-off-by: Junio C Hamano <>
2005-11-07Recover dropped +x bit from by accident.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2005-11-07Refactored merge options into separate merge-options.txt.Jon Loeliger
Refactored fetch options into separate fetch-options.txt. Made git-merge use merge-options. Made git-fetch use fetch-options. Made git-pull use merge-options and fetch-options. Added --help option to git-pull and git-format-patch scripts. Rewrote Documentation/Makefile to dynamically determine include dependencies. Signed-off-by: Jon Loeliger <> Signed-off-by: Junio C Hamano <>
2005-11-05Document the --no-commit flag betterJunio C Hamano
Pasky and I did overlapping documentation independently; this is to pick up better wordings from what he sent me. Signed-off-by: Petr Baudis <> Signed-off-by: Junio C Hamano <>
2005-11-03Add --no-commit to git-merge/git-pull.Junio C Hamano
With --no-commit flag, git-pull will perform the merge but pretends as if the merge needed a hand resolve even if automerge cleanly resolves, to give the user a chance to add further changes and edit the commit message. Signed-off-by: Junio C Hamano <>
2005-10-03git-pull: do not barf on -a flag meant for git-fetch.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2005-09-29Use git-merge in git-pull (second try).Junio C Hamano
This again makes git-pull to use git-merge, so that different merge strategy can be specified from the command line. Without explicit strategy parameter, it defaults to git-merge-resolve if only one remote is pulled, and git-merge-octopus otherwise, to keep the default behaviour of the command the same as the original. Also this brings another usability measure: -n flag from the command line, if given, is passed to git-merge to prevent it from running the diffstat at the end of the merge. Signed-off-by: Junio C Hamano <>
2005-09-28Use git-update-ref in scripts.Junio C Hamano
This uses the git-update-ref command in scripts for safer updates. Also places where we used to read HEAD ref by using "cat" were fixed to use git-rev-parse. This will matter when we start using symbolic references. Signed-off-by: Junio C Hamano <>
2005-09-28Fix default pull not to do an unintended Octopus.Junio C Hamano
The refspecs specified in the .git/remotes/<remote> on the "Pull: " lines are for fetching multiple heads in one go, but most of the time making an Octopus out of them is not what is wanted. Make git-fetch leave the marker in .git/FETCH_HEAD file so that later stages can tell which heads are for merging and which are not. Tom Prince made me realize how stupid the original behaviour was. Signed-off-by: Junio C Hamano <>
2005-09-23Prettyprint octopus merge message.Junio C Hamano
Including the current branch in the list of heads being merged was not a good idea, so drop it. And shorten the message by grouping branches and tags together to form a single line. Signed-off-by: Junio C Hamano <>
2005-09-21Revert "Use git-merge instead of git-resolve in git-pull."Junio C Hamano
This reverts f887564ab72e107bcdee3ba83c91e2bb4ae13ca7 commit.
2005-09-21Revert "Make Octopus merge message a bit nicer."Junio C Hamano
This reverts 63f1aa6c72c46928f1b6959437aed4becbc42ff3 commit.
2005-09-21Make Octopus merge message a bit nicer.Junio C Hamano
Linus says that 'of .' to mean the commits came from the local repository was too confusing and ugly -- I tend to agree with him. Signed-off-by: Junio C Hamano <>
2005-09-21Use git-merge instead of git-resolve in git-pull.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2005-09-16Revert breakage introduced by c80522e30fdc190f8c8c7fc983bbe040a1b03e93.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2005-09-14Make merge comment git-pull makes for an octopus a bit prettier.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2005-09-08Big tool rename.Junio C Hamano
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <>