aboutsummaryrefslogtreecommitdiff
path: root/git-reset-script
Commit message (Collapse)AuthorAge
* Big tool rename.Junio C Hamano2005-09-07
| | | | | | | | | | | | | | | | | | | 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>
* Introduce "reset type" flag to "git reset"Junio C Hamano2005-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Audit rev-parse users.Junio C Hamano2005-08-15
| | | | | | | 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>
* Stash away the original head in ORIG_HEAD when resetting.Junio C Hamano2005-08-09
| | | | | | | 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>
* [PATCH] Extend "git reset" to take a reset pointLinus Torvalds2005-08-06
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Add "git-sh-setup-script" for common git shell script setupLinus Torvalds2005-07-08
| | | | | | | | | | 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.
* Remove MERGE_HEAD in "git checkout/reset"Linus Torvalds2005-06-21
| | | | | Both of these scripts will end up resetting the index to some specific head, and any unresolved merge will be forgotten.
* Trivial git script fixupsLinus Torvalds2005-06-14
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".