summaryrefslogtreecommitdiff
path: root/git-merge.sh
AgeCommit message (Collapse)AuthorFilesLines
2007-11-17Merge branch 'ph/parseopt-sh'Libravatar Junio C Hamano1-72/+54
* ph/parseopt-sh: git-quiltimport.sh fix --patches handling git-am: -i does not take a string parameter. sh-setup: don't let eval output to be shell-expanded. git-sh-setup: fix parseopt `eval` string underquoting Give git-am back the ability to add Signed-off-by lines. git-rev-parse --parseopt scripts: Add placeholders for OPTIONS_SPEC Migrate git-repack.sh to use git-rev-parse --parseopt Migrate git-quiltimport.sh to use git-rev-parse --parseopt Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash Migrate git-instaweb.sh to use git-rev-parse --parseopt Migrate git-merge.sh to use git-rev-parse --parseopt Migrate git-am.sh to use git-rev-parse --parseopt Migrate git-clone to use git-rev-parse --parseopt Migrate git-clean.sh to use git-rev-parse --parseopt. Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt Add a parseopt mode to git-rev-parse to bring parse-options to shell scripts.
2007-11-14Merge branch 'jc/stash-create'Libravatar Junio C Hamano1-6/+5
* jc/stash-create: git-stash: Fix listing stashes git-merge: no reason to use cpio anymore Revert "rebase: allow starting from a dirty tree." rebase: allow starting from a dirty tree. stash: implement "stash create"
2007-11-05Migrate git-merge.sh to use git-rev-parse --parseoptLibravatar Pierre Habouzit1-72/+54
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-01git-merge: no reason to use cpio anymoreLibravatar Junio C Hamano1-6/+5
Now we have "git stash create", we can use it to safely stash away the dirty state in the tree. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-03Merge branch 'lh/merge'Libravatar Junio C Hamano1-11/+54
* lh/merge: git-merge: add --ff and --no-ff options git-merge: add support for --commit and --no-squash git-merge: add support for branch.<name>.mergeoptions git-merge: refactor option parsing git-merge: fix faulty SQUASH_MSG Add test-script for git-merge porcelain
2007-10-03Merge branch 'jc/autogc'Libravatar Junio C Hamano1-0/+1
* jc/autogc: git-gc --auto: run "repack -A -d -l" as necessary. git-gc --auto: restructure the way "repack" command line is built. git-gc --auto: protect ourselves from accumulated cruft git-gc --auto: add documentation. git-gc --auto: move threshold check to need_to_gc() function. repack -A -d: use --keep-unreachable when repacking pack-objects --keep-unreachable Export matches_pack_name() and fix its return value Invoke "git gc --auto" from commit, merge, am and rebase. Implement git gc --auto
2007-09-23Merge branch 'je/hooks'Libravatar Junio C Hamano1-0/+13
* je/hooks: Added example hook script to save/restore permissions/ownership. Add post-merge hook, related documentation, and tests.
2007-09-23git-merge: add --ff and --no-ff optionsLibravatar Lars Hjemli1-6/+16
These new options can be used to control the policy for fast-forward merges: --ff allows it (this is the default) while --no-ff will create a merge commit. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23git-merge: add support for --commit and --no-squashLibravatar Lars Hjemli1-2/+6
These options can be used to override --no-commit and --squash, which is needed since --no-commit and --squash now can be specified as default merge options in $GIT_DIR/config. The change also introduces slightly different behavior for --no-commit: when specified, it explicitly overrides --squash. Earlier, 'git merge --squash --no-commit' would result in a squashed merge (i.e. no $GIT_DIR/MERGE_HEAD was created) but with this patch the command will behave as if --squash hadn't been specified. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23git-merge: add support for branch.<name>.mergeoptionsLibravatar Lars Hjemli1-0/+21
This enables per branch configuration of merge options. Currently, the most useful options to specify per branch are --squash, --summary/--no-summary and possibly --strategy, but all options are supported. Note: Options containing whitespace will _not_ be handled correctly. Luckily, the only option which can include whitespace is --message and it doesn't make much sense to give that option a default value. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23git-merge: refactor option parsingLibravatar Lars Hjemli1-6/+14
Move the option parsing into a separate function as preparation for reuse by the next commit. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23git-merge: fix faulty SQUASH_MSGLibravatar Lars Hjemli1-1/+1
Only the first 'remote' head is currently specified as an argument to 'git log' when generating a SQUSH_MSG, which makes the generated message fail to mention every commit involved in the merge. This fixes the problem. Noticed-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23Supplant the "while case ... break ;; esac" idiomLibravatar David Kastrup1-1/+1
A lot of shell scripts contained stuff starting with while case "$#" in 0) break ;; esac and similar. I consider breaking out of the condition instead of the body od the loop ugly, and the implied "true" value of the non-matching case is not really obvious to humans at first glance. It happens not to be obvious to some BSD shells, either, but that's because they are not POSIX-compliant. In most cases, this has been replaced by a straight condition using "test". "case" has the advantage of being faster than "test" on vintage shells where "test" is not a builtin. Since none of them is likely to run the git scripts, anyway, the added readability should be worth the change. A few loops have had their termination condition expressed differently. Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-18Add post-merge hook, related documentation, and tests.Libravatar Josh England1-0/+13
The post-merge hook enables one to hook in for `git pull` operations in order to check and/or change attributes of a work tree from the hook. As an example, it can be used in combination with a pre-commit hook to save/restore file ownership and permissions data (or file ACLs) within the repository and transparently update the working tree after a `git pull` operation. Signed-off-by: Josh England <jjengla@sandia.gov> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06Invoke "git gc --auto" from commit, merge, am and rebase.Libravatar Junio C Hamano1-0/+1
The point of auto gc is to pack new objects created in loose format, so a good rule of thumb is where we do update-ref after creating a new commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27git-merge: do up-to-date check also for all strategiesLibravatar Junio C Hamano1-15/+20
This clarifies the logic to omit fast-forward check and omit trivial merge before running the specified strategy. The "index_merge" variable started out as a flag to say "do not do anything clever", but when recursive was changed to skip the trivial merge, the semantics were changed and the variable alone does not make sense anymore. This splits the variable into two, allow_fast_forward (which is almost always true, and avoids making a merge commit when the other commit is a descendant of our branch, but is set to false for ours and subtree) and allow_trivial_merge (which is false for ours, recursive and subtree). Unlike the earlier implementation, the "ours" strategy allows an up-to-date condition. When we are up-to-date, the result will be our commit, and by definition, we will have our tree as the result. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-06Enable "git rerere" by the config variable rerere.enabledLibravatar Johannes Schindelin1-4/+1
Earlier, "git rerere" was enabled by creating the directory .git/rr-cache. That is definitely not in line with most other features, which are enabled by a config variable. So, check the config variable "rerere.enabled". If it is set to "false" explicitely, do not activate rerere, even if .git/rr-cache exists. This should help when you want to disable rerere temporarily. If "rerere.enabled" is not set at all, fall back to detection of the directory .git/rr-cache. [jc: with minimum tweaks] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-36/+36
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-29Merge branch 'ar/mergestat'Libravatar Junio C Hamano1-6/+12
* ar/mergestat: Add a configuration option to control diffstat after merge
2007-05-26Merge branch 'maint'Libravatar Junio C Hamano1-3/+3
* 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
2007-05-26Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano1-3/+3
* 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
2007-05-26More echo "$user_message" fixes.Libravatar Jeff King1-3/+3
Here are fixes to more uses of 'echo "$msg"' where $msg could contain backslashed sequence. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24Add a configuration option to control diffstat after mergeLibravatar Alex Riesen1-6/+12
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>
2007-05-10Add colour support in rebase and merge tree diff stats output.Libravatar James Bowes1-1/+2
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>
2007-04-07A new merge stragety 'subtree'.Libravatar Junio C Hamano1-2/+2
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>
2007-03-22git-merge: Put FETCH_HEAD data in merge commit messageLibravatar Michael S. Tsirkin1-0/+4
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>
2007-03-16git-merge: finish when git-read-tree failsLibravatar Santi Béjar1-2/+2
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>
2007-03-11git-merge: warn when -m provided on a fast forwardLibravatar J. Bruce Fields1-1/+6
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>
2007-03-03git-merge: fail correctly when we cannot fast forward.Libravatar Junio C Hamano1-1/+1
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>
2007-02-16git-merge: minor fix for no_trivial_merge_strategies.Libravatar Junio C Hamano1-6/+9
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>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-2/+2
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-26git-merge: leave sensible reflog message when used as the first level UI.Libravatar Junio C Hamano1-1/+1
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>
2007-01-14Merge branch 'sp/merge' (early part)Libravatar Junio C Hamano1-17/+23
* 'sp/merge' (early part): Improve merge performance by avoiding in-index merges.
2007-01-12Allow whole-tree operations to be started from a subdirectoryLibravatar Junio C Hamano1-1/+3
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>
2007-01-10Improve merge performance by avoiding in-index merges.Libravatar Shawn O. Pearce1-17/+23
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>
2007-01-10Disallow working directory commands in a bare repository.Libravatar Shawn O. Pearce1-0/+1
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>
2007-01-01fail pull/merge early in the middle of conflicted mergeLibravatar Junio C Hamano1-0/+3
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>
2006-12-28Honor pull.{twohead,octopus} in git-merge.Libravatar Shawn O. Pearce1-2/+14
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>
2006-12-28Use GIT_REFLOG_ACTION environment variable instead.Libravatar Shawn O. Pearce1-8/+5
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>
2006-12-23Display 'theirs' branch name when possible in merge.Libravatar Shawn O. Pearce1-0/+2
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>
2006-12-22merge and reset: adjust for "reset --hard" messagesLibravatar Junio C Hamano1-1/+1
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>
2006-12-16merge: give a bit prettier merge message to "merge branch~$n"Libravatar Junio C Hamano1-9/+17
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>
2006-12-13Merge branch 'jc/read-tree-ignore'Libravatar Junio C Hamano1-1/+1
* 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.
2006-12-13git merge: reword failure message.Libravatar Junio C Hamano1-1/+8
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>
2006-12-06git-merge: fix "fix confusion between tag and branch" for realLibravatar Junio C Hamano1-2/+3
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>
2006-12-06git-merge: squelch needless error message.Libravatar Junio C Hamano1-1/+1
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>
2006-12-05Loosen "working file will be lost" check in Porcelain-ishLibravatar Junio C Hamano1-1/+1
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>
2006-12-02git-merge: fix confusion between tag and branchLibravatar Junio C Hamano1-5/+5
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>
2006-11-26git-merge: do not leak rev-parse output used for checking internally.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-26git-merge: tighten error checking.Libravatar Junio C Hamano1-3/+3
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>