kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Linus Torvalds	81b50f3ce4	Move 'builtin-' into a 'builtin/' subdirectory This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Christian Couder	9bc454df08	reset: add option "--keep" to "git reset" The purpose of this new option is to discard some of the last commits but to keep current changes in the work tree. The use case is when you work on something and commit that work. And then you work on something else that touches other files, but you don't commit it yet. Then you realize that what you commited when you worked on the first thing is not good or belongs to another branch. So you want to get rid of the previous commits (at least in the current branch) but you want to make sure that you keep the changes you have in the work tree. And you are pretty sure that your changes are independent from what you previously commited, so you don't want the reset to succeed if the previous commits changed a file that you also changed in your work tree. The table below shows what happens when running "git reset --keep target" to reset the HEAD to another commit (as a special case "target" could be the same as HEAD). working index HEAD target working index HEAD ---------------------------------------------------- A B C D --keep (disallowed) A B C C --keep A C C B B C D --keep (disallowed) B B C C --keep B C C In this table, A, B and C are some different states of a file. For example the last line of the table means that if a file is in state B in the working tree and the index, and in a different state C in HEAD and in the target, then "git reset --keep target" will put the file in state B in the working tree, and in state C in the index and in HEAD. The following table shows what happens on unmerged entries: working index HEAD target working index HEAD ---------------------------------------------------- X U A B --keep (disallowed) X U A A --keep X A A In this table X can be any state and U means an unmerged entry. Though the error message when "reset --keep" is disallowed on unmerged entries is something like: error: Entry 'file1' would be overwritten by merge. Cannot merge. fatal: Could not reset index file to revision 'HEAD^'. which is not very nice. A following patch will add some test cases for "--keep". The "--keep" option is implemented by doing a 2 way merge between HEAD and the reset target, and if this succeeds by doing a mixed reset to the target. The code comes from the sequencer GSoC project, where such an option was developed by Stephan Beyer: git://repo.or.cz/git/sbeyer.git (at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079) But in the sequencer project the "reset" flag was set in the "struct unpack_trees_options" passed to "unpack_trees()". With this flag the changes in the working tree were discarded if the file was different between HEAD and the reset target. Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Stephan Beyer	d0f379c2dc	reset: use "unpack_trees()" directly instead of "git read-tree" This patch makes "reset_index_file()" call "unpack_trees()" directly instead of forking and execing "git read-tree". So the code is more efficient. And it's also easier to see which unpack_tree() options will be used, as we don't need to follow "git read-tree"'s command line parsing which is quite complex. As Daniel Barkalow found, there is a difference between this new version and the old one. The old version gives an error for "git reset --merge" with unmerged entries, and the new version does not when we reset the entries to some states that differ from HEAD. Instead, it resets the index entry and succeeds, while leaving the conflict markers in the corresponding file in the work tree (which will be corrected by the next patch). The code comes from the sequencer GSoC project: git://repo.or.cz/git/sbeyer.git (at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079) Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Christian Couder	2b06b0a02f	reset: improve mixed reset error message when in a bare repo When running a "git reset --mixed" in a bare repository, the message displayed is something like: fatal: This operation must be run in a work tree fatal: Could not reset index file to revision 'HEAD^'. This message is a little bit misleading because a mixed reset is ok in a git directory, so it is not absolutely needed to run it in a work tree. So this patch improves upon the above by changing the message to: fatal: mixed reset is not allowed in a bare repository And if "git reset" is ever sped up by using unpack_tree() directly (instead of execing "git read-tree"), this patch will also make sure that a mixed reset is still disallowed in a bare repository. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jeff King	cd0f0f68e1	reset: unbreak hard resets with GIT_WORK_TREE Commit `952dfc6` tried to tighten the safety valves for doing a "reset --hard" in a bare repository or outside the work tree, but accidentally broke the case for GIT_WORK_TREE. This patch unbreaks it. Most git commands which need a work tree simply use NEED_WORK_TREE in git.c to die before they get to their cmd_* function. Reset, however, only needs a work tree in some cases, and so must handle the work tree itself. The error that `952dfc6` made was to simply forbid certain operations if the work tree was not set up; instead, we need to do the same thing that NEED_WORK_TREE does, which is to call setup_work_tree(). We no longer have to worry about dying in the non-worktree case, as setup_work_tree handles that for us. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jeff King	952dfc6944	reset: improve worktree safety valves The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Felipe Contreras	5d2dcc423e	General --quiet improvements 'git reset' is missing --quiet, and 'git gc' is not using OPT__QUIET. Let's fix that. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Matthieu Moy	3deffc52d8	reset: make the reminder output consistent with "checkout" git reset without argument displays a summary of the local modification, like this: $ git reset Makefile: locally modified Some people have problems with this; they look like an error message. This patch makes its output mimic how "git checkout $another_branch" reports the paths with local modifications. "git add --refresh --verbose" is changed in the same way. It also adds a header to make it clear that the output is informative, and not an error. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>	16 years ago
Matthieu Moy	43673fddd3	Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN. The change in the output is going to become more general than just saying "changed", so let's make the variable name more general too. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Thomas Rast	d002ef4d94	Implement 'git reset --patch' This introduces a --patch mode for git-reset. The basic case is git reset --patch -- [files...] which acts as the opposite of 'git add --patch -- [files...]': it offers hunks for unstaging. Advanced usage is git reset --patch <revision> -- [files...] which offers hunks from the diff between the index and <revision> for forward application to the index. (That is, the basic case is just <revision> = HEAD.) Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Stephen Boyd	3778292017	parse-opts: prepare for OPT_FILENAME To give OPT_FILENAME the prefix, we pass the prefix to parse_options() which passes the prefix to parse_options_start() which sets the prefix member of parse_opts_ctx accordingly. If there isn't a prefix in the calling context, passing NULL will suffice. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Mike Ralphson	3ea3c215c0	Fix typos / spelling in comments Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
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

3 Commits (ec136663c7d5a8e2ce1664ce79f2297e2e61c86f)