The primary thing Linus's patch wanted to change was to make sure
that 0-line change appears for a mode-only change. Update the
first test to chmod a file that we can see in the output (limited
by --stat-count) to demonstrate it. Also make sure to use test_chmod
and compare the index and the tree, so that we can run this test
even on a filesystem without permission bits.
Later two tests are about fixes to separate issues that were
introduced and/or uncovered by Linus's patch as a side effect, but
the issues are not related to mode-only changes. Remove chmod from
the tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise the user might get something like:
git-completion.sh:2466: command not found: compdef
If this script is loaded before compinit. The script would work either
way, but let's not be more annoying to the user.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Having a ".git" entry inside a tree can cause confusing
results on checkout. At the top-level, you could not
checkout such a tree, as it would complain about overwriting
the real ".git" directory. In a subdirectory, you might
check it out, but performing operations in the subdirectory
would confusingly consider the in-tree ".git" directory as
the repository.
The regular git tools already make it hard to accidentally
add such an entry to a tree, and do not allow such entries
to enter the index at all. Teaching fsck about it provides
an additional safety check, and let's us avoid propagating
any such bogosity when transfer.fsckObjects is on.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We allow send-email to use an implicitly-defined identity
for the sender (because there is still a confirmation step),
but we abort when we cannot generate such an identity. Let's
make sure that we test this.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
* pw/maint-p4-rcs-expansion-newline:
git p4: RCS expansion should not span newlines
We do not currently have any explicit tests for "git var" at
all (though we do exercise it to some degree as a part of
other tests). Let's add a few basic sanity checks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A tree with meta-paths like '.' or '..' does not work well
with git; the index will refuse to load it or check it out
to the filesystem (and even if we did not have that safety,
it would look like we were overwriting an untracked
directory). For the same reason, it is difficult to create
such a tree with regular git.
Let's warn about these dubious entries during fsck, just in
case somebody has created a bogus tree (and this also lets
us prevent them from propagating when transfer.fsckObjects
is set).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Strictly speaking bzr doesn't need any changes to interact with remote
repositories, but it's dead slow.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The context of the example to push into refs/remotes/satellite/
hierarchy of the other repository needs to be spelled out explicitly
for the value of this example to be fully appreciated. Make it so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configure script checks whether certain flags are required to use
pthreads. But it did not consider that *none* might be needed (as is the
case on Mac OS X). This lead to configure adding "-mt" to the list of
flags (which does nothing on OS X except producing a warning). This in
turn triggered a compiler warning on every single file.
To solve this, we now first check if pthreads work without extra flags.
This means the check is now order dependant, hence a comment is added
explaining this, and the reasons for it.
Note that it might be possible to write an order independent test, but
it does not seem worth the extra effort required for implementing and
testing such a solution, when this simple solution exists and works.
Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As Amit Bakshi reported, older versions of python (< 2.7) don't have
subprocess.check_output, so let's use subprocess.Popen directly as
suggested.
Suggested-by: Amit Bakshi <ambakshi@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jh/update-ref-d-through-symref:
Fix failure to delete a packed ref through a symref
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
Even though we show a separate *UNMERGED* entry in the patch and
diffstat output (or in the --raw format, for that matter) in
addition to and separately from the diff against the specified stage
(defaulting to #2) for unmerged paths, they should not be counted in
the total number of files affected---that would lead to counting the
same path twice.
The separation done by the previous step makes this fix simple and
straightforward. Among the filepairs in diff_queue, paths that
weren't modified, and the extra "unmerged" entries do not count as
total number of files.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diffstat generation logic, with --stat-count limit, is
implemented as three loops.
- The first counts the width necessary to show stats up to
specified number of entries, and notes up to how many entries in
the data we need to iterate to show the graph;
- The second iterates that many times to draw the graph, adjusts
the number of "total modified files", and counts the total
added/deleted lines for the part that was shown in the graph;
- The third iterates over the remainder and only does the part to
count "total added/deleted lines" and to adjust "total modified
files" without drawing anything.
Move the logic to count added/deleted lines and modified files from
the second loop to the third loop.
This incidentally fixes a bug. The third loop was not filtering
binary changes (counted in bytes) from the total added/deleted as it
should. The second loop implemented this correctly, so if a binary
change appeared earlier than the --stat-count cutoff, the code
counted number of added/deleted lines correctly, but if it appeared
beyond the cutoff, the number of lines would have mixed with the
byte count in the buggy third loop.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few problems in diff.c around --stat area, partially
caused by the recent 74faaa1 (Fix "git diff --stat" for interesting
- but empty - file changes, 2012-10-17), and largely caused by the
earlier change that introduced when --stat-count was added.
Add a few test pieces to t4049 to expose the issues.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tcsh users sometimes alias the 'git' command to another name. In
this case, the user expects to only have to issue a new 'complete'
command using the alias name.
However, the tcsh script currently uses the command typed by the
user to call the appropriate function in git-completion.bash, either
_git() or _gitk(). When using an alias, this technique no longer
works.
This change specifies the real name of the command (either 'git' or
'gitk') as a parameter to the script handling tcsh completion. This
allows the user to use any alias for the 'git' or 'gitk' commands,
while still getting completion to work.
A check for the presence of ${HOME}/.git-completion.bash is also
added to help the user make use of the script properly.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current version contains the sentence:
Further suppose that the other person already pushed changes leading to
A back to the original repository you two obtained the original commit
X.
which doesn't parse for me; I've changed it to
Further suppose that the other person already pushed changes leading to
A back to the original repository from which you two obtained the
original commit X.
Signed-off-by: Mark Szepieniec <mszepien@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some cases the user may want to send email with "Cc:" line with
email address we cannot extract. Now we allow user to extract
such email address for us.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to warn about invalid emails and just drop them. Such warnings
can be unnoticed by user or noticed after sending email when we are not
giving the "final sanity check [Y/n]?"
Now we quit by default.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some addresses are passed twice to unique_email_list() and invalid addresses
may be reported twice per send_message. Now we warn about them earlier
and we also remove invalid addresses.
This also removes using of undefined values for string comparison
for invalid addresses in cc list processing.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This document contains no new policies or proposals; it attempts to
document established practices and interface requirements.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, read_message() didn't distinguish between an error and eof
when reading its input. This could have resulted in incorrect
behavior if there was an error: (1) reporting "nothing to send" if no
bytes were read or (2) sending an incomplete message if some bytes
were read before the error.
Change read_message() to return -1 on ferror()s and 0 on success, so
that the caller can recognize that an error occurred. (The return
value used to be the length of the input read, which was redundant
because that is already available as the strbuf length.
Change the caller to report errors correctly.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
all_msgs is only used as a glorified string, therefore there is no
reason to declare it as a struct msg_data.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Through the rest of the file, the data member of struct msg_data is
kept NUL-terminated, and that fact is relied upon in a couple of
places. Change lf_to_crlf() to preserve this invariant.
In fact, there are no execution paths in which lf_to_crlf() is called
and then its data member is required to be NUL-terminated, but it is
better to be consistent to prevent future confusion.
Document the invariant in the struct msg_data definition.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Substantially the same code is present in http-push.c and imap-send.c,
so make a library function out of it.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
