kernel/git - git - PowerEL Git System

Tree: 652d5dc6c0

Author	SHA1	Message	Date
Junio C Hamano	e2f5f6ef67	Do not require clean tree when reverting and cherry-picking. My stupidity deserved to be yelled at by Linus ... there is no reason to require the working tree to be clean when merging -- the only requirements are index to match HEAD commit and the paths involved in merge are up to date in the working tree. Revert and cherry-pick are just specialized forms of merge, and the requirements should be the same. Remove the 'general purpose routine to make sure tree is clean' from git-sh-setup, to prevent me from getting tempted again. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
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
Junio C Hamano	9fa4db544e	Do not verify reverted/cherry-picked/rebased patches. The original committer may have used validation criteria that is less stricter than yours. You do not want to lose the changes even if they are done in substandard way from your 'commit -v' verifier's point of view. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	48313592bf	Redo "revert" using three-way merge machinery. The reverse patch application using "git apply" sometimes is too rigid. Since the user would get used to resolving conflicting merges by hand during the normal merge experience, using the same machinery would be more helpful rather than just giving up. Cherry-picking and reverting are essentially the same operation. You pick one commit, and apply the difference that commit introduces to its own commit ancestry chain to the current tree. Revert applies the diff in reverse while cherry-pick applies it forward. They share the same logic, just different messages and merge direction. Rewrite "git rebase" using "git cherry-pick". Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	ff84d327df	Audit rev-parse users again. Some callers to rev-parse were using the output selection flags inconsistently. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	045f82cbee	git-revert: revert an existing commit. Given one existing commit, revert the change the patch introduces, and record a new commit that records it. This requires your working tree to be clean (no modifications from the HEAD commit). This is based on what Linus posted to the list, with enhancements he suggested, including the use of -M to attempt reverting renames. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago