* Re: Bug: commit -p breaks with -m
2013-08-15 4:43 5% Bug: commit -p breaks with -m Matan Nassau
@ 2013-08-15 12:16 0% ` Jeff King
0 siblings, 0 replies; 9+ results
From: Jeff King @ 2013-08-15 12:16 UTC (permalink / raw)
To: Matan Nassau; +Cc: git@vger.kernel.org
On Thu, Aug 15, 2013 at 12:43:39AM -0400, Matan Nassau wrote:
> With git 1.8.3.3,
>
> $ seq 5 >data
> $ git add data
> $ git commit -mdata
> $ sed -i '2 d' data
> $ git commit -pmchange
>
> At the prompt, type e to edit the hunk. The editor doesn't start, but
> git records a commit.
>
> I found that builtin/commit.c sets the GIT_EDITOR env var to ":" when
> the user specifies the -m option. This was done in 406400ce4f69.
> Removing these two lines,
>
> if (!use_editor)
> setenv("GIT_EDITOR", ":", 1);
>
> seems to fix the issue, but I'm not sure this won't break the
> prepare-commit-msg hook. I'd like to submit a patch: can I get a hint
> if this change would break commit hooks or anything else I'm not
> seeing?
Yeah, that is definitely a bug. Just removing those lines would not be the
right fix, though, because the point of them is to let the
prepare-commit-msg hook know whether or not an editor is in use.
Instead, I think you would want to limit the scope of where we have set
GIT_EDITOR. I.e., drop those lines, and then add GIT_EDITOR=: to the
environment that we pass to the hook via the run_hook function.
Unfortunately, I think that will require some refactoring of the
run_hook interface, which does not allow arbitrary environment
parameters to be set.
-Peff
^ permalink raw reply [relevance 0%]
* Bug: commit -p breaks with -m
@ 2013-08-15 4:43 5% Matan Nassau
2013-08-15 12:16 0% ` Jeff King
0 siblings, 1 reply; 9+ results
From: Matan Nassau @ 2013-08-15 4:43 UTC (permalink / raw)
To: git@vger.kernel.org
With git 1.8.3.3,
$ seq 5 >data
$ git add data
$ git commit -mdata
$ sed -i '2 d' data
$ git commit -pmchange
At the prompt, type e to edit the hunk. The editor doesn't start, but git records a commit.
I found that builtin/commit.c sets the GIT_EDITOR env var to ":" when the user specifies the -m option. This was done in 406400ce4f69. Removing these two lines,
if (!use_editor)
setenv("GIT_EDITOR", ":", 1);
seems to fix the issue, but I'm not sure this won't break the prepare-commit-msg hook. I'd like to submit a patch: can I get a hint if this change would break commit hooks or anything else I'm not seeing?
^ permalink raw reply [relevance 5%]
* Re: Fwd: Bug: SEGV in git when applying the patches
2013-08-05 11:09 5% ` John Keeping
@ 2013-08-05 11:10 0% ` Rafal W.
0 siblings, 0 replies; 9+ results
From: Rafal W. @ 2013-08-05 11:10 UTC (permalink / raw)
To: John Keeping; +Cc: git@vger.kernel.org
Thank you, I'll test with the newer version.
---
kenorb
On 5 August 2013 12:09, John Keeping <john@keeping.me.uk> wrote:
> On Mon, Aug 05, 2013 at 12:01:44PM +0100, Rafal W. wrote:
>> Hi,
>> When applying patch via git, it is doing sometimes SEGV.
>> Please find more details in the attached crash logs.
>
> This looks like the issue fixed by commit 212eb96 (apply: carefully
> strdup a possibly-NULL name, 2013-06-21), which is in Git 1.8.3.3 and
> later.
^ permalink raw reply [relevance 0%]
* Re: Fwd: Bug: SEGV in git when applying the patches
@ 2013-08-05 11:09 5% ` John Keeping
2013-08-05 11:10 0% ` Rafal W.
0 siblings, 1 reply; 9+ results
From: John Keeping @ 2013-08-05 11:09 UTC (permalink / raw)
To: Rafal W.; +Cc: git@vger.kernel.org
On Mon, Aug 05, 2013 at 12:01:44PM +0100, Rafal W. wrote:
> Hi,
> When applying patch via git, it is doing sometimes SEGV.
> Please find more details in the attached crash logs.
This looks like the issue fixed by commit 212eb96 (apply: carefully
strdup a possibly-NULL name, 2013-06-21), which is in Git 1.8.3.3 and
later.
^ permalink raw reply [relevance 5%]
* Re: Difficulty adding a symbolic link, part 3
2013-07-31 20:29 3% Difficulty adding a symbolic link, part 3 Dale R. Worley
@ 2013-08-01 1:17 0% ` Duy Nguyen
0 siblings, 0 replies; 9+ results
From: Duy Nguyen @ 2013-08-01 1:17 UTC (permalink / raw)
To: Dale R. Worley; +Cc: Git Mailing List
On Thu, Aug 1, 2013 at 3:29 AM, Dale R. Worley <worley@alum.mit.edu> wrote:
> I've run into a problem (with Git 1.8.3.3) where I cannot add a
> symbolic link (as such) to the repository *if* its path is given
> absolutely; instead Git adds the file the symbolic link points to.
> (If I give the path relatively, Git does what I expect, that is, adds
> the symbolic link.)
>
> I've written a test script that shows the problem and included it
> below.
>
> I would not expect *how* a path is presented to Git to change how Git
> processes the path. In the test case, I would expect "/bin/awk" and
> "../../bin/awk" to produce the same effect when used as arguments to
> "git add".
>
> What is going on in the code is this: In "git add", all paths are
> normalized by the function prefix_path_gently() in abspath.c. That
> function removes symbolic links from the pathspec *only if* it is
> absolute, as shown in the first few lines of the function:
>
> static char *prefix_path_gently(const char *prefix, int len, const char *path)
> {
> const char *orig = path;
> char *sanitized;
> if (is_absolute_path(orig)) {
> - const char *temp = real_path(path);
> + const char *temp = absolute_path(path);
> sanitized = xmalloc(len + strlen(temp) + 1);
> strcpy(sanitized, temp);
> } else {
>
> real_path() is specified to remove symbolic links. As shown, I've
> replaced real_path() with absolute_path(), based on the comment at the
> top of real_path():
>
> /*
> * Return the real path (i.e., absolute path, with symlinks resolved
> * and extra slashes removed) equivalent to the specified path. (If
> * you want an absolute path but don't mind links, use
> * absolute_path().) The return value is a pointer to a static
> * buffer.
> *
>
> If I replace real_path() with absolute_path() as shown, the problem I
> am testing for disappears.
I think it also reverts 18e051a (setup: translate symlinks in filename
when using absolute paths - 2010-12-27). real_path() (or
make_absolute_path() back then) is added to resolve symlinks, at least
ones leading to the work tree, not ones inside the work tree, if I
understand the commit message correctly.
>
> With the above change, the test suite runs with zero failures, so it
> doesn't affect any common Git usage.
It means the test suite is incomplete. As you can see, the commit
introducing this change does not come with a test case to catch people
changing this.
>
> But I don't know enough about the internal architecture of Git to know
> that my change is correct in all cases. I'm almost certain that the
> normalization process for pathspecs should *not* normalize a final
> component that is a symbolic link. But I would expect it would be
> desirable to normalize non-final components that are symbolic links.
> On the other hand, that might not matter.
>
> Can someone give me advice on what this code *should* do?
It does as the function name says: given cwd, a prefix (i.e. a
relative path with no ".." components) and a path relative to
cwd+prefix, convert 'path' to something relative to cwd. In the
simplest case, prepending the prefix to 'path' is enough. cwd is also
get_git_work_tree().
I agree with you that this code should not resolve anything in the
components after 'cwd', after rebasing the path to 'cwd' (not just the
final component). Not sure how to do it correctly though because we do
need to resolve symlinks before cwd. Maybe a new variant of real_path
that stops at 'cwd'?
We may also have problems with resolve symlinks before cwd when 'path'
is relative, as normalize_path_copy() does not resolve symlinks. We
just found out emacs has this bug [1] but did not realize we also have
one :-P.
[1] http://thread.gmane.org/gmane.comp.version-control.git/231268
>
> I believe I can prepare a proper test for the test suite for this, so
> once I know what the code change should be, I can prepare a proper
> patch for it.
>
> Dale
--
Duy
^ permalink raw reply [relevance 0%]
* Re: Making a patch: "git format-patch" does not produce the documented format
2013-07-31 21:31 4% Making a patch: "git format-patch" does not produce the documented format Dale R. Worley
@ 2013-07-31 21:48 0% ` John Keeping
0 siblings, 0 replies; 9+ results
From: John Keeping @ 2013-07-31 21:48 UTC (permalink / raw)
To: Dale R. Worley; +Cc: git
On Wed, Jul 31, 2013 at 05:31:47PM -0400, Dale R. Worley wrote:
> Notice that the whole commit message has been formatted as if it is
> part of the Subject line, and the line breaks in the commit message
> have been refilled.
>
> The file Documentation/SubmittingPatches says that "git format-patch"
> produces patches in the best format, but the manual page shows an
> example more like this:
>
> From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
> From: Tony Luck <tony.luck@intel.com>
> Date: Tue, 13 Jul 2010 11:42:54 -0700
> Subject: [PATCH] Put ia64 config files on the
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> arch/arm config files were slimmed down using a python script
> (See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)
> [...]
>
> That is, the first line of the commit message is in the Subject and
> the remaining lines are in the message body. As far as I can tell,
> that's what SubmittingPatches prescribes. And that is what I see in
> the Git mailing list on vger.
>
> (This is with git 1.8.3.3.)
>
> Exactly how should the commit message be inserted into the patch
> e-mail? What needs to be updated so the code is consistent with the
> documentation?
git-format-patch(1) says:
By default, the subject of a single patch is "[PATCH] " followed
by the concatenation of lines from the commit message up to the
first blank line (see the DISCUSSION section of git-commit(1)).
I think that accurately describes what you're seeing. The referenced
DISCUSSION section describes how to write a commit message that is
formatted in a suitable way, with a short first subject line and then a
blank line before the body of the message.
^ permalink raw reply [relevance 0%]
* Making a patch: "git format-patch" does not produce the documented format
@ 2013-07-31 21:31 4% Dale R. Worley
2013-07-31 21:48 0% ` John Keeping
0 siblings, 1 reply; 9+ results
From: Dale R. Worley @ 2013-07-31 21:31 UTC (permalink / raw)
To: git
I'm working on writing a patch, but I'm running into a problem. The
patch itself is from this commit:
$ git log -1
commit 07a25537909dd277426818a39d9bc4235e755383
Author: Dale Worley <worley@ariadne.com>
Date: Thu Jul 18 18:43:12 2013 -0400
open() returns -1 on failure, and indeed 0 is a possible success value
if the user closed stdin in our process. Fix the test.
$
But the output of "git format-patch" is:
From 07a25537909dd277426818a39d9bc4235e755383 Mon Sep 17 00:00:00 2001
From: Dale Worley <worley@ariadne.com>
Date: Thu, 18 Jul 2013 18:43:12 -0400
Subject: [PATCH] open() returns -1 on failure, and indeed 0 is a possible
success value if the user closed stdin in our process. Fix
the test.
---
t/t0070-fundamental.sh | 7 +++++++
wrapper.c | 2 +-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/t/t0070-fundamental.sh b/t/t0070-fundamental.sh
index 986b2a8..d427f3a 100755
--- a/t/t0070-fundamental.sh
+++ b/t/t0070-fundamental.sh
@@ -25,6 +25,13 @@ test_expect_success POSIXPERM,SANITY 'mktemp to unwritable directory prints file
grep "cannotwrite/test" err
[...]
Notice that the whole commit message has been formatted as if it is
part of the Subject line, and the line breaks in the commit message
have been refilled.
The file Documentation/SubmittingPatches says that "git format-patch"
produces patches in the best format, but the manual page shows an
example more like this:
From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
From: Tony Luck <tony.luck@intel.com>
Date: Tue, 13 Jul 2010 11:42:54 -0700
Subject: [PATCH] Put ia64 config files on the
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
arch/arm config files were slimmed down using a python script
(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)
[...]
That is, the first line of the commit message is in the Subject and
the remaining lines are in the message body. As far as I can tell,
that's what SubmittingPatches prescribes. And that is what I see in
the Git mailing list on vger.
(This is with git 1.8.3.3.)
Exactly how should the commit message be inserted into the patch
e-mail? What needs to be updated so the code is consistent with the
documentation?
Dale
^ permalink raw reply [relevance 4%]
* Difficulty adding a symbolic link, part 3
@ 2013-07-31 20:29 3% Dale R. Worley
2013-08-01 1:17 0% ` Duy Nguyen
0 siblings, 1 reply; 9+ results
From: Dale R. Worley @ 2013-07-31 20:29 UTC (permalink / raw)
To: git
I've run into a problem (with Git 1.8.3.3) where I cannot add a
symbolic link (as such) to the repository *if* its path is given
absolutely; instead Git adds the file the symbolic link points to.
(If I give the path relatively, Git does what I expect, that is, adds
the symbolic link.)
I've written a test script that shows the problem and included it
below.
I would not expect *how* a path is presented to Git to change how Git
processes the path. In the test case, I would expect "/bin/awk" and
"../../bin/awk" to produce the same effect when used as arguments to
"git add".
What is going on in the code is this: In "git add", all paths are
normalized by the function prefix_path_gently() in abspath.c. That
function removes symbolic links from the pathspec *only if* it is
absolute, as shown in the first few lines of the function:
static char *prefix_path_gently(const char *prefix, int len, const char *path)
{
const char *orig = path;
char *sanitized;
if (is_absolute_path(orig)) {
- const char *temp = real_path(path);
+ const char *temp = absolute_path(path);
sanitized = xmalloc(len + strlen(temp) + 1);
strcpy(sanitized, temp);
} else {
real_path() is specified to remove symbolic links. As shown, I've
replaced real_path() with absolute_path(), based on the comment at the
top of real_path():
/*
* Return the real path (i.e., absolute path, with symlinks resolved
* and extra slashes removed) equivalent to the specified path. (If
* you want an absolute path but don't mind links, use
* absolute_path().) The return value is a pointer to a static
* buffer.
*
If I replace real_path() with absolute_path() as shown, the problem I
am testing for disappears.
With the above change, the test suite runs with zero failures, so it
doesn't affect any common Git usage.
But I don't know enough about the internal architecture of Git to know
that my change is correct in all cases. I'm almost certain that the
normalization process for pathspecs should *not* normalize a final
component that is a symbolic link. But I would expect it would be
desirable to normalize non-final components that are symbolic links.
On the other hand, that might not matter.
Can someone give me advice on what this code *should* do?
I believe I can prepare a proper test for the test suite for this, so
once I know what the code change should be, I can prepare a proper
patch for it.
Dale
----------------------------------------------------------------------
Here's a test case for adding a symbolic link. This test exploits the
fact that on my system, /bin/awk is a symbolic link to "gawk". As you
can see, the behavior of Git differs if the link's path is given to
"git add" as an absolute path or a relative path.
Here is the test script:
----------------------------------------------------------------------
#! /bin/bash
# Illustrates a problem with applying "git add" to a symbolic link.
set -x
# To be run from a directory one step below the root directory. E.g.,
# "/tmp".
# On this system, /bin/awk is a symbolic link to "gawk", which
# means /tmp/gawk.
# Show the Git version.
git version
# Make a test directory and cd to it.
DIR=temp.$$
mkdir $DIR
cd $DIR
# Create a Git repository.
git init
# Set the worktree to be /
git config core.worktree /
# Create an empty commit.
git commit --allow-empty -m Empty.
# Add the symbolic link using its absolute name.
ABSOLUTE=/bin/awk
ls -l $ABSOLUTE
git add $ABSOLUTE
# Notice that the target of the link is added, not the link itself.
git status -uno
# Reset the index.
git reset
# Add the symbolic link using its relative name.
# Remember that we are two directory levels below the root directory now.
RELATIVE=../..$ABSOLUTE
ls -l $RELATIVE
git add $RELATIVE
# Notice that now the link itself is added.
git status -uno
----------------------------------------------------------------------
Here is sample output of the script:
----------------------------------------------------------------------
+ git version
git version 1.8.3.3.756.g07a2553.dirty
+ DIR=temp.22366
+ mkdir temp.22366
+ cd temp.22366
+ git init
Initialized empty Git repository in /git-add-link/temp.22366/.git/
+ git config core.worktree /
+ git commit --allow-empty -m Empty.
[master (root-commit) fb232e5] Empty.
+ ABSOLUTE=/bin/awk
+ ls -l /bin/awk
lrwxrwxrwx. 1 root root 4 Nov 2 2012 /bin/awk -> gawk
+ git add /bin/awk
+ git status -uno
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: ../../bin/gawk
#
# Untracked files not listed (use -u option to show untracked files)
+ git reset
+ RELATIVE=../../bin/awk
+ ls -l ../../bin/awk
lrwxrwxrwx. 1 root root 4 Nov 2 2012 ../../bin/awk -> gawk
+ git add ../../bin/awk
+ git status -uno
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: ../../bin/awk
#
# Untracked files not listed (use -u option to show untracked files)
----------------------------------------------------------------------
Dale
^ permalink raw reply [relevance 3%]
* [ANNOUNCE] Git v1.8.3.3
@ 2013-07-15 21:13 7% Junio C Hamano
0 siblings, 0 replies; 9+ results
From: Junio C Hamano @ 2013-07-15 21:13 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.3.3 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
417cb12660446702bffc5c2c83cbb6e7f1e60c79 git-1.8.3.3.tar.gz
c6104064c1276b2405a281e104fc54ff86f7299d git-htmldocs-1.8.3.3.tar.gz
07361cfd38b8c57207b9a5f8bf0c4456b7229b52 git-manpages-1.8.3.3.tar.gz
The following public repositories all have a copy of the v1.8.3.3
tag and the maint branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Also, http://www.kernel.org/pub/software/scm/git/ has copies of the
release tarballs.
Git v1.8.3.3 Release Notes
==========================
Fixes since v1.8.3.2
--------------------
* "git apply" parsed patches that add new files, generated by programs
other than Git, incorrectly. This is an old breakage in v1.7.11.
* Older cURL wanted piece of memory we call it with to be stable, but
we updated the auth material after handing it to a call.
* "git pull" into nothing trashed "local changes" that were in the
index.
* Many "git submodule" operations did not work on a submodule at a
path whose name is not in ASCII.
* "cherry-pick" had a small leak in its error codepath.
* Logic used by git-send-email to suppress cc mishandled names like
"A U. Thor" <author@example.xz>, where the human readable part
needs to be quoted (the user input may not have the double quotes
around the name, and comparison was done between quoted and
unquoted strings). It also mishandled names that need RFC2047
quoting.
* "gitweb" forgot to clear a global variable $search_regexp upon each
request, mistakenly carrying over the previous search to a new one
when used as a persistent CGI.
* The wildmatch engine did not honor WM_CASEFOLD option correctly.
* "git log -c --follow $path" segfaulted upon hitting the commit that
renamed the $path being followed.
* When a reflog notation is used for implicit "current branch",
e.g. "git log @{u}", we did not say which branch and worse said
"branch ''" in the error messages.
* Mac OS X does not like to write(2) more than INT_MAX number of
bytes; work it around by chopping write(2) into smaller pieces.
* Newer MacOS X encourages the programs to compile and link with
their CommonCrypto, not with OpenSSL.
Also contains various minor documentation updates.
----------------------------------------------------------------
Changes since v1.8.3.2 are as follows:
Andrew Pimlott (2):
lib-rebase: document exec_ in FAKE_LINES
t7500: fix flipped actual/expect
Anthony Ramine (1):
wildmatch: properly fold case everywhere
Brandon Casey (1):
http.c: don't rewrite the user:passwd string multiple times
Charles McGarvey (1):
gitweb: fix problem causing erroneous project list
Chris Rorvick (1):
git.txt: remove stale comment regarding GIT_WORK_TREE
Clemens Buchacher (1):
fix segfault with git log -c --follow
David Aguilar (4):
Makefile: fix default regex settings on Darwin
Makefile: add support for Apple CommonCrypto facility
cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
imap-send: eliminate HMAC deprecation warnings on Mac OS X
Dmitry Marakasov (1):
contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
Felipe Contreras (4):
read-cache: fix wrong 'the_index' usage
read-cache: trivial style cleanups
sequencer: remove useless indentation
sequencer: avoid leaking message buffer when refusing to create an empty commit
Filipe Cabecinhas (1):
compate/clipped-write.c: large write(2) fails on Mac OS X/XNU
Fredrik Gustafsson (1):
handle multibyte characters in name
Jeff King (1):
pull: update unborn branch tip after index
John Keeping (1):
git-config: update doc for --get with multiple values
Junio C Hamano (6):
deprecate core.statinfo at Git 2.0 boundary
t5551: do not use unportable sed '\+'
Documentation/diff-index: mention two modes of operation
Start preparing for 1.8.3.3
Update draft release notes to 1.8.3.3
Git 1.8.3.3
Michael S. Tsirkin (9):
t/send-email.sh: add test for suppress-cc=self
send-email: fix suppress-cc=self on cccmd
t/send-email: test suppress-cc=self on cccmd
send-email: make --suppress-cc=self sanitize input
t/send-email: add test with quoted sender
t/send-email: test suppress-cc=self with non-ascii
test-send-email: test for pre-sanitized self name
send-email: add test for duplicate utf8 name
send-email: sanitize author when writing From line
Ramkumar Ramachandra (6):
sha1_name: fix error message for @{u}
sha1_name: fix error message for @{<N>}, @{<date>}
diffcore-pickaxe: make error messages more consistent
diffcore-pickaxe doc: document -S and -G properly
check-ignore doc: fix broken link to ls-files page
fixup-builtins: retire an old transition helper script
René Scharfe (2):
t5004: avoid using tar for checking emptiness of archive
t5004: resurrect original empty tar archive test
Richard Hansen (1):
Documentation/merge-options.txt: restore `-e` option
SZEDER Gábor (1):
test: spell 'ls-files --delete' option correctly in test descriptions
Thomas Rast (2):
pull: merge into unborn by fast-forwarding from empty tree
apply: carefully strdup a possibly-NULL name
Torsten Bögershausen (1):
t7400: test of UTF-8 submodule names pass under Mac OS
Vikrant Varma (2):
help: add help_unknown_ref()
merge: use help_unknown_ref()
^ permalink raw reply [relevance 7%]
Results 1-9 of 9 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-07-15 21:13 7% [ANNOUNCE] Git v1.8.3.3 Junio C Hamano
2013-07-31 20:29 3% Difficulty adding a symbolic link, part 3 Dale R. Worley
2013-08-01 1:17 0% ` Duy Nguyen
2013-07-31 21:31 4% Making a patch: "git format-patch" does not produce the documented format Dale R. Worley
2013-07-31 21:48 0% ` John Keeping
[not found] <CANmdXCGZKBwjUP2FgcgmBQ12Gv-ttv78y0ZDjfWRAmR69S2mNQ@mail.gmail.com>
[not found] ` <CANmdXCFFfRJiCMV5U7Ap8wd=ek7Rs92TuaXDk8XNqQ_U7OxSKw@mail.gmail.com>
2013-08-05 11:01 ` Fwd: Bug: SEGV in git when applying the patches Rafal W.
2013-08-05 11:09 5% ` John Keeping
2013-08-05 11:10 0% ` Rafal W.
2013-08-15 4:43 5% Bug: commit -p breaks with -m Matan Nassau
2013-08-15 12:16 0% ` Jeff King
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).