kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Linus Torvalds	9e8eceab73	Add 'merge' mode to 'git reset' We have always had a nice way to reset a working tree to another state while carrying our changes around: "git read-tree -u -m". Yes, it fails if the target tree is different in the paths that are dirty in the working tree, but this is how we used to switch branches in "git checkout", and it worked fine. However, perhaps exactly _because_ we've supported this from very early on, another low-level command, namely "git reset", never did. But as time went on, 'git reset' remains as a very common command, while 'git read-tree' is now a very odd and low-level plumbing thing that nobody sane should ever use, because it only makes sense together with other operations like either switching branches or just rewriting HEAD. Which means that we have effectively lost the ability to do something very common: jump to another point in time without always dropping all our dirty state. So add this kind of mode to "git reset", and since it merges your changes to what you are resetting to, just call it that: "git reset --merge". I've wanted this for a long time, since I very commonly carry a dirty tree while working on things. My main 'Makefile' file quite often has the next version already modified, and sometimes I have local modifications that I don't want to commit, but I still do pulls and patch applications, and occasionally want to do "git reset" to undo them - while still keeping my local modifications. (Maybe we could eventually change it to something like "if we have a working tree, default to --merge, otherwise default to --mixed"). NOTE! This new mode is certainly not perfect. There's a few things to look out for: - if the index has unmerged entries, "--merge" will currently simply refuse to reset ("you need to resolve your current index first"). You'll need to use "--hard" or similar in this case. This is sad, because normally a unmerged index means that the working tree file should have matched the source tree, so the correct action is likely to make --merge reset such a path to the target (like --hard), regardless of dirty state in-tree or in-index. But that's not how read-tree has ever worked, so.. - "git checkout -m" actually knows how to do a three-way merge, rather than refuse to update the working tree. So we do know how to do that, and arguably that would be even nicer behavior. At the same time it's also arguably true that there is a chance of loss of state (ie you cannot get back to the original tree if the three-way merge ends up resolving cleanly to no diff at all), so the "refuse to do it" is in some respects the safer - but less user-friendly - option. In other words, I think 'git reset --merge' could become a bit more friendly, but this is already a big improvement. It allows you to undo a recent commit without having to throw your current work away. Yes, yes, with a dirty tree you could always do git stash git reset --hard git stash apply instead, but isn't "git reset --merge" a nice way to handle one particular simple case? Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> -- Hmm? Maybe I'm the only one that does a lot of work with a dirty tree, and sure, I can do other things like the "git stash" thing, or using "git checkout" to actually create a new branch, and then playing games with branch renaming etc to make it work like this one. But I suspect others dislike how "git reset" works too. But see the suggested improvements above. builtin-reset.c \| 26 ++++++++++++++++++-------- 1 files changed, 18 insertions(+), 8 deletions(-)	16 years ago
Miklos Vajna	eca35a25a9	Fix git branch -m for symrefs. This had two problems with symrefs. First, it copied the actual sha1 instead of the "pointer", second it failed to remove the old ref after a successful rename. Given that till now delete_ref() always dereferenced symrefs, a new parameters has been introduced to delete_ref() to allow deleting refs without a dereference. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Dmitry Potapov	048f276200	do not segfault if make_cache_entry failed Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	16 years ago
Dmitry Potapov	d09e2cd551	do not segfault if make_cache_entry failed Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	16 years ago
Stephan Beyer	b0320eaf6a	git-reset: Let -q hush "locally modified" messages "git reset -q" is advertised to "only report errors", but "locally modified" messages are still shown. They are not errors but diagnostics. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	d14e7407b3	"needs update" considered harmful "git update-index --refresh", "git reset" and "git add --refresh" have reported paths that have local modifications as "needs update" since the beginning of git. Although this is logically correct in that you need to update the index at that path before you can commit that change, it is now becoming more and more clear, especially with the continuous push for user friendliness since 1.5.0 series, that the message is suboptimal. After all, the change may be something the user might want to get rid of, and "updating" would be absolutely a wrong thing to do if that is the case. I prepared two alternatives to solve this. Both aim to reword the message to more neutral "locally modified". This patch is a more intrusive variant that changes the message for only Porcelain commands ("add" and "reset") while keeping the plumbing "update-index" intact. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Stephan Beyer	1b1dd23f2d	Make usage strings dash-less When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	dfc8f39e43	Allow "git-reset path" when unambiguous Resetting a selected set of index entries is done with "git reset -- paths" syntax, but we did not allow -- to be omitted even when the command is unambiguous. This updates the command to follow the general rule: * When -- appears, revs come before it, and paths come after it; * When there is no --, earlier ones are revs and the rest are paths, and we need to guess. When lack of -- marker forces us to guess, we protect from user errors and typoes by making sure what we treat as revs do not appear as filenames in the work tree, and what we treat as paths do appear as filenames in the work tree, and by erroring out if that is not the case. We tell the user to disambiguate by using -- in such a case. which is employed elsewhere in the system. When this rule is applied to "reset", because we can have only zero or one rev to the command, the check can be slightly simpler than other programs. We have to check only the first one or two tokens after the command name and options, and when they are: -- A: no explicit rev given; "A" and whatever follows it are paths. A --: explicit rev "A" given and whatever follows the "--" are paths. A B: "A" could be rev or path and we need to guess. "B" could be missing but if exists that (and everything that follows) would be paths. So we apply the guess only in the last case and only to "A" (not "B" and what comes after it). * As long as "A" is unambiguously a path, index entries for "A", "B" (and everything that follows) are reset to the HEAD revision. * If "A" is unambiguously a rev, on the other hand, the index entries for "B" (and everything that follows) are reset to the "A" revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jamis Buck	5aa965a0c1	git-reset: honor -q and do not show progress message When running git-reset in a non-interactive setting, the -q switch works for everything except the progress updates. This squelches it. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Schindelin	ef90d6d420	Provide git_config with a callback-data parameter git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Carlos Rica	5eee6b28b5	Make builtin-reset.c use parse_options. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	2efb3b0617	Clean up find_unique_abbrev() callers Now find_unique_abbrev() never returns NULL, there is no need for callers to prepare for seeing NULL and fall back to giving the full 40-hexdigits. While we are at it, drop "..." in the "git reset" output that reports the location of the new HEAD, between the abbreviated commit object name and the one line commit summary. Because we are always showing the HEAD (which cannot be missing!), we never had a case where we show the full 40 hexdigits that is not followed by three dots, and these three dots were stealing 3 columns from the precious horizontal screen real estate out of 80 that can better be used for the one line commit summary. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Daniel Barkalow	c369e7b805	Move code to clean up after a branch change to branch.c Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>	17 years ago
Daniel Barkalow	94a5728cfb	Library function to check for unmerged index entries It's small, but it was in three places already, so it should be in the library. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>	17 years ago
Brandon Casey	4ed7cd3ab0	Improve use of lockfile API Remove remaining double close(2)'s. i.e. close() before commit_locked_index() or commit_lock_file(). Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jeff King	49b9362fd3	git-reset: refuse to do hard reset in a bare repository It makes no sense since there is no working tree. A soft reset should be fine, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Mike Hommey	03b69c7606	Fix small memory leaks induced by diff_tree_setup_paths Run diff_tree_release_paths in the appropriate places, and add a test to avoid NULL dereference. Better safe than sorry. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Gerrit Pape	521b53e5c7	git-reset: add -q option to operate quietly Many git commands have a -q option to suppress output to stdout, let's have it for git-reset too. This was asked for by Joey Hess through http://bugs.debian.org/444933 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Schindelin	620a6cd42e	builtin-reset: avoid forking "update-index --refresh" Instead of forking update-index, call refresh_cache() directly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Schindelin	cdf4a751fa	builtin-reset: do not call "ls-files --unmerged" Since reset is a builtin now, it can use the full power of libgit.a and check for unmerged entries itself. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Schindelin	2e7a9785c2	git-reset: do not be confused if there is nothing to reset The purpose of the function update_index_from_diff() (which is the callback function we give do_diff_cache()) is to update those index entries which differ from the given commit. Since do_diff_cache() plays games with the in-memory index, this function discarded the cache and reread it. Then, back in the function read_from_tree() we wrote the index. Of course, this broke down when there were no changes and update_index_from_diff() was not called, and therefore the mangled index was not discarded. The solution is to move the index writing into the function update_index_from_diff(). Noticed by Björn Steinbrink. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Shawn O. Pearce	538dfe7397	Improved const correctness for strings Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Carlos Rica	0e5a7faa3a	Make "git reset" a builtin. This replaces the script "git-reset.sh" with "builtin-reset.c". A few git commands used in the script are called from the builtin also: "ls-files" to check for unmerged files, "read-tree" for resetting the index file in "mixed" and "hard" resets, and "update-index" to refresh at the end in the "mixed" reset and also for the option that gets selected paths into the index. The reset option with paths was implemented by Johannes Schindelin. Since the option that gets selected paths into the index is not a "reset" like the others because it does not change the HEAD at all, now the command is showing a warning when the "--mixed" option is supplied for that purpose. The following table shows the behaviour of "git reset" for the different supported options, where X means "changing" the HEAD, index or working tree: reset: --soft --mixed --hard -- <paths> HEAD X X X - index - X X X files - - X - Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago

23 Commits (951886481668b97485640a1b24fc73fccff0d629)