The output was meant to be a balance of self-explanatory and
terse. In case we have erred too far on the terse side, it
doesn't hurt to explain in more detail what each line means.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous text was correct, but it was easy to miss the
fact that we are talking about "matching" refs. That is, the
text can be parsed as "we push the union of the sets
of remote and local heads" and not "we push the intersection
of the sets of remote and local heads". (The former actually
doesn't make sense if you think about it, since we don't
even _have_ some of those heads). A careful reading would
reveal the correct meaning, but it makes sense to be as
explicit as possible in documentation.
We also explicitly use and introduce the term "matching";
this is a term discussed on the list, and it seems useful
to for users to be able to refer to this behavior by name.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing message indicates that an error occured during
push, but it is unclear whether _any_ refs were actually
pushed (even though the status table above shows which were
pushed successfully and which were not, the message "failed
to push" implies a total failure). By indicating that "some
refs" failed, we hopefully indicate to the user that the
table above contains the details.
We could also put in an explicit "see above for details"
message, but it seemed to clutter the output quite a bit
(both on a line of its own, or at the end of the error line,
which inevitably wraps).
This could also be made more fancy if the transport
mechanism passed back more details on how many refs
succeeded and failed:
error: failed to push %d out of %d refs to '%s'
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git gui" would complain at launch if the local version of Git was
"1.5.4.2.dirty". Loosen the regular expression to look for either
"-dirty" or ".dirty", thus eliminating spurious warnings.
Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Documentation/git-reset: don't mention --mixed for selected-paths reset
The option is accepted, but that is the only form selected-paths
variant of the reset command takes, so there is no point mentioning it.
And while we're at it, use the dashless git call.
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 3368d11 (Remove unnecessary git-rm --cached reference from
status output), the status output marks the "Added but not yet
committed" section as "Changes to be committed".
commit: discard index after setting up partial commit
There may still be some entries from the original index that
should be discarded before we show the status. In
particular, if a file was added in the index but not
included in the partial commit, it would still show up in
the status listing as staged for commit.
Ultimately the correct fix is to keep the two states in
separate index_state variables. Then we can avoid having
to reload the cache from the temporary file altogether, and
just point wt_status_print at the correct index.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command used a very old fashioned construct to extract
filenames out of diff-index and ended up corrupting the output.
We can simply use --name-only and pipe into --stdin mode of
update-index. It's been like that for the past 2 years or so
since a94d994 (update-index: work with c-quoted name).
Before objects are sent, the respective ref is locked. However,
without this patch, the lock is lifted before the last object for
that ref was sent. As a consequence, the lock data was accessed
after the lock structure was free()d.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
c1795bb (Unify whitespace checking) incorrectly made the
checking function return without incrementing the line numbers
when there is no whitespace problem is found on a '+' line.
This resurrects the earlier behaviour.
Noticed and reported by Jay Soffian. The test script was stolen
from Jay's independent fix.
Fix a bug in the hg-to-git convertor introduced by commit 1bc7c13af9f936aa80893100120b542338a10bf4: when searching the changeset
parents, 'hg log' returns an extra space at the end of the line, which
confuses the .split(' ') based tokenizer:
Traceback (most recent call last):
File "hg-to-git.py", line 123, in <module>
hgchildren[mparent] += ( str(cset), )
KeyError: ''
Signed-off-by: Stelian Pop <stelian@popies.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
mailinfo: feed only one line to handle_filter() for QP input
The function is intended to be fed one logical line at a time to
inspect, but a QP encoded raw input line can have more than one
lines, just like BASE64 encoded one.
Quoting LF as =0A may be unusual but RFC2045 allows it.
The issue was noticed and fixed by Jay Soffian. JC added a test
to protect the fix from regressing later.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
config: add 'git_config_string' to refactor string config variables.
In many places we just check if a value from the config file is not
NULL, then we duplicate it and return 0. This patch introduces the new
'git_config_string' function to do that.
This function is also used to refactor some code in 'config.c'.
Refactoring other files is left for other patches.
Also not all the code in "config.c" is refactored, because the function
takes a "const char **" as its first parameter, but in many places a
"char *" is used instead of a "const char *". (And C does not allow
using a "char **" instead of a "const char **" without a warning.)
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is not necessary to check if value != NULL before calling
'parse_lldiff_command' as there is already a check inside this
function.
By the way this patch also improves the existing check inside
'parse_lldiff_command' by using:
return config_error_nonbool(var);
instead of:
return error("%s: lacks value", var);
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-import: check return value from unpack_entry()
If the tree object we have asked for is deltafied in the packfile and
the delta did not apply correctly or was not able to be decompressed
from the packfile then we can get back NULL instead of the tree data.
This is (part of) the reason why read_sha1_file() can return NULL, so
we need to also handle it the same way.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Validate nicknames of remote branches to prohibit confusing ones
The original problem was that the parsers for configuration files were
getting confused by seeing as nicknames remotes that involved
directory-changing characters. In particular, the branches config file
for ".." was particularly mystifying on platforms that can open
directories and read odd data from them.
The validation function was written by Junio Hamano (with a typo
corrected).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff.c: fixup garding of config parser from value=NULL
Christian Couder noticed that there still were a handcrafted error()
call that we should have converted to config_error_nonbool() where
parse_lldiff_command() parses the configuration file.
cvsimport: have default merge regex also match beginning of commit message
The default value of @mergerx uses \W, which matches a non-word
character; this means that commit messages like "Merging FOO" are not
matched by default; using \b, which matches a word boundary, instead of
\W fixes that.
This change was suggested by Frédéric Brière through
http://bugs.debian.org/463468
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
status: suggest "git rm --cached" to unstage for initial commit
It makes no sense to suggest "git reset HEAD" since we have
no HEAD commit. This actually used to work but regressed in f26a0012.
wt_status_print_cached_header was updated to take the whole
wt_status struct rather than just the reference field.
Previously the various code paths were sometimes sending in
s->reference and sometimes sending in NULL, making the
decision on whether this was an initial commit before we
even got to this function. Now we must check the initial
flag here.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Protect get_author_ident_from_commit() from filenames in work tree
We used to use "cat-file commit $commit" to extract the original
author information from existing commit, but an earlier commit 5ac2715 (Consistent message encoding while reusing log from an
existing commit) changed it to use "git show -s $commit". If
you have a file in your work tree that can be interpreted as a
valid object name (e.g. "HEAD"), this conversion will not work.
Disambiguate by marking the end of revision parameter on the
comand line with an explicit "--" to fix this.
This breakage is most visible with rebase when a file called
"HEAD" exists in the worktree.
Since git-upload-pack has to spawn git-pack-objects, it has to make sure
that the latter can be found in the PATH. Without this patch an attempt
to clone or pull via ssh from a server fails if the git tools are not in
the standard PATH on the server even though git clone or git pull were
invoked with --upload-pack=/path/to/git-upload-pack.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: use verbatim commit subject in the bisect log
Due to a typo, the commit subject was shell expanded in the bisect log.
That is, if you had some shell pattern in the commit subject, bisect
would happily put all matching file names into the log.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nico analyzed and found out that this does not really help, and
I agree with it.
By the time this gets into action and data is actively thrown
away, performance simply goes down the drain due to the data
constantly being reloaded over and over and over and over and
over and over again, to the point of virtually making no
relative progress at all. The previous behavior of enforcing
the memory limit by dynamically shrinking the window size at
least had the effect of allowing some kind of progress, even if
the end result wouldn't be optimal.
And that's the whole point behind this memory limiting feature:
allowing some progress to be made when resources are too limited
to let the repack go unbounded.
This is used to report misconfigured configuration file that does not
give any value to a non-boolean variable, e.g.
[section]
var
It is perfectly fine to say it if the section.var is a boolean (it means
true), but if a variable expects a string value it should be flagged as
a configuration error.
Work around curl-gnutls not liking to be reinitialized
curl versions 7.16.3 to 7.18.0 included had a regression in which https
requests following curl_global_cleanup/init sequence would fail with ASN1
parser errors with curl-gnutls. Such sequences happen in some cases such
as git fetch.
We work around this by removing the http_init and http_cleanup calls from
get_refs_via_curl, replacing them with a transport->data initialization
with the http_walker (which does http_init).
While the http_walker is not currently used in get_refs_via_curl, http
and walker code refactor will make it use it.
Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72? There are known problems building the
> > manpages with that version. 1.71 works, and 1.73 should work when it get
> > released.
I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.
builtin-commit: remove .git/SQUASH_MSG upon successful commit
After doing a merge --squash, and commit afterwards, the commit message
template SQUASH_MSG in the git directory is not removed, which means that
the content of SQUASH_MSG is used as default commit message for all
subsequent commits. So have git commit remove the file SQUASH_MSG from
the git directory upon a successful commit.
The problem was discovered by Frédéric Brière, reported through
http://bugs.debian.org/464656
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make git prune remove temporary packs that look like write failures
Write errors when repacking (eg, due to out-of-space conditions)
can leave temporary packs (and possibly other files beginning
with "tmp_") lying around which no existing
codepath removes and which aren't obvious to the casual user.
These can also be multi-megabyte files wasting noticeable space.
Unfortunately there's no way to definitely tell in builtin-prune
that a tmp_ file is not being used by a concurrent process,
such as a fetch. However, it is documented that pruning should
only be done on a quiet repository and --expire is honoured
(using code from Johannes Schindelin, along with a test case
he wrote) so that its safety is the same as that of loose
object pruning.
Since they might be signs of a problem (unlike orphaned loose
objects) the names of any removed files are printed.
Signed-off-by: David Tweed (david.tweed@gmail.com) Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document that the default of branch.autosetupmerge is true
In 34a3e69 (git-branch: default to --track) the default was changed to
true, to help new git users. But yours truly forgot to update the
documentation. This fixes it.
Noticed by Kalle Olavi Niemitalo.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_beginning_of_line didn't take into account that the
previous line might have ended with \ in which case it shouldn't
stop but continue its search.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was an embarrassing pair of off-by-one miscounting that
failed to match path "a/b/c" when "a/.gitattributes" tried to
name it with relative path "b/c".
The scripted version might not have handled this correctly
either, but the version rewritten in C definitely does not grok
this and complains $tag is not a commit object.
Because ':/substring' extended SHA1 expression cannot take
postfix modifiers such as ^{tree} and ^{commit}, we would need
to do it in multiple steps. With the patch, you can start a new
branch from a randomly-picked commit whose message has the named
string in it.
Revert "filter-branch docs: remove brackets so not to imply revision arg is optional"
This reverts commit c41b439244c51b30c60953192816afc91e552578, as
we decided to default to HEAD when revision parameters are missing
and they are no longer mandatory.
filter-branch: assume HEAD if no revision supplied
filter-branch previously took the first non-option argument as the name for
a new branch. Since dfd05e38, it now takes a revision or a revision range
and modifies the current branch. Update to operate on HEAD by default to
conform with standard git interface practice.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We only care about getting what should be an empty string and
sending it to a file, without a trailing LF, so the empty string
translates into a 0 byte file. Earlier when I originally wrote
these lines Mac OS X allowed the format string of printf to be
the empty string, but more recent versions appear to have been
'improved' with error messages if the format is not given.
This may cause problems if we ever wind up with changes to the hook
tests. A minor cleanup makes the test more safe on all systems,
by conforming to accepted printf conventions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
filter-branch.sh: remove temporary directory on failure
One of the first things filter-branch does is to create a temporary
directory. This directory is eventually removed by the script during
normal operation, but is not removed if the script encounters an error.
Set a trap to remove it when the script terminates for any reason.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-relink: avoid hard linking in objects/info directory
git-relink is intended to search for packs and loose objects in
common between two repositories and to replace the one set with
hard links to the other. Files other than packs and loose objects
should not be touched, so add the "info" sub-directory to the
pattern of directory excludes.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Add info about $projectroot and $projects_list to gitweb/README
Those two configuration variables are important enough that it is
worth to explicitely write about them in the "Gitweb config file
variables" section even if they are usually set during build by
GITWEB_PROJECTROOT and GITWEB_LIST build (Makefile) configuration
variables.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reflog-expire: Avoid creating new files in a directory inside readdir(3) loop
"git reflog expire --all" opened a directory in $GIT_DIR/logs/,
read reflog files in there readdir(3), and rewrote the file by
creating a new file and renaming it back inside the loop. This
code structure can cause the newly created file to be returned
by subsequent call to readdir(3), and fall into an infinite loop
in the worst case.
This separates the processing to two phase. Running
for_each_reflog() to find out and collect all refs, and then
iterate over them, calling expire_reflog(). This way, the
program would behave exactly the same way as if all the refs
were given by the user from the command line.
gitweb: Convert generated contents to utf8 in commitdiff_plain
If the commit message, or commit author contains non-ascii, it must be
converted from Perl internal representation to utf-8, to follow what
got declared in HTTP header. Use to_utf8() to do the conversion.
This necessarily replaces here-doc with "print" statements.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Acked-by: İsmail Dönmez <ismail@pardus.org.tr> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
instaweb: use 'browser.<tool>.path' config option if it's set.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add test for rebase -i with commits that do not pass pre-commit
This accompanies c5b09feb786f6a2456ec3d8203d0f4d67f09f043 (Avoid
update hook during git-rebase --interactive) to make sure that
any regression to make Debian's Bug#458782 (git-core: git-rebase
doesn't work when trying to squash changes into commits created
with --no-verify) resurface will be caught.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>