git-reset to remove "$GIT_DIR/MERGE_MSG"

2006-12-06T18:47:14Z

An earlier commit a9cb3c6e changed git-commit to use the contents of MERGE_MSG even when we do not have MERGE_HEAD (the rationale is in its log message). However, the change tricks the following sequence to include a merge message in a completely unrelated commit: $ git pull somewhere : oops, the conflicts are too much. forget it. $ git reset --hard : work work work $ git commit To fix this confusion, this patch makes "git reset" to remove the leftover MERGE_MSG that was prepared when the user abandoned the merge. Signed-off-by: Junio C Hamano Acked-by: Luben Tuikov

git-reset: remove unused variable

2006-08-27T22:32:37Z

Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

git-reset: detect update-ref error and report it.

2006-07-28T05:27:44Z

Signed-off-by: Junio C Hamano

git-reset: complain and exit upon seeing an unknown parameter.

2006-07-06T02:44:03Z

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

git-merge --squash

2006-06-24T08:11:19Z

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

Include ref log detail in commit, reset, etc.

2006-05-19T22:03:21Z

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 Signed-off-by: Junio C Hamano

Simplify "git reset --hard"

2006-05-14T23:48:33Z

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 Signed-off-by: Junio C Hamano

Make git-reset delete empty directories

2006-02-18T07:52:57Z

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.]

git-rerere: reuse recorded resolve.

2006-02-07T05:53:11Z

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

use GIT_DIR instead of /var/tmp

2006-01-06T01:24:51Z

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 Signed-off-by: Junio C Hamano

user/sven/git.git/git-reset.sh, branch v1.4.4.4