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>
These will be used for generating the cover letter in addition to the
patch emails.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tests -o, and an excessively long subject, and --thread, with and
without --in-reply-to=
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also changes it such that:
$ git checkout
will give the same information without changing branches. This is good
for finding out if the fetch you did recently had anything to say
about the branch you've been on, whose name you don't remember at the
moment.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using 'git rev-parse --git-dir' makes the code shorter and more future-
proof.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mk/maint-parse-careful:
peel_onion: handle NULL
check return value from parse_commit() in various functions
parse_commit: don't fail, if object is NULL
revision.c: handle tag->tagged == NULL
reachable.c::process_tree/blob: check for NULL
process_tag: handle tag->tagged == NULL
check results of parse_commit in merge_bases
list-objects.c::process_tree/blob: check for NULL
reachable.c::add_one_tree: handle NULL from lookup_tree
mark_blob/tree_uninteresting: check for NULL
get_sha1_oneline: check return value of parse_object
read_object_with_reference: don't read beyond the buffer
Some codepaths (eg. builtin-rev-parse -> get_merge_bases -> parse_commit)
can pass NULL.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As these functions are directly called with the result
from lookup_tree/blob, they must handle NULL.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As these functions are directly called with the result
from lookup_tree/blob, they must handle NULL.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As these functions are directly called with the result
from lookup_tree/blob, they must handle NULL.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not terminating the options[] array with OPT_END can cause
usage ("git checkout -h") output to segfault.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This moves low-level merge functions out of merge-recursive.c and
places them in a new separate file, ll-merge.c
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a merge conflicts, there are often common lines that are not really
common, such as empty lines or lines containing a single curly bracket.
With XDL_MERGE_ZEALOUS_ALNUM, we use the following heuristics: when a
hunk does not contain any letters or digits, it is treated as conflicting.
In other words, a conflict which used to look like this:
<<<<<<<
a = 1;
=======
output();
>>>>>>>
}
}
}
<<<<<<<
output();
=======
b = 1;
>>>>>>>
will look like this with ZEALOUS_ALNUM:
<<<<<<<
a = 1;
}
}
}
output();
=======
output();
}
}
}
b = 1;
>>>>>>>
To demonstrate this, git-merge-file has been switched from
XDL_MERGE_ZEALOUS to XDL_MERGE_ZEALOUS_ALNUM.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a merge conflicts, there are often less than three common lines
between two conflicting regions.
Since a conflict takes up as many lines as are conflicting, plus three
lines for the commit markers, the output will be shorter (and thus,
simpler) in this case, if the common lines will be merged into the
conflicting regions.
This patch merges up to three common lines into the conflicts.
For example, what looked like this before this patch:
<<<<<<<
if (a == 1)
=======
if (a != 0)
>>>>>>>
{
int i;
<<<<<<<
a = 0;
=======
a = !a;
>>>>>>>
will now look like this:
<<<<<<<
if (a == 1)
{
int i;
a = 0;
=======
if (a != 0)
{
int i;
a = !a;
>>>>>>>
Suggested Linus (based on ideas by "Voltage Spike" -- if that name is
real, it is mighty cool).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A failure in prepare_revision_walk can be caused by
a not parseable object.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for new option -nohtml to quot_cec and quot_upr
subroutines, to have output not wrapped in HTML tags. This makes
those subroutines suitable to quoting attributes values, and for plain
text output quoting. Currently this API is not used yet.
While at it fix whitespace, and use ';' as delimiter, not separator.
The option to not wrap quot_cec output in HTML tag were proposed
originally in patch:
"Don't open a XML tag while another one is already open"
Message-ID: <20080216191628.GK30676@schiele.dyndns.org>
by Robert Schiele. Originally the parameter was named '-notag', was
also supportted by esc_html (but not esc_path) which passed it down to
quot_cec. Mentioned patch was meant to fix the bug Martin Koegler
reported in his mail
"Invalid html output repo.or.cz (alt-git.git)"
Message-ID: <20080216130037.GA14571@auto.tuwien.ac.at>
which was fixed in different way (do not use esc_html to escape and
quote HTML attributes).
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not use esc_html to escape [title] _attribute_ of a HTML element,
and quote unprintable characters. Replace unprintable characters by
'?' and use CGI method to generate HTML element and do the escaping.
This caused bug noticed by Martin Koegler,
Message-ID: <20080216130037.GA14571@auto.tuwien.ac.at>
that for bad commit encoding in author name, the title attribute (here
to show full, not shortened name) had embedded HTML code in it, result
of quoting unprintable characters the gitweb/HTML way. This of course
broke the HTML, causing page being not displayed in XML validating web
browsers.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When deciding if gitk or git-log should be used to visualize the current
state, the environment variable DISPLAY was checked. Now, we check
MSYSTEM (for MinGW32/MSys) and SECURITYSESSIONID (for MacOSX) in addition.
Note that there is currently no way to ssh into MinGW32, and that
SECURITYSESSIONID is not set automatically on MacOSX when ssh'ing into it.
So this patch should be safe.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you do this (and you are not an Emacs user who uses PAGER=cat
in your *shell* buffer):
$ git init
Initialized empty Git repository in .git/
$ echo hello world >foo
$ H=$(git hash-object -w foo)
$ git tag -a foo-tag -m "Tags $H" $H
$ echo $H
3b18e512dba79e4c8300dd08aeb37f8e728b8dad
$ rm -f .git/objects/3b/18e5*
$ git show foo-tag
tag foo-tag
Tagger: Junio C Hamano <gitster@pobox.com>
Date: Sat Feb 16 10:43:23 2008 -0800
Tags 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
you do not get any indication of error. If you are careful, you
would notice that no contents from the tagged object is
displayed, but that is about it. If you run the "show" command
without pager, however, you will see the error:
$ git --no-pager show foo-tag
tag foo-tag
Tagger: Junio C Hamano <gitster@pobox.com>
Date: Sat Feb 16 10:43:23 2008 -0800
Tags 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
error: Could not read object 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
Because we spawn the pager as the foreground process and feed
its input via pipe from the real command, we cannot affect the
exit status the shell sees from git command when the pager is in
use (I think there is not much gain we can have by working it
around, though). But at least it may make sense to show the
error message to the user sitting in front of the pager.
[jc: Edgar Toernig suggested a much nicer implementation than
what I originally posted, which I took.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
And markup one missing string for translation.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* cc/browser:
Documentation: add 'git-web--browse.txt' and simplify other docs.
git-web--browse: fix misplaced quote in init_browser_path()
web--browse: Add a few quotes in 'init_browser_path'.
Documentation: instaweb: add 'git-web--browse' information.
Adjust .gitignore for 5884f1(Rename 'git-help--browse.sh'...)
git-web--browse: do not start the browser with nohup
instaweb: use 'git-web--browse' to launch browser.
Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
help--browse: add '--config' option to check a config option for a browser.
help: make 'git-help--browse' usable outside 'git-help'.
Conflicts:
git-web--browse.sh
* pb/prepare-commit-msg:
git-commit: add a prepare-commit-msg hook
git-commit: Refactor creation of log message.
git-commit: set GIT_EDITOR=: if editor will not be launched
git-commit: support variable number of hook arguments
