Commit Graph

10 Commits

Author SHA1 Message Date
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