Граф коммитов

38 Коммитов

Автор SHA1 Сообщение Дата
Jeff King 72fac66bca merge: detect delete/modechange conflict
If one side deletes a file and the other changes its
content, we notice and report a conflict. However, if
instead of changing the content, we change only the mode,
the merge does not notice (and the mode change is silently
dropped).

The trivial index merge notices the problem and correctly
leaves the conflict in the index, but both merge-recursive
and merge-one-file will silently resolve this in favor of
the deletion.  In many cases that is a sane resolution, but
we should be punting to the user whenever there is any
question. So let's detect and treat this as a conflict (in
both strategies).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26 14:49:31 -07:00
Junio C Hamano 183f88018a Merge branch 'kb/p4merge'
Adjust the order mergetools feeds the files to the p4merge backend
to match the p4 convention.

* kb/p4merge:
  merge-one-file: force content conflict for "both sides added" case
  git-merge-one-file: send "ERROR:" messages to stderr
  git-merge-one-file: style cleanup
  merge-one-file: remove stale comment
  mergetools/p4merge: create a base if none available
  mergetools/p4merge: swap LOCAL and REMOTE
2013-03-26 13:15:24 -07:00
Junio C Hamano 4fa5c0591a merge-one-file: force content conflict for "both sides added" case
Historically, we tried to be lenient to "both sides added, slightly
differently" case and as long as the files can be merged using a
made-up common ancestor cleanly, since f7d24bbefb (merge with
/dev/null as base, instead of punting O==empty case, 2005-11-07).

This was later further refined to use a better made-up common file
with fd66dbf529 (merge-one-file: use empty- or common-base
condintionally in two-stage merge., 2005-11-10), but the spirit has
been the same.

But the original fix in f7d24bbefb to avoid punting on "both sides
added" case had a code to unconditionally error out the merge.  When
this triggers, even though the content-level merge can be done
cleanly, we end up not saying "content conflict" in the message, but
still issue the error message, showing "ERROR: in <pathname>".

Move that "always fail for add/add conflict" logic a bit higher to
fix this.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25 13:32:07 -07:00
Kevin Bracey d401acf703 git-merge-one-file: send "ERROR:" messages to stderr
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25 10:50:31 -07:00
Kevin Bracey 333ea38db9 git-merge-one-file: style cleanup
Update style to match Documentation/CodingGuidelines.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25 10:50:27 -07:00
Junio C Hamano 530333cfe8 merge-one-file: remove stale comment
The "funny filename" comment was from b539c5e8fb (git-merge-one:
new merge world order., 2005-12-07) where the removed code just
before that new comment ended with:

        merge "$4" "$orig" "$src2"

(yes, we used to use "merge" program from the RCS suite).  The
comment refers to one of the bad side effect the old code used to
have and warns against such a practice, i.e. it was talking about
the code that no longer existed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25 10:48:24 -07:00
Kevin Bracey 4549162e8d mergetools/p4merge: create a base if none available
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:

   p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"

Commit 0a0ec7bd changed this to:

   p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"

to avoid the problem of being unable to save in some circumstances with
similar inputs.

Unfortunately this approach produces much worse results on differing
inputs. P4Merge really regards the blank file as the base, and once you
have just a couple of differences between the two branches you end up
with one a massive full-file conflict. The 3-way diff is not readable,
and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a
useful view.

The original approach appears to have invoked special 2-way merge
behaviour in P4Merge that occurs only if the base filename is "" or
equal to the left input.  You get a good visual comparison, and it does
not auto-resolve differences. (Normally if one branch matched the base,
it would autoresolve to the other branch).

But there appears to be no way of getting this 2-way behaviour and being
able to reliably save. Having base==left appears to be triggering other
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.

So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. This is the same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.

Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files.  As with the other merges using this
technique, we assume the user will inspect the result before saving.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Reviewed-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-13 10:46:07 -07:00
David Aguilar e5a1518ef4 git-merge-one-file: use a lowercase "usage:" string
Make the usage string consistent with Git.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-24 13:31:06 -08:00
Junio C Hamano b73c6834dd Merge branch 'js/maint-merge-one-file-osx-expr'
* js/maint-merge-one-file-osx-expr:
  merge-one-file: fix "expr: non-numeric argument"
2011-10-13 19:03:24 -07:00
Jay Soffian d30db5605b merge-one-file: fix "expr: non-numeric argument"
When invoking expr to compare two numbers, don't quote the
variables which are the output of 'wc -c'. On OS X, this output
includes spaces, which expr balks at:

  $ sz0=`wc -c </etc/passwd`
  $ sz1=`wc -c </etc/passwd`
  $ echo "'$sz0'"
  '    3667'

  $ expr "$sz0" \< "$sz1" \* 2
  expr: non-numeric argument

  $ expr $sz0 \< $sz1 \* 2
  1

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 13:24:59 -07:00
Junio C Hamano ac13e7c514 Merge branch 'jk/merge-one-file-working-tree'
* jk/merge-one-file-working-tree:
  merge-one-file: fix broken merges with alternate work trees
  add tests for merge-index / merge-one-file
2011-05-06 10:54:08 -07:00
Jeff King 6aaeca900b merge-one-file: fix broken merges with alternate work trees
The merge-one-file tool predates the invention of
GIT_WORK_TREE. By the time GIT_WORK_TREE was invented, most
people were using the merge-recursive strategy, which
handles resolving internally. Therefore these features have
had very little testing together.

For the most part, merge-one-file just works with
GIT_WORK_TREE; most of its heavy lifting is done by plumbing
commands which do respect GIT_WORK_TREE properly. The one
exception is a shell redirection which touches the worktree
directly, writing results to the wrong place in the presence
of a GIT_WORK_TREE variable.

This means that merges won't even fail; they will silently
produce incorrect results, throwing out the entire "theirs"
side of files which need content-level merging!

This patch makes merge-one-file chdir to the toplevel of the
working tree (and exit if we don't have one). This most
closely matches the assumption made by the original script
(before separate work trees were invented), and matches what
happens when the script is called as part of a merge
strategy.

While we're at it, we'll also error-check the call to cat.
Merging a file in a subdirectory could in fact fail, as the
redirection relies on the "checkout-index" call just prior
to create leading directories. But we never noticed, since
we ignored the error return from running cat.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29 15:37:43 -07:00
Junio C Hamano 09ce4bb6ea build: propagate $DIFF to scripts
git-merge-one-file expects to run "-u" capable "diff", but using
$DIFF is not the right way to do so.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-05 09:36:13 -07:00
Gary V. Vaughan d1b1a91946 Do not use "diff" found on PATH while building and installing
Some of the flags used with the first diff found in PATH cause the
vendor diff to choke.

Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31 16:59:27 -07:00
Jonathan Nieder ae5bdda36c Show usage string for 'git merge-one-file -h'
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10 11:06:57 -08:00
Alex Riesen 718135e3b6 Clarify kind of conflict in merge-one-file helper
Not as verbose as the recursive merge driver, but better still.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-09 00:27:39 -07:00
Junio C Hamano 29dc133198 git-merge-one-file: fix longstanding stupid thinko
When a merge result creates a new file, and when our side already has a
file in the path, taking the merge result may clobber the untracked file.
However, the logic to detect this situation was totally the wrong way.  We
should complain when the file exists, not when the file does not exist.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-18 22:17:17 -07:00
Junio C Hamano ff72af00f8 Support a merge with conflicting gitlink change
merge-recursive did not support merging trees that have conflicting
changes in submodules they contain, and died.  Support it exactly the
same way as how it handles conflicting symbolic link changes --- mark it
as a conflict, take the tentative result from the current side, and
letting the caller resolve the conflict, without dying in merge_file()
function.

Also reword the error message issued when merge_file() has to die
because it sees a tree entry of type it does not support yet.

[jc: fixed up initial draft by Finn Arne Gangstad]

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-11 00:40:56 -08:00
Junio C Hamano 561b0fbb4a Fix merge-one-file for our-side-added/our-side-removed cases
When commit ed93b449 changed the script so that it does not
touch untracked working tree file, we forgot that we still
needed to resolve the index entry (otherwise they are left
unmerged).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-08 18:24:19 -07:00
Junio C Hamano 5be60078c9 Rewrite "git-frotz" to "git frotz"
This uses the remove-dashes target to replace "git-frotz" to "git frotz".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02 22:52:14 -07:00
Junio C Hamano a6080a0a44 War on whitespace
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time.  There are a few files that need
to have trailing whitespaces (most notably, test vectors).  The results
still passes the test, and build result in Documentation/ area is unchanged.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07 00:04:01 -07:00
Johannes Schindelin caba139d43 Use git-merge-file in git-merge-one-file, too
Would you believe? I edited git-merge-one-file (note the missing ".sh"!)
when I submitted the patch which became commit e2b7008752...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-21 20:33:06 -08:00
Junio C Hamano ed93b449c5 merge: loosen overcautious "working file will be lost" check.
The three-way merge complained unconditionally when a path that
does not exist in the index is involved in a merge when it
existed in the working tree.  If we are merging an old version
that had that path tracked, but the path is not tracked anymore,
and if we are merging that old version in, the result will be
that the path is not tracked.  In that case we should not
complain.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-27 17:16:39 -07:00
Pavel Roskin 82e5a82fd7 Fix more typos, primarily in the code
The only visible change is that git-blame doesn't understand
"--compability" anymore, but it does accept "--compatibility" instead,
which is already documented.

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10 00:36:44 -07:00
Mark Wooding f327dbced2 Shell utilities: Guard against expr' magic tokens.
Some words, e.g., `match', are special to expr(1), and cause strange
parsing effects.  Track down all uses of expr and mangle the arguments
so that this isn't a problem.

Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-13 16:45:48 -07:00
Alex Riesen 31f883d1b8 trivial: remove the dots at the end of file names from merge-one-file
to make the output more friendly to mouse copy-paste.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-05 17:23:41 -08:00
Junio C Hamano b539c5e8fb git-merge-one: new merge world order.
This does two things:

 - Use new --stage=2 option to create the working tree file with
   leading paths and correct permission bits using
   checkout-index, as before.

 - Make sure we do not confuse "merge" program when the file
   being merged has an unfortunate name, '-L'.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-07 00:50:33 -08:00
Junio C Hamano be61db922a git-merge-one-file: resurrect leading path creation.
Since we do not use git-update-index followed by
git-checkout-index -u to create the half-merged file on
conflicting case anymore, we need to make sure the leading
directories are created here.

Maybe a better solution would be to allow update-index to add to
higher stage, and checkout-index to extract from such, but that
is a change slightly bigger than I would like to have so close
to 1.0, so this should do for now.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-06 00:07:58 -08:00
Junio C Hamano 54dd99a127 merge-one-file: make sure we do not mismerge symbolic links.
We ran "merge" command on O->A, O->B, A!=B case without
verifying the path involved is not a symlink.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-02 01:08:14 -08:00
Junio C Hamano 1c2c10b6e6 merge-one-file: make sure we create the merged file.
The "update-index followed by checkout-index" chain served two
purposes -- to collapse the index to "our" version, and make
sure that file exists in the working tree.  In the recent update
to leave the index unmerged on conflicting path, we wanted to
stop doing the former, but we still need to do the latter (we
allow merging to work in an un-checked-out working tree).

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-02 01:08:14 -08:00
Junio C Hamano ce3ca27545 git-merge-one-file: do not worry about 'rmdir -p' not removing directory.
9ae2172aed used "rmdir -p"
carelessly, causing the more important "git-update-index
--remove" to be skipped.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01 17:02:04 -08:00
Linus Torvalds 354b9b59b0 merge-one-file: leave unmerged index entries upon automerge failure.
When automerge fails, we used to collapse the path to stage0
from "our" branch, to help "diff-files" users to view the
half-merged state against the current HEAD.  Now diff-files has
been taught how to compare with unmerged stage2,leaving them
unmerged is a better thing to do, especially this prevents the
unresolved conflicts to be committed by mistake.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-30 00:14:19 -08:00
Junio C Hamano 9ae2172aed merge-one-file: use rmdir -p
The flag is universally available, even on VMS; use it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-20 10:40:31 -08:00
Junio C Hamano 397c76697f merge-one-file: remove empty directories
When the last file in a directory is removed as the result of a
merge, try to rmdir the now-empty directory.

[jc: We probably could use "rmdir -p", but for now we do that by
hand for portability.]

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19 19:50:44 -08:00
Junio C Hamano fd66dbf529 merge-one-file: use empty- or common-base condintionally in two-stage merge.
If two sides added the same path completely different thing, it is
easier to see the merge pivoting on /dev/null.  So check the size of
the common section we have found, and empty it if it is too small.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-11 21:18:18 -08:00
Junio C Hamano cb93c19365 merge-one-file: use common as base, instead of emptiness.
Unlike the previous round that merged the path added differently
in each branches using emptiness as the base, compute a common
version and use it as input to 'merge' program.

This would show the resulting (still conflicting) file left in
the working tree as:

	common file contents...
	<<<<<< FILENAME
	version from our branch...
	======
	version from their branch...
	>>>>>> .merge_file_XXXXXX
	more common file contents...

when both sides added similar contents.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-11 21:18:17 -08:00
Junio C Hamano f7d24bbefb merge with /dev/null as base, instead of punting O==empty case
Instead of leaving the path unmerged in a case where each side
adds different version of the same path, attempt to merge it
with empty base and leave "our" version in the index file, just
like we do for the case in conflicting merge.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-11 21:18:17 -08:00
Junio C Hamano 215a7ad1ef Big tool rename.
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 <junkio@cox.net>
2005-09-07 17:45:20 -07:00