aboutsummaryrefslogtreecommitdiff
path: root/git-merge.sh
Commit message (Collapse)AuthorAge
* Merge branch 'ar/mergestat'Junio C Hamano2007-05-29
|\ | | | | | | | | * ar/mergestat: Add a configuration option to control diffstat after merge
| * Add a configuration option to control diffstat after mergeAlex Riesen2007-05-24
| | | | | | | | | | | | | | | | | | The diffstat can be controlled either with command-line options (--summary|--no-summary) or with merge.diffstat. The default is left as it was: diffstat is active by default. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'maint'Junio C Hamano2007-05-26
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | * maint: Fix git-svn to handle svn not reporting the md5sum of a file, and test. Fix mishandling of $Id$ expanded in the repository copy in convert.c More echo "$user_message" fixes. Add tests for the last two fixes. git-commit: use printf '%s\n' instead of echo on user-supplied strings git-am: use printf instead of echo on user-supplied strings Documentation: Add definition of "evil merge" to GIT Glossary Replace the last 'dircache's by 'index' Documentation: Clean up links in GIT Glossary
| * Merge branch 'maint-1.5.1' into maintJunio C Hamano2007-05-26
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint-1.5.1: Fix git-svn to handle svn not reporting the md5sum of a file, and test. More echo "$user_message" fixes. Add tests for the last two fixes. git-commit: use printf '%s\n' instead of echo on user-supplied strings git-am: use printf instead of echo on user-supplied strings Documentation: Add definition of "evil merge" to GIT Glossary Replace the last 'dircache's by 'index' Documentation: Clean up links in GIT Glossary
| | * More echo "$user_message" fixes.Jeff King2007-05-26
| | | | | | | | | | | | | | | | | | | | | Here are fixes to more uses of 'echo "$msg"' where $msg could contain backslashed sequence. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Add colour support in rebase and merge tree diff stats output.James Bowes2007-05-10
|/ / | | | | | | | | | | | | | | | | | | | | | | The rebase and merge commands used diff-tree to display the summary stats of what files had changed from the operation. diff-tree does not read the diff ui configuration options, so the diff.color setting was not used. Have rebase and merge call diff rather than diff-tree, which does read the diff ui options. Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | A new merge stragety 'subtree'.Junio C Hamano2007-04-07
|/ | | | | | | | | | | | | | | | | | | | | | | | | This merge strategy largely piggy-backs on git-merge-recursive. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree. If you are pulling updates from git-gui repository into git.git repository, the root level of the former corresponds to git-gui/ subdirectory of the latter. The tree object of git-gui's toplevel is wrapped in a fake tree object, whose sole entry has name 'git-gui' and records object name of the true tree, before being used by the 3-way merge code. If you are merging the other way, only the git-gui/ subtree of git.git is extracted and merged into git-gui's toplevel. The detection of corresponding subtree is done by comparing the pathnames and types in the toplevel of the tree. Heuristics galore! That's the git way ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: Put FETCH_HEAD data in merge commit messageMichael S. Tsirkin2007-03-22
| | | | | | | | This makes git-fetch <URL> && git-merge FETCH_HEAD produce the same merge message as git-pull <URL>. Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: finish when git-read-tree failsSanti Béjar2007-03-16
| | | | | | | | | The message formating (commit v1.5.0.3-28-gbe242d5) broke the && chain. Noticed by Dmitry Torokhov. Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: warn when -m provided on a fast forwardJ. Bruce Fields2007-03-11
| | | | | | | | | | Warn the user that the "-m" option is ignored in the case of a fast forward. That may save some confusion in the case where the user doesn't know about fast forwards yet and may not realize that the behavior here is intentional. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: fail correctly when we cannot fast forward.Junio C Hamano2007-03-03
| | | | | | | | | | When we cannot fast forward the working tree and the current branch, git-merge did not exit with non-zero status. Noticed by Larry Streepy, the section to be fixed identfied by Johannes Schindelin. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: minor fix for no_trivial_merge_strategies.Junio C Hamano2007-02-16
| | | | | | | | | | | | The shell loop to determine if we should skip the trivial in-index merge stage based on what strategy is given was not prepared to have more than one strategy listed in the variable $no_trivial_merge_strategies. This does not trigger unless you use a modified git but the fix is simple and straightforward, so let's fix it before 1.5.0.1. Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] Rename git-repo-config to git-config.Tom Prince2007-01-28
| | | | | Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: leave sensible reflog message when used as the first level UI.Junio C Hamano2007-01-26
| | | | | | | | | | | It used to throw potentially multi-line log message at reflog. Just record the heads that were given to be merged at the command line and the action. Revert the removal of the check in "git-update-ref -m" I made earlier which was only a work-around for this. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'sp/merge' (early part)Junio C Hamano2007-01-14
|\ | | | | | | | | * 'sp/merge' (early part): Improve merge performance by avoiding in-index merges.
| * Improve merge performance by avoiding in-index merges.Shawn O. Pearce2007-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the early days of Git we performed a 3-way read-tree based merge before attempting any specific merge strategy, as our core merge strategies of merge-one-file and merge-recursive were slower script based programs which took far longer to execute. This was a good performance optimization in the past, as most merges were able to be handled strictly by `read-tree -m -u`. However now that merge-recursive is a C based program which performs a full 3-way read-tree before it starts running we need to pay the cost of the 3-way read-tree twice if we have to do any sort of file level merging. This slows down some classes of simple merges which `read-tree -m -u` could not handle but which merge-recursive does automatically. For a really trivial merge which can be handled entirely by `read-tree -m -u`, skipping the read-tree and just going directly into merge-recursive saves on average 50 ms on my PowerPC G4 system. May sound odd, but it does appear to be true. In a really simple merge which needs to use merge-recursive to handle a file that was modified on both branches, skipping the read-tree in git-merge saves on average almost 100 ms (on the same PowerPC G4) as we avoid doing some work twice. We only avoid `read-tree -m -u` if the only strategy to use is merge-recursive, as not all merge strategies perform as well as merge-recursive does. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Allow whole-tree operations to be started from a subdirectoryJunio C Hamano2007-01-12
| | | | | | | | | | | | | | | | | | | | | | | | 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 <junkio@cox.net>
* | Disallow working directory commands in a bare repository.Shawn O. Pearce2007-01-10
|/ | | | | | | | | | | | | | | | 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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* fail pull/merge early in the middle of conflicted mergeJunio C Hamano2007-01-01
| | | | | | | | | | | | | | | | | | | | | | | | 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 <junkio@cox.net>
* Honor pull.{twohead,octopus} in git-merge.Shawn O. Pearce2006-12-28
| | | | | | | | | | | If git-merge is invoked without a strategy argument it is probably being run as a porcelain-ish command directly and is not being run from within git-pull. However we still should honor whatever merge strategy the user may have selected in their configuration, just as `git-pull .` would have. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use GIT_REFLOG_ACTION environment variable instead.Shawn O. Pearce2006-12-28
| | | | | | | | | | | | | | | | | 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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Display 'theirs' branch name when possible in merge.Shawn O. Pearce2006-12-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Displaying the SHA1 of 'their' branch (the branch being merged into the current branch) is not nearly as friendly as just displaying the name of that branch, especially if that branch is already local to this repository. git-merge now sets the environment variable 'GITHEAD_%(sha1)=%(name)' for each argument it gets passed, making the actual input name that resolved to the commit '%(sha1)' easily available to the invoked merge strategy. git-merge-recursive makes use of these environment variables when they are available by using '%(name)' whenever it outputs the commit identification rather than '%(sha1)'. This is most obvious in the conflict hunks created by xdl_merge: $ git mege sideb~1 <<<<<<< HEAD:INSTALL Good! ======= Oops. >>>>>>> sideb~1:INSTALL [jc: adjusted a test script and a minor constness glitch.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge and reset: adjust for "reset --hard" messagesJunio C Hamano2006-12-22
| | | | | | | | | | | | | An earlier commit made "reset --hard" chattier but leaking its message from "git rebase" (which calls it when first rewinding the current branch to prepare replaying our own changes) without explanation was confusing, so add an extra message to mention it. Inside restorestate in merge (which is rarely exercised codepath, where more than one strategies are attempted), resetting to the original state uses "reset --hard" -- this can be squelched entirely. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge: give a bit prettier merge message to "merge branch~$n"Junio C Hamano2006-12-16
| | | | | | | This hacks the input to fmt-merge-msg to make the message for merging early part of a branch a little easier to read. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'jc/read-tree-ignore'Junio C Hamano2006-12-13
|\ | | | | | | | | | | | | * jc/read-tree-ignore: read-tree: document --exclude-per-directory Loosen "working file will be lost" check in Porcelain-ish read-tree: further loosen "working file will be lost" check.
| * Loosen "working file will be lost" check in Porcelain-ishJunio C Hamano2006-12-05
| | | | | | | | | | | | | | | | This uses the previous update to read-tree in Porcelain-ish commands "git checkout" and "git merge" to loosen the check when switching branches. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git merge: reword failure message.Junio C Hamano2006-12-13
| | | | | | | | | | | | | | | | | | | | | | 99.9999% of the time, the command is used with a single strategy; after a merge failure, saying "No strategy handled the merge" is technically correct, but there is no point stressing we tried and failed all the possibilities the user has given. Just say that it failed. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-merge: fix "fix confusion between tag and branch" for realJunio C Hamano2006-12-06
| | | | | | | | | | | | | | | | An earlier commit 3683dc5a broke the merge message generation with a careless use of && where it was not needed, breaking the merge message for cases where non branches are given. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-merge: squelch needless error message.Junio C Hamano2006-12-06
|/ | | | | | | | | | While deciding if the new style command line argument is a tag or a branch, we checked it with "git show-ref -s --verify" to see if results in an error, but when it is not a branch, the check leaked the error message out, which was not needed to be shown to the end user. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: fix confusion between tag and branchJunio C Hamano2006-12-02
| | | | | | | | | | | | | In a repository with core.warnambiguousrefs turned off, and with a branch and a tag that have the same name 'frotz', git merge frotz would merge the commit pointed at by the tag 'frotz' but incorrectly would identify what was merged as 'branch frotz' in the merge message. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: do not leak rev-parse output used for checking internally.Junio C Hamano2006-11-26
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: tighten error checking.Junio C Hamano2006-11-26
| | | | | | | | | If a branch name to be merged is misspelled, the command leaked error messages from underlying plumbing commands, which were helpful only to people who know how the command are implemented to diagnose the breakage, but simply puzzling and unhelpful for the end users. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge: allow merging into a yet-to-be-born branch.Junio C Hamano2006-11-21
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: make it usable as the first class UIJunio C Hamano2006-11-21
| | | | | | | | | | | | | | | | | | | | | | | | This teaches the oft-requested syntax git merge $commit to implement merging the named commit to the current branch. This hopefully would make "git merge" usable as the first class UI instead of being a mere backend for "git pull". Most notably, $commit above can be any committish, so you can say for example: git merge js/shortlog~2 to merge early part of a topic branch without merging the rest of it. A custom merge message can be given with the new --message=<msg> parameter. The message is prepended in front of the usual "Merge ..." message autogenerated with fmt-merge-message. Signed-off-by: Junio C Hamano <junkio@cox.net>
* remove merge-recursive-oldJunio C Hamano2006-11-21
| | | | | | This frees the Porcelain-ish that comes with the core Python-free. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'maint'Junio C Hamano2006-10-22
|\ | | | | | | | | | | | | | | | | | | | | * maint: pager: default to LESS=FRSX not LESS=FRS Make prune also run prune-packed git-vc: better installation instructions gitweb: Do not esc_html $basedir argument to git_print_tree_entry gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2) Fix usagestring for git-branch git-merge: show usage if run without arguments
| * git-merge: show usage if run without argumentsRene Scharfe2006-10-22
| | | | | | | | | | Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | merge and resolve: Output short hashes and .. in "Updating ..."Santi Béjar2006-09-30
|/ | | | | Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Deprecate merge-recursive.pyJunio C Hamano2006-09-24
| | | | | | | | | This renames merge-recursive written in Python to merge-recursive-old, and makes merge-recur as a synonym to merge-recursive. We do not remove merge-recur yet, but we will remove merge-recur and merge-recursive-old in a few releases down the road. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'js/read-tree' into js/c-merge-recursiveJunio C Hamano2006-07-30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * js/read-tree: (107 commits) read-tree: move merge functions to the library read-trees: refactor the unpack_trees() part tar-tree: illustrate an obscure feature better git.c: allow alias expansion without a git directory setup_git_directory_gently: do not barf when GIT_DIR is given. Build on Debian GNU/kFreeBSD Call setup_git_directory() much earlier Call setup_git_directory() early Display an error from update-ref if target ref name is invalid. Fix http-fetch t4103: fix binary patch application test. git-apply -R: binary patches are irreversible for now. Teach git-apply about '-R' Makefile: ssh-pull.o depends on ssh-fetch.c log and diff family: honor config even from subdirectories git-reset: detect update-ref error and report it. lost-found: use fsck-objects --full Teach git-http-fetch the --stdin switch Teach git-local-fetch the --stdin switch Make pull() support fetching multiple targets at once ...
| * Log ref changes made by git-merge and git-pull.Shawn Pearce2006-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | recur vs recursive: help testing without touching too many stuff.Junio C Hamano2006-07-13
| | | | | | | | | | | | | | | | During git-merge-recur development, you could set an environment variable GIT_USE_RECUR_FOR_RECURSIVE to use WIP recur in place of the recursive strategy. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Status update on merge-recursive in CJohannes Schindelin2006-07-13
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is just an update for people being interested. Alex and me were busy with that project for a few days now. While it has progressed nicely, there are quite a couple TODOs in merge-recursive.c, just search for "TODO". For impatient people: yes, it passes all the tests, and yes, according to the evil test Alex did, it is faster than the Python script. But no, it is not yet finished. Biggest points are: - there are still three external calls - in the end, it should not be necessary to write the index more than once (just before exiting) - a lot of things can be refactored to make the code easier and shorter BTW we cannot just plug in git-merge-tree yet, because git-merge-tree does not handle renames at all. This patch is meant for testing, and as such, - it compile the program to git-merge-recur - it adjusts the scripts and tests to use git-merge-recur instead of git-merge-recursive - it provides "TEST", a script to execute the tests regarding -recursive - it inlines the changes to read-cache.c (read_cache_from(), discard_cache() and refresh_cache_entry()) Brought to you by Alex Riesen and Dscho Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix expr usage for FreeBSDDennis Stosberg2006-06-27
| | | | | | | | Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge --squashJunio C Hamano2006-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <junkio@cox.net>
* git-merge: Don't use -p when outputting summaryTimo Hirvonen2006-06-23
| | | | | | | -p is not needed and we only want diffstat and summary. Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Convert some "apply --summary" users to "diff --summary".Sean2006-05-14
| | | | | Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge: a bit more readable user guidance.Junio C Hamano2006-04-19
| | | | | | | | We said "fix up by hand" after failed automerge, which was a big "Huh? Now what?". Be a bit more explicit without being too verbose. Suggested by Carl Worth. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge knows some strategies want to skip trivial mergesJunio C Hamano2006-03-20
| | | | | | | | | | Most notably "ours". Also this makes sure we do not record duplicated parents on the parent list of the resulting commit. This is based on Mark Wooding's work, but does not change the UI nor introduce new flags. Signed-off-by: Junio C Hamano <junkio@cox.net>
* allow double click on current HEAD id after git-pullOlaf Hering2006-03-09
| | | | | | | | | Double click on to current HEAD commit id is not possible, the dot has to go. [jc: by popular requests.] Signed-off-by: Junio C Hamano <junkio@cox.net>