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>
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>
* 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
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>
Since 98bf8a47c2 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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
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>
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>
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>
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>
* 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
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>
* 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.
...
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>
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>
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>
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>
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>
Junio C Hamano
Mark Wooding
Nicolas Pitre
Jürgen Rühle
Andy Parkins
Shawn O. Pearce
Tero Roponen
Jeff King
Johannes Schindelin