kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Rene Scharfe	2e6183840e	git-reset: remove unused variable Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	dee4e384f3	git-reset: detect update-ref error and report it. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	ac83aa2e1f	git-reset: complain and exit upon seeing an unknown parameter. The check to use "rev-parse --verify" was defeated by the use of "--default HEAD". "git reset --hard bogus-committish" just defaulted to reset to the HEAD without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	7d0c68871a	git-merge --squash Some people tend to do many little commits on a topic branch, recording all the trials and errors, and when the topic is reasonably cooked well, would want to record the net effect of the series as one commit on top of the mainline, removing the cruft from the history. The topic is then abandoned or forked off again from that point at the mainline. The barebone porcelainish that comes with core git tools does not officially support such operation, but you can fake it by using "git pull --no-merge" when such a topic branch is not a strict superset of the mainline, like this: git checkout mainline git pull --no-commit . that-topic-branch : fix conflicts if any rm -f .git/MERGE_HEAD git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged This however does not work when the topic branch is a fast forward of the mainline, because normal "git pull" will never create a merge commit in such a case, and there is nothing special --no-commit could do to begin with. This patch introduces a new option, --squash, to support such a workflow officially in both fast-forward case and true merge case. The user-level operation would be the same in both cases: git checkout mainline git pull --squash . that-topic-branch : fix conflicts if any -- naturally, there would be : no conflict if fast forward. git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged When the current branch is already up-to-date with respect to the other branch, there truly is nothing to do, so the new option does not have any effect. This was brought up in #git IRC channel recently. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Shawn Pearce	67644a4d77	Include ref log detail in commit, reset, etc. When updating a ref at the direction of the user include a reason why head was changed as part of the ref log (assuming it was enabled). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	c68998f5b5	Simplify "git reset --hard" Now that the one-way merge strategy does the right thing wrt files that do not exist in the result, just remove all the random crud we did in "git reset" to do this all by hand. Instead, just pass in "-u" to git-read-tree when we do a hard reset, and depend on git-read-tree to update the working tree appropriately. This basically means that git reset turns into # Always update the HEAD ref git update-ref HEAD "$rev" case "--soft" # do nothing to index/working tree case "--hard" # read index _and_ update working tree git-read-tree --reset -u "$rev" case "--mixed" # update just index, report on working tree differences git-read-tree --reset "$rev" git-update-index --refresh which is what it was always semantically doing, it just did it in a rather strange way because it was written to not expect git-read-tree to do anything to the working tree. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Shawn Pearce	772d8a3b63	Make git-reset delete empty directories When git-reset --hard is used and a subdirectory becomes empty (as it contains no tracked files in the target tree) the empty subdirectory should be removed. This matches the behavior of git-checkout-index and git-read-tree -m which would not have created the subdirectory or would have deleted it when updating the working directory. Subdirectories which are not empty will be left behind. This may happen if the subdirectory still contains object files from the user's build process (for example). [jc: simplified the logic a bit, while keeping the test script.]	19 years ago
Junio C Hamano	8389b52b2a	git-rerere: reuse recorded resolve. In a workflow that employs relatively long lived topic branches, the developer sometimes needs to resolve the same conflict over and over again until the topic branches are done (either merged to the "release" branch, or sent out and accepted upstream). This commit introduces a new command, "git rerere", to help this process by recording the conflicted automerge results and corresponding hand-resolve results on the initial manual merge, and later by noticing the same conflicted automerge and applying the previously recorded hand resolution using three-way merge. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Alex Riesen	6ff0b1c56c	use GIT_DIR instead of /var/tmp Not every system (will not one microsoft windows system) have /var/tmp, whereas using GIT_DIR for random temporary files is more or less established. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
freku045@student.liu.se	806f36d4d7	Trivial usage string clean-up Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	ae2b0f1518	git-sh-setup: die if outside git repository. Now all the users of this script detect its exit status and die, complaining that it is outside git repository. So move the code that dies from all callers to git-sh-setup script. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
c.shoemaker@cox.net	2f9d685c61	Add usage help for git-reset.sh Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	bf7960eb51	Use git-update-ref in scripts. This uses the git-update-ref command in scripts for safer updates. Also places where we used to read HEAD ref by using "cat" were fixed to use git-rev-parse. This will matter when we start using symbolic references. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	c3bc895c81	Remove use of 'xargs -0' from git-reset. Even without the trouble it causes to people without GNU xargs, it was not really necessary to print from Perl and then remove it outside. Just unlink it inside Perl. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	e8623d45b4	Squelch `removal' message from 'git reset --hard'. We do not say anything about checking out, so mentioning removal only gets unnecessarily alarming. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 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>	20 years ago
Junio C Hamano	45d197a469	Introduce "reset type" flag to "git reset" I have been feeling that the current behaviour of "git reset" is not quite optimal, but so far could not express exactly what I felt was wrong with it. This patch clarifies it. There are at least two situations you may want to "reset" your working tree. 1. You made a mess in your working tree. You want to switch back to a known good state and start over. This mess may be a result of your own editing, a merge that had too many conflicting changes that you do not feel like to resolve by hand at this moment, or a botched application of a patch you received from somewhere. In this case, you would want to have "git reset HEAD" reset the index file to the tree read from the HEAD commit and the files in the working tree to match index (i.e. "git status" should say "Nothing to commit", without any "unrecorded changes"). The current behaviour leaves the files in the working tree intact, which requires you to run "git checkout -f". Also you need to remember "rm -f" any files that the botched patch may have left in the working tree if the purpose of this "reset" is to attempt to apply it again; most likely the patch would fail if such a file is left behind. 2. You have discovered that commits you made earlier need to be reorganized. The simplest example is to undo the last commit, re-edit some files, and redo the commit. Another simple eample is to undo the last two commits, and commit the changes in those two commits as a single commit. In this case, you would want to have "git reset HEAD^" reset the $GIT_DIR/HEAD to the commit object name of the parent commit of the current commit (i.e. rewinding one commit), leave the index file and the files in the working tree in a state where you can easily make a commit that records a tree that resembles what you have in the current index file and the working tree. The current behaviour is almost OK for this purpose, except that you need to find which files you need to manually run "git add" yourself. They are files that are in the original HEAD commit and not in the commit you are resetting to. The default without the type flag is to do "--mixed", which is the current behaviour. $ git reset [ --hard \| --soft \| --mixed ] [ <commit-ish> ] A hard reset would be used for 1 and works in this way: (1) remember the set of paths that appear in the current index file (which may even have unmerged entries) and the current $GIT_DIR/HEAD commit. (2) "read-tree --reset" the specified <commit-ish> (default to HEAD), followed by "checkout-cache -f -u -a". (3) remove any files that appear in (1) but not in <commit-ish> from the working tree. (4) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update $GIT_DIR/HEAD with the specified <commit-ish>. (5) remove leftover $GIT_DIR/MERGE_HEAD A soft reset would be used for 2 and works in this way: (1) Make sure that the index file is merged and we do not have MERGE_HEAD; otherwise it does not make sense to do soft reset. (2) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update $GIT_DIR/HEAD with the specified <commit-ish>. Note that with the current behaviour, "git diff" is the way to see what could be committed immediately after "git reset". With the "soft reset" described here you would need to say "git diff HEAD" to find that out. I am not sure what mixed reset (the current behaviour) is good for. If nobody comes up with a good use case it may not be a bad idea to remove it. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	2ad77e67c7	Audit rev-parse users. Make sure that we say --verify when we want to get a single SHA1 name. Also when we say --verify, --revs-only is redundant. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	32173e6988	Stash away the original head in ORIG_HEAD when resetting. When rewinding the head, stash away the value of the original HEAD in ORIG_HEAD, just like git-resolve-script does. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Linus Torvalds	bfe19f876c	[PATCH] Extend "git reset" to take a reset point This was triggered by a query by Sam Ravnborg, and extends "git reset" to reset the index and the .git/HEAD pointer to an arbitrarily named point. For example git reset HEAD^ will just reset the current HEAD to its own parent - leaving the working directory untouched, but effectively un-doing the top-most commit. You might want to do this if you realize after you committed that you made a mistake that you want to fix up: reset your HEAD back to its previous state, fix up the working directory and re-do the commit. If you want to totally un-do the commit (and reset your working directory to that point too), you'd first use "git reset HEAD^" to reset to the parent, and then do a "git checkout -f" to reset the working directory state to that point in time too. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Linus Torvalds	b33e966608	Add "git-sh-setup-script" for common git shell script setup It sets up the normal git environment variables and a few helper functions (currently just "die()"), and returns ok if it all looks like a git archive. So use it something like . git-sh-setup-script \|\| die "Not a git archive" to make the rest of the git scripts more careful and readable.	20 years ago
Linus Torvalds	ef0bfa25e9	Remove MERGE_HEAD in "git checkout/reset" Both of these scripts will end up resetting the index to some specific head, and any unresolved merge will be forgotten.	20 years ago
Linus Torvalds	40d8cfe411	Trivial git script fixups Fix permissions, and add trivial "reset" and "add" scripts. The "reset" script just resets the index back to head, while the "add" script is just a crutch for people used to do "cvs add".	20 years ago

16 Commits (83b5d2f5b0c95fe102bc3d1cc2947abbdf5e5c5b)