Port v1.7.0-rc0~83^2 (Teach --[no-]rerere-autoupdate option to
merge, revert and friends, 2009-12-04) to the example merge script.
After this change, all tests pass for me with the scripted
merge.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Port v1.6.2-rc1~10^2 (Teach @{-1} to git merge, 2009-02-13) to
the old merge script.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a --no-ff merge with conflicts, "git commit" used to forget the
--no-ff when used to complete the merge. That was fixed by
v1.6.1-rc1~134^2 (builtin-commit: use reduce_heads() only when
appropriate, 2008-10-03) for the builtin merge. Port the change to
the merge script in contrib/examples.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Port v1.6.6-rc0~62^2 (Teach 'git merge' and 'git pull' the option
--ff-only, 2009-10-29) to the old merge script.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Based on v1.6.0-rc0~51^2~5 (Build in merge, 2008-07-07).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Based on v1.7.1.1~23^2 (merge: --log appends shortlog to message if
specified, 2010-05-11). Without this change, the scripted
(non-builtin) merge does not pass t7604.
Cc: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some git-merge-* commands are not merge strategies. This is based on
v1.6.1-rc1~294^2~7 (builtin-merge: allow using a custom strategy,
2008-07-30) but it is less smart: we just use a hard-coded list of
forbidden strategy names. It is okay if this falls out of date, since
the code is just an example.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The idea comes from v1.6.1-rc1~294^2~7 (builtin-merge: allow using a
custom strategy, 2008-07-30).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this support, the scripted merge cannot pass t6037.
Based on v1.7.0-rc0~55^2~5 (git merge -X<option>, 2009-11-25).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- point out remote-tracking branches as "remote branch
'upstream/master'";
- avoid misleading log messages when a tag and branch
share a name.
This approximates the builtin merge command's behavior well
enough to pass the relevant tests.
Based roughly on v1.6.4.2~10^2 (merge: indicate remote tracking
branches in merge message, 2009-08-09) and v1.6.4.2~10^2~1 (merge: fix
incorrect merge message for ambiguous tag/branch, 2009-08-09).
Cc: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check MERGE_HEAD and bail out if it exists. Based on v1.6.3.3~3^2
(refuse to merge during a merge, 2009-06-01). Without this change,
the scripted merge does not pass t3030.
Cc: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before:
You are in the middle of a conflicted merge.
After:
Merge is not possible because you have unmerged files.
I prefer the old message, but the new one is more consistent with
other commands and tests expect it. In particular, without this
change the scripted merge does not pass t3030.
Based on v1.7.0-rc0~66^2 (Be more user-friendly when refusing to do
something because of conflict., 2010-01-12).
Cc: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Port v1.6.1-rc1~319 (provide more errors for the "merge into empty
head" case, 2008-08-21) to the example merge script.
Noticed by comparison with builtin merge.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach "-X <option>" command line argument to "git merge" that is passed to
strategy implementations. "ours" and "theirs" autoresolution introduced
by the previous commit can be asked to the recursive strategy.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitcli(5) already documents them, and there are no options named
--no-no-stat, --no-no-summary and --no-no-log.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are the command line option equivalents of the 'merge.log' config
variable.
The patch also updates documentation and bash completion accordingly, and
adds a test.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This variable has the same effect, as 'merge.diffstat'.
Also mention it in the documentation.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option has the same effect as '--(no-)summary' (i.e. whether to
show a diffsat at the end of the merge or not), and it is consistent
with the '--stat' option of other git commands.
Documentation, tests, and bash completion are updaed accordingly, and the
old --summary option is marked as being deprected.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The following patch will introduce a new configuration variable,
"format.pretty", from then on the pretty format without specifying
"--pretty" might not be the default "--pretty=medium", it depends on
the user's config. So all kinds of Shell/Perl/Emacs scripts that needs
the default medium pretty format must specify it explicitly.
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge used to use either the --squash,--no-squash, --no-ff,--ff,
--no-commit,--commit option, whichever came last in the command line.
This lead to some un-intuitive behavior, having
git merge --no-commit --no-ff <branch>
actually commit the merge. Now git-merge respects --no-commit together
with --no-ff, as well as other combinations of the options. However,
this broke a selftest in t/t7600-merge.sh which expected to have --no-ff
completely override the --squash option, so that
git merge --squash --no-ff <branch>
fast-forwards, and makes a merge commit; combining --squash with --no-ff
doesn't really make sense though, and is now refused by git-merge. The
test is adapted to test --no-ff without the preceding --squash, and
another test is added to make sure the --squash --no-ff combination is
refused.
The unexpected behavior was reported by John Goerzen through
http://bing.sdebian.org/468568
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Jonathan Nieder