summaryrefslogtreecommitdiff
path: root/wt-status.c
AgeCommit message (Collapse)AuthorFilesLines
2007-09-19Enable wt-status to run against non-standard index file.Libravatar Kristian Høgsberg1-1/+2
We still default to get_index_file(), but this can be overridden by setting wt_status.index_file after calling wt_status_prepare(). Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Enable wt-status output to a given FILE pointer.Libravatar Kristian Høgsberg1-41/+44
Still defaults to stdout, but you can now override wt_status.fp after calling wt_status_prepare(). Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Fix the rename detection limit checkingLibravatar Linus Torvalds1-0/+1
This adds more proper rename detection limits. Instead of just checking the limit against the number of potential rename destinations, we verify that the rename matrix (which is what really matters) doesn't grow ridiculously large, and we also make sure that we don't overflow when doing the matrix size calculation. This also changes the default limits from unlimited, to a rename matrix that is limited to 100 entries on a side. You can raise it with the config entry, or by using the "-l<n>" command line flag, but at least the default is now a sane number that avoids spending lots of time (and memory) in situations that likely don't merit it. The choice of default value is of course very debatable. Limiting the rename matrix to a 100x100 size will mean that even if you have just one obvious rename, but you also create (or delete) 10,000 files, the rename matrix will be so big that we disable the heuristics. Sounds reasonable to me, but let's see if people hit this (and, perhaps more importantly, actually *care*) in real life. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-08Missing statics.Libravatar Pierre Habouzit1-1/+1
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-21Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano1-0/+9
* maint-1.5.1: git-status: respect core.excludesFile SubmittingPatches: mention older C compiler compatibility git-daemon: don't ignore pid-file write failure
2007-05-21git-status: respect core.excludesFileLibravatar Johannes Schindelin1-0/+9
git-add reads this variable, and honours the contents of that file if that exists. Match this behaviour in git-status, too. Noticed by Evan Carroll on IRC. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-31Optimize directory listing with pathspec limiter.Libravatar Linus Torvalds1-1/+1
The way things are set up, you can now pass a "pathspec" to the "read_directory()" function. If you pass NULL, it acts exactly like it used to do (read everything). If you pass a non-NULL pointer, it will simplify it into a "these are the prefixes without any special characters", and stop any readdir() early if the path in question doesn't match any of the prefixes. NOTE! This does *not* obviate the need for the caller to do the *exact* pathspec match later. It's a first-level filter on "read_directory()", but it does not do the full pathspec thing. Maybe it should. But in the meantime, builtin-add.c really does need to do first read_directory(dir, .., pathspec); if (pathspec) prune_directory(dir, pathspec, baselen); ie the "prune_directory()" part will do the *exact* pathspec pruning, while the "read_directory()" will use the pathspec just to do some quick high-level pruning of the directories it will recurse into. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-26Merge branch 'master' into js/diff-niLibravatar Junio C Hamano1-2/+2
* master: (201 commits) Documentation: link in 1.5.0.2 material to the top documentation page. Documentation: document remote.<name>.tagopt GIT 1.5.0.2 git-remote: support remotes with a dot in the name Documentation: describe "-f/-t/-m" options to "git-remote add" diff --cc: fix display of symlink conflicts during a merge. merge-recursive: fix longstanding bug in merging symlinks merge-index: fix longstanding bug in merging symlinks diff --cached: give more sensible error message when HEAD is yet to be created. Update tests to use test-chmtime Add test-chmtime: a utility to change mtime on files Add Release Notes to prepare for 1.5.0.2 Allow arbitrary number of arguments to git-pack-objects rerere: do not deal with symlinks. rerere: do not skip two conflicted paths next to each other. Don't modify CREDITS-FILE if it hasn't changed. diff-patch: Avoid emitting double-slashes in textual patch. Reword git-am 3-way fallback failure message. Limit filename for format-patch core.legacyheaders: Use the description used in RelNotes-1.5.0 ...
2007-02-22run_diff_{files,index}(): update calling convention.Libravatar Junio C Hamano1-2/+10
They used to open and read index themselves, but they now expect their callers to do so. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20prefixcmp(): fix-up leftover strncmp().Libravatar Junio C Hamano1-1/+1
There were instances of strncmp() that were formatted improperly (e.g. whitespace around parameter before closing parenthesis) that caused the earlier mechanical conversion step to miss them. This step cleans them up. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Mechanical conversion to use prefixcmp()Libravatar Junio C Hamano1-2/+2
This mechanically converts strncmp() to use prefixcmp(), but only when the parameters match specific patterns, so that they can be verified easily. Leftover from this will be fixed in a separate step, including idiotic conversions like if (!strncmp("foo", arg, 3)) => if (!(-prefixcmp(arg, "foo"))) This was done by using this script in px.perl #!/usr/bin/perl -i.bak -p if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) { s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|; } if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) { s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|; } and running: $ git grep -l strncmp -- '*.c' | xargs perl px.perl Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-09wt_status_prepare(): clean up structure initialization.Libravatar Junio C Hamano1-8/+1
Otherwise it would be a pain to add members to it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28wt-status: Actually accept `color.status.BLAH' configuration variables.Libravatar Mark Wooding1-1/+1
A stupid typo stopped this from working. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-13simplify the "no changes added to commit" messageLibravatar Nicolas Pitre1-1/+1
Suggesting the use of [-a|-i|-o] with git-commit is unnecessarily complex and confusing. In this context -o is totally useless and -i requires extra arguments which are not mentioned. The only sensible hint (besides reading the man page but let's not go there) is "commit -a". Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-11Merge branch 'jc/detached-head'Libravatar Junio C Hamano1-2/+11
* jc/detached-head: git-checkout: handle local changes sanely when detaching HEAD git-checkout: safety check for detached HEAD checks existing refs git-checkout: fix branch name output from the command git-checkout: safety when coming back from the detached HEAD state. git-checkout: rewording comments regarding detached HEAD. git-checkout: do not warn detaching HEAD when it is already detached. Detached HEAD (experimental) git-branch: show detached HEAD git-status: show detached HEAD
2007-01-11git-status: wording update to deal with deleted files.Libravatar Junio C Hamano1-3/+16
If you do: $ /bin/rm foo $ git status we used to say "git add ... to add content to commit". But suggsting "git add" to record the deletion of a file is simply insane. So this rewords various things: - The section header is the old "Changed but not updated", instead of "Changed but not added"; - Suggestion is "git add ... to update what will be committed", instead of "... to add content to commit"; - If there are removed paths, the above suggestion becomes "git add/rm ... to update what will be committed"; - For untracked files, the suggestion is "git add ... to include in what will be committed". Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10Provide better feedback for the untracked only case in status outputLibravatar Jürgen Rühle1-9/+12
Since 98bf8a47c296f51ea9722fef4bb81dbfb70cd4bb status would claim that git-commit could be useful even if there are no changes except untracked files. Since wt-status is already computing all the information needed go the whole way and actually track the (non-)emptiness of all three sections separately, unify the code, and provide useful messages for each individual case. Thanks to Junio and Michael Loeffler for suggestions. Signed-off-by: Jürgen Rühle <j-r@online.de>
2007-01-08git-status: show detached HEADLibravatar Junio C Hamano1-2/+11
This makes git-status to state when you are not on any branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-07Remove unnecessary git-rm --cached reference from status outputLibravatar Jürgen Rühle1-2/+2
Since git-reset has learned restoring the absence of paths git-rm --cached is no longer necessary. Therefore remove it from the cached content header hint. Also remove the unfortunate wording 'Cached' from the header itself. Signed-off-by: Jürgen Rühle <j-r@online.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-02Improve cached content header of status outputLibravatar Jürgen Rühle1-4/+14
This tries to be more to the point while also including a pointer on how to unstage changes from the index. Since this header is printed in two different code paths and the name of the reference commit is needed for the unstage part, provide a new printing function. Signed-off-by: Jürgen Rühle <j-r@online.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-02Support --amend on initial commit in status outputLibravatar Jürgen Rühle1-2/+3
We check the existence of the parent commit to determine whether the status is requested for an initial commit. Since the parent commit depends on the presence of the --amend switch do initial commit detection after command line arguments have been handled. Signed-off-by: Jürgen Rühle <j-r@online.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-02Improve "nothing to commit" part of status outputLibravatar Jürgen Rühle1-6/+18
Previously git-status in a clean working directory would advice the user to use git add. This isn't very helpful when there is nothing to add in the working directory, therefore note a clean working directory while displaying the other sections and print the appropriate message for each case. Signed-off-by: Jürgen Rühle <j-r@online.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-02Clarify syntax and role of git-add in status outputLibravatar Jürgen Rühle1-1/+1
This uses the actual (simplified) synopsis line from the git-add man page and advertises its incremental nature. Signed-off-by: Jürgen Rühle <j-r@online.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-1/+1
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15git-status always says what branch it's onLibravatar Andy Parkins1-1/+1
If the current branch was "master" then git-status wouldn't say # On branch XXXX In its output. This patch makes it so that this message is always output; regardless of branch name. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Align section headers of 'git status' to new 'git add'.Libravatar Shawn O. Pearce1-4/+5
Now that 'git add' is considered a first-class UI for 'update-index' and that the 'git add' documentation states "Even modified files must be added to the set of changes about to be committed" we should make the output of 'git status' align with that documentation and common usage. So now we see a status output such as: # Added but not yet committed: # (will commit) # # new file: x # # Changed but not added: # (use "git add file1 file2" to include for commit) # # modified: x # # Untracked files: # (use "git add" on files to include for commit) # # y which just reads better in the context of using 'git add' to manipulate a commit (and not a checkin, whatever the heck that is). We also now support 'color.status.added' as an alias for the existing 'color.status.updated', as this alias more closely aligns with the current output and documentation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Suggest use of "git add file1 file2" when there is nothing to commit.Libravatar Shawn O. Pearce1-5/+6
If a user modifies files and runs 'git commit' (without the very useful -a option) and they have not yet updated the index they are probably coming from another SCM-like tool which would perform the same as 'git commit -a' in this case. Showing the user their current status and a final line of "nothing to commit" is not very reassuring, as the user might believe that Git did not recognize their files were modified. Instead we can suggest as part of the 'nothing to commit' message that the user invoke 'git add' to add files to their next commit. Suggested by Andy Parkins' Git 'niggles' list (<200612132237.10051.andyparkins@gmail.com>). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-13Merge branch 'np/addcommit'Libravatar Junio C Hamano1-1/+1
* np/addcommit: git-commit: allow --only to lose what was staged earlier. Documentation/git-commit: rewrite to make it more end-user friendly. make 'git add' a first class user friendly interface to the index
2006-12-13Allow subcommand.color and color.subcommand color configurationLibravatar Andy Parkins1-2/+2
While adding colour to the branch command it was pointed out that a config option like "branch.color" conflicts with the pre-existing "branch.something" namespace used for specifying default merge urls and branches. The suggested solution was to flip the order of the components to "color.branch", which I did for colourising branch. This patch does the same thing for - git-log (color.diff) - git-status (color.status) - git-diff (color.diff) - pager (color.pager) I haven't removed the old config options; but they should probably be deprecated and eventually removed to prevent future namespace collisions. I've done this deprecation by changing the documentation for the config file to match the new names; and adding the "color.XXX" options to contrib/completion/git-completion.bash. Unfortunately git-svn reads "diff.color" and "pager.color"; which I don't like to change unilaterally. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-04make 'git add' a first class user friendly interface to the indexLibravatar Nicolas Pitre1-1/+1
This brings the power of the index up front using a proper mental model without talking about the index at all. See for example how all the technical discussion has been evacuated from the git-add man page. Any content to be committed must be added together. Whether that content comes from new files or modified files doesn't matter. You just need to "add" it, either with git-add, or by providing git-commit with -a (for already known files only of course). No need for a separate command to distinguish new vs modified files please. That would only screw the mental model everybody should have when using GIT. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-08git-status: quote LF in its outputLibravatar Junio C Hamano1-11/+53
Otherwise, commit log template would get the remainder of the filename start on a new line unquoted and the log gets messed up. I initially considered using the full quote_c_style(), but the output from the command is primarily for human consumption so chose to leave other control characters and bytes with high-bits unmolested. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-07Merge branch 'maint'Libravatar Junio C Hamano1-2/+0
* maint: remove an unneeded test
2006-11-07remove an unneeded testLibravatar Tero Roponen1-2/+0
In wt-status.c there is a test which does nothing. This patch removes it. Signed-off-by: Tero Roponen <teanropo@jyu.fi> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-06Merge branch 'maint'Libravatar Junio C Hamano1-8/+3
* maint: Documentation: Transplanting branch with git-rebase --onto merge-recursive implicitely depends on trust_executable_bit adjust_shared_perm: chmod() only when needed. Fix git-runstatus for repositories containing a file named HEAD
2006-11-05Fix git-runstatus for repositories containing a file named HEADLibravatar Jeff King1-8/+3
The wt_status_print_updated() and wt_status_print_untracked() routines call setup_revisions() with 'HEAD' being the reference to the tip of the current branch. However, setup_revisions() gets confused if the branch also contains a file named 'HEAD' resulting in a fatal error. Instead, don't pass an argv to setup_revisions() at all; simply give it no arguments, and make 'HEAD' the default revision. Bug noticed by Rocco Rutte <pdmef@gmx.net>. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-01Merge branch 'lj/refs'Libravatar Junio C Hamano1-4/+2
* lj/refs: (63 commits) Fix show-ref usagestring t3200: git-branch testsuite update sha1_name.c: avoid compilation warnings. Make git-branch a builtin ref-log: fix D/F conflict coming from deleted refs. git-revert with conflicts to behave as git-merge with conflicts core.logallrefupdates thinko-fix git-pack-refs --all core.logallrefupdates create new log file only for branch heads. Remove bashism from t3210-pack-refs.sh ref-log: allow ref@{count} syntax. pack-refs: call fflush before fsync. pack-refs: use lockfile as everybody else does. git-fetch: do not look into $GIT_DIR/refs to see if a tag exists. lock_ref_sha1_basic does not remove empty directories on BSD Do not create tag leading directories since git update-ref does it. Check that a tag exists using show-ref instead of looking for the ref file. Use git-update-ref to delete a tag instead of rm()ing the ref file. Fix refs.c;:repack_without_ref() clean-up path Clean up "git-branch.sh" and add remove recursive dir test cases. ...
2006-10-26Make filenames line up in git-status outputLibravatar Andy Parkins1-7/+7
When all the filenames line up it's much easier to copy and paste them somewhere else, or to remove the "modified:", "copied:", etc prefix. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20Tell between packed, unpacked and symbolic refs.Libravatar Junio C Hamano1-1/+1
This adds a "int *flag" parameter to resolve_ref() and makes for_each_ref() family to call callback function with an extra "int flag" parameter. They are used to give two bits of information (REF_ISSYMREF and REF_ISPACKED) about the ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17wt-status: use simplified resolve_ref to find current branchLibravatar Jeff King1-4/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-13wt-status: remove extraneous newline from 'deleted:' outputLibravatar Jeff King1-1/+1
This was accidentally introduced during the fixes to avoid putting newlines inside of colorized output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-12Teach runstatus about --untrackedLibravatar Johannes Schindelin1-0/+5
Actually, teach runstatus what to do if it is not passed; it should not list the contents of completely untracked directories, but only the name of that directory (plus a trailing '/'). [jc: with comments by Jeff King to match hide-empty-directories behaviour of the original.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-08git-commit.sh: convert run_status to a C builtinLibravatar Jeff King1-0/+271
This creates a new git-runstatus which should do roughly the same thing as the run_status function from git-commit.sh. Except for color support, the main focus has been to keep the output identical, so that it can be verified as correct and then used as a C platform for other improvements to the status printing code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>