kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
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>	19 years ago
Linus Torvalds	cdcb0ed411	[PATCH] Make "git resolve" less scary When we resolve a merge between two branches, and it removes a file in the current branch, we notify the person doing the resolve with a big nice notice like Removing xyzzy which is all well and good. HOWEVER, we also do this when the file was actually removed in the current branch, and we're merging with another branch that didn't have it removed (or, indeed, if the other branch _did_ have it removed, but the common parent was far enough back that the file still existed in there). And that just doesn't make sense. In that case we're not removing anything: the file didn't exist in the branch we're merging into in the first place. So the message just makes people nervous, and makes no sense. This has been around forever, but I never bothered to do anything about it. Until now. The trivial fix is to only talk about removing files if the file existed in the branch we're merging into, but will not exist in the result. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Petr Baudis	0b124bb4bf	[PATCH] Trivial tidyups Simple whitespace-related tidyups ensuring style consistency. This is carried over from my old git-pb branch. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	aacc15ec52	[PATCH] git-merge-one-file-script: do not misinterpret rm failure. When a merge adds a file DF and removes a directory there by deleting a path DF/DF, git-merge-one-file-script can be called for the removal of DF/DF when the path DF is already created by "git-read-tree -m -u". When this happens, we get confused by a failure return from 'rm -f -- "$4"' (where $4 is DF/DF); finding file DF there the "rm -f" command complains that DF is not a directory. What we want to ensure is that there is no file DF/DF in this case. Avoid getting ourselves confused by first checking if there is a file, and only then try to remove it (and check for failure from the "rm" command). Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	98a96b00b8	One more time.. Clean up git-merge-one-file-script This uses git-checkout-file to make sure that the full pathname is created, instead of the script having to verify it by hand. Also, simplify the 3-way merge case by just writing to the right file and setting the initial index contents early.	20 years ago
Linus Torvalds	e0226add28	Fix up git-merge-one-file-script Junio points out that we may need to create the path leading up the the file we merge. And we need to be more careful with the "exec"s we've done to exit on success - only do the on the last command in the pipeline, not the first one ;)	20 years ago
Petr Baudis	ec73962d8e	[PATCH] git-merge-one-file-script cleanups from Cogito Chain the resolving sequences (e.g. git-cat-file - chmod - git-update-cache) through &&s so we stop right away in case one of the command fails, and report the error code to the script caller. Also add a copyright notice, some blank lines, ;; on a separate line, and nicer error messages. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	ae3858e7e9	Make sure we error out if we can't remove a file on automatic merges. Pointed out by Junio.	20 years ago
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>	20 years ago
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.	20 years ago
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>	20 years ago
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>	20 years ago
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>	20 years ago
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>	20 years ago
Linus Torvalds	2d280e1c5e	Update the merge scripts for the big git rename. Let's see what else I forgot..	20 years ago
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>	20 years ago
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.	20 years ago
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".	20 years ago
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.	20 years ago

1 Commits (0363ecf6414e75d4423814ba930f67edaef91683)