1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-06-09 02:26:11 +02:00
Commit Graph

11 Commits

Author SHA1 Message Date
Petr Baudis 8544a6f1b8 [PATCH] Fix git-merge-one-file permissions auto-merging
In the automerge case, permissions were not restored properly after the
merge tool was invoked and overwrote the target file.

Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-08 15:54:45 -07:00
Linus Torvalds 2a68a8659f Leave merge failures in the filesystem
This changes how we handle merges: if a automated merge
fails, we will leave the index as a clean entry pointing
to the original branch, and leave the actual file _dirty_
the way the "merge" program left it.

You can then just do "git-diff-files -p" to see what the
merge conflicts did, fix them up, and commit the end result.

NOTE NOTE NOTE! Do _not_ use "git commit" to commit such
a merge. It won't set the parents right. I'll need to fix
that. In the meantime, you'd need to merge using

	git-commit-tree $(git-write) -p HEAD -p MERGE_HEAD

or something like that by hand.
2005-06-08 11:40:59 -07:00
Junio C Hamano c7d1d4e1b5 Use backticks in git-merge-one-file-script instead of $(command).
Thomas Glanzmann says that shell he uses on Solaris cannot grok
$(command) but the script does not use nested $(command) and 
works happily just by using backticks instead.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-05-07 12:26:15 -07:00
Junio C Hamano ee28152d03 Update git-merge-one-file-script.
With this change, git-merge-one-file-script ceases to smudge
files in the work tree when recording the trivial merge results
(conflicting auto-merge failure case does not touch the work
tree file as before).

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-05-01 23:53:32 -07:00
Junio C Hamano 21a08dcbe7 [PATCH] Really fix git-merge-one-file-script this time.
The merge-cache program was updated to pass executable bits when
calling git-merge-one-file-script, but the called script
supplied as an example were not using them carefully.

This patch fixes the following problems in the script:

 * When a new file is created in a directory, which is a file in
   the work tree, it tried to create leading directory but did
   not check for failure from the "mkdir -p" command.

 * The script did not check the exit status from the
   git-update-cache command at all.

 * The parameter "$4" to the script is a file name that can
   contain almost any characters, so it must be quoted with
   double quotes and also needs to be preceded with -- to mark
   it as a non-option when passed to certain commands.

 * The chmod command was used with parameter "$6" or "$7" to set
   the mode bits.  This contradicts with the strategy taken by
   checkout-cache, where we honor user's umask and force only
   the executable bits.  With this patch, it creates a new file
   by redirecting into it (thus honoring user's default umask),
   and then uses "chmod +x" if we want the resulting file
   executable.  Without this fix, the merge result becomes 0644
   or 0755 for users whose umask is 002 for whom it should
   become 0664 or 0775.

 * When "$1 -> $2 -> $3" case was not handled, the script did
   not say which path it was working on, which was not so useful
   when used with the -a option of git-merge-cache.

Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 09:33:12 -07:00
Junio C Hamano 0fc65a4572 [PATCH] leftover bits for git rename
Linus said:

    "Let's see what else I forgot.."

Not that many, but here they are.

Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-29 16:25:05 -07:00
Linus Torvalds 2d280e1c5e Update the merge scripts for the big git rename.
Let's see what else I forgot..
2005-04-29 15:02:43 -07:00
James Bottomley e2b6a9d0bf [PATCH] make file merging respect permissions
1) permissions aren't respected in the merge script (primarily because
they're never passed in to it in the first place).  Fix that and also
check for permission conflicts in the merge

2) the delete of a file in both branches may indeed be just that, but it
could also be the indicator of a rename conflict (file moved to
different locations in both branches), so error out and ask the
committer for guidance.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-23 20:50:10 -07:00
James Bottomley 0a9ea85000 [PATCH] SCSI trees, merges and git status
Doing the latest SCSI merge exposed two bugs in your merge script:

1) It doesn't like a completely new directory (the misc tree contains a
   new drivers/scsi/lpfc)
2) the merge testing logic is wrong.  You only want to exit 1 if the
   merge fails.
2005-04-18 19:55:19 -07:00
Linus Torvalds e3b4be7f6c Change merge-cache and git-merge-one-file to use the SHA1 of the file
instead of a checked-out temporary copy.

If merging requires a checked-out-copy, we now do so with "unpack-file".
2005-04-18 14:17:58 -07:00
Linus Torvalds 839a7a06f3 Add the simple scripts I used to do a merge with content conflicts.
They sure as hell aren't perfect, but they allow you to do:

	./git-pull-script {other-git-directory}

to do the initial merge, and if that had content clashes, you do

	merge-cache ./git-merge-one-file-script -a

which tries to auto-merge. When/if the auto-merge fails, it will
leave the last file in your working directory, and you can edit
it and then when you're happy you can do "update-cache filename"
on it. Re-do the merge-cache thing until there are no files left
to be merged, and now you can write the tree and commit:

	write-tree
	commit-tree .... -p $(cat .git/HEAD) -p $(cat .git/MERGE_HEAD)

and you're done.
2005-04-18 12:15:10 -07:00