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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
-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>
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>
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>
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>
This implements "eye candy" similar to the pack-object/unpack-object
to entertain users while a large tree is being checked out after
a clone or a pull.
Signed-off-by: Junio C Hamano <junkio@cox.net>
"empty ident not allowed" error makes commit-tree fail, so we
are already safer in that we would not end up with commit
objects that have bogus names on the author or committer fields.
However, before commit-tree is called there are already changes
made to the index file and the working tree. The operation can
be resumed after fixing the environment problem, but when this
triggers to a newcomer with unusable gecos, the first question
becomes "what did I lose and how would I recover".
This patch modifies some Porcelainish commands to verify
GIT_COMMITTER_IDENT as soon as we know we are going to make some
commits before doing much damage to prevent confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In some setups (notably server setups) you do not need that dependency.
Gracefully handle the absence of python when NO_PYTHON is defined.
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"empty ident not allowed" error makes commit-tree fail, so we
are already safer in that we would not end up with commit
objects that have bogus names on the author or committer fields.
However, before commit-tree is called there are already changes
made to the index file and the working tree. The operation can
be resumed after fixing the environment problem, but when this
triggers to a newcomer with unusable gecos, the first question
becomes "what did I lose and how would I recover".
This patch modifies some Porcelainish commands to verify
GIT_COMMITTER_IDENT as soon as we know we are going to make some
commits before doing much damage to prevent confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes noticed that git-rerere depends on Digest.pm, and if
one does not use the command, one can live without it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a workflow that employs relatively long lived topic branches,
the developer sometimes needs to resolve the same conflict over
and over again until the topic branches are done (either merged
to the "release" branch, or sent out and accepted upstream).
This commit introduces a new command, "git rerere", to help this
process by recording the conflicted automerge results and
corresponding hand-resolve results on the initial manual merge,
and later by noticing the same conflicted automerge and applying
the previously recorded hand resolution using three-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The files with conflicts need to be hand resolved, and it is a
good discipline for the committer to explain which branch was
taken and why. Pre-fill the merge message template with the
list of conflicted paths to encourage it.
This is from Linus.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We did not distinguish the case the user asked not to make a
commit with --no-commit flag and the automerge failed. Tell
these cases apart and phrase dying message differently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Although "git-merge" is advertised as the end-user level command
(instead of being a "git-pull" backend), it was not prepared to
take tag objects that point at commits and barfed when fed one.
Sanitize the input while we validate them, for which we already
have a loop.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This way it is possible to test in scripts if the merge was non-clean
or if the strategy had other problems with the merge.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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 <junkio@cox.net>
git-pull invoked merge with recursive as the default strategy
for some time now; match it in the git-merge itself. Also avoid
listing more than one strategy on default because we have only
one strategy that can resolve an octopus and we are already
counting heads here. This reduces the need to stash away local
modifications.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It may get extra merge base on truly pathological commit histories,
but is a lot easier to understand, explain, and prove correctness.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the coolest merge strategy ever, "ours". It can take
arbitrary number of foreign heads and merge them into the
current branch, with the resulting tree always taken from our
branch head, hence its name.
What this means is that you can declare that the current branch
supersedes the development histories of other branches using
this merge strategy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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 <junkio@cox.net>
Update docs and usages regarding '-r' recursive option for git-diff-tree.
Remove '-r' from common diff options, mention it only for git-diff-tree.
Remove one extraneous use of '-r' with git-diff-files in get-merge.sh.
Sync the synopsis and usage string for git-diff-tree.
Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Martin Langhoff wants to use git-merge from outside git-pull and wants
to do further processing; for this, he wants git-merge no to commit
even when it cleanly merges. I think other script writers would want
something like that as well, so here it is.
Instead of the "merge commit message" parameter (which usually is made
for you by "git-pull" which calls this command), you pass an empty
string to it. Then it will not update your HEAD -- you can do whatever
you want with the resulting index file, which contains the merge results.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let the merge strategies handle the base less case if they are able to
do it. It also fixes git-resolve.sh to die if no common ancestors
exists, instead of doing the wrong thing. Furthermore, it contains a
small independent fix for git-merge.sh and a fix for a base less code
path in gitMergeCommon.py.
With this it's possible to use
git merge -s recursive 'merge message' A B
to do a base less merge of A and B.
[jc: Thanks Fredrik for fixing the brown-paper-bag in git-merge.
I fixed a small typo in git-merge-resolve fix; 'test' equality
check is spelled with single equal sign -- C-style double equal
sign is bashism.]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using Linus' --trivial option, this handles really trivial case
inside git-merge itself, without using any strategy modules.
A 'really trivial case' is:
- we are merging one branch into the current branch;
- there is only one merge base between the branches;
- there is no file-level merge required.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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 <junkio@cox.net>
The merge strategy would check this itself and typically does it
by using git-read-tree -m -u 3-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Being able to try multiple strategies and automatically picking one
that seems to give less conflicting result may or may not much sense
in practice. At least that should not force normal use case to
additionally require the working tree to be fully clean. As Linus
shouted, local changes do not matter unless they interfere with the
merge.
This commit changes git-merge not to require a clean working tree.
Only when we will iterate through more than one merge strategies,
local changes are stashed away before trying the first merge, and
restored before second and later merges are attempted.
The index file must be in sync with HEAD in any case -- otherwise the
merge result would contain changes since HEAD that was done locally
and registered in the index. This check is already enforced by
three-way read-tree existing merge strategies use, but is done here as
a safeguard as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The merge strategies can give more descriptive error messages for
conflict cases if they are given the actual branch names instead of
the SHA1s.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise we would regret when Fredrik comes up with another merge
algorithm with different pros-and-cons with the current one.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano