On Fri, Jul 12, 2013 at 1:48 AM, Junio C Hamano gits...@pobox.com wrote:
Jonathan Nieder jrnie...@gmail.com writes:
My current thinking is no --- the patch has as a justification Now
we can test these aspects of .mailmap handling directly with a
low-level tool instead of using the tool most
In my earlier series introducing git cat-file --batch-check=format,
found here:
http://thread.gmane.org/gmane.comp.version-control.git/229761/focus=230041
I spent a little time optimizing revindex generation, and measured by
requesting information on a single object from a large repository.
Unless a command has separate --nul-terminated-{input,output}
options, the --nul-terminated-records (-z) option should apply
to both input and output for consistency. The caller knows that its
input paths may need to be protected for LF, and the program shows
these problematic paths to its
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/check-attr.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 075d01d..7cc9b5d 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -13,14 +13,14 @@
A command that has to deal with input/output that may contain LF
needs to offer the -z (--nul-terminated-records) option, and if it
does not support separate --nul-terminated-{input,output} options,
the -z option should govern both input and output. A caller that
uses -z knows that the paths it
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/check-ignore.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 0240f99..be22bce 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c
@@
Unless a command has separate --nul-terminated-{input,output}
options, the --nul-terminated-records (-z) option should apply
to both input and output for consistency. The caller knows that its
input paths may need to be protected for LF, and the program shows
these problematic paths to its
A common use of cat-file --batch-check is to feed a list
of objects from rev-list --objects or a similar command.
In this instance, all of our input objects are 40-byte sha1
ids. However, cat-file has always allowed arbitrary revision
specifiers, and feeds the result to get_sha1().
Fortunately,
The value we get from each low-level object_info function
(e.g., loose, packed) is actually the object type (or -1 for
error). Let's explicitly call it type, which will make
further refactorings easier to read.
Signed-off-by: Jeff King p...@peff.net
---
sha1_file.c | 20 ++--
1
On Fri, Jul 12, 2013 at 1:47 AM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
For each contact information (either in the form of ``Name
user@host'' or ...)
in order to clarify that the two forms of input is what you call
contact
Eric Sunshine sunsh...@sunshineco.com writes:
On Fri, Jul 12, 2013 at 1:48 AM, Junio C Hamano gits...@pobox.com wrote:
Jonathan Nieder jrnie...@gmail.com writes:
My current thinking is no --- the patch has as a justification Now
we can test these aspects of .mailmap handling directly with a
Until recently, the only items to request from
sha1_object_info_extended were type and size. This meant
that we always had to open a loose object file to determine
one or the other. But with the addition of the disk_size
query, it's possible that we can fulfill the query without
even opening the
Currently, packed_object_info can save some work by not
calculating the size or disk_size of the object if the
caller is not interested. However, it always calculates the
true object type, whether the caller cares or not, and only
optionally returns the easy-to-get representation type.
Let's swap
To calculate the type of a packed object, we must walk down
its delta chain until we hit a true base object with a real
type. Most of the code in packed_object_info is for handling
this case.
Let's hoist it out into a separate helper function, which
will make it easier to make the type-lookup
Eric Sunshine sunsh...@sunshineco.com writes:
I find it easier than your original, but I do not know if you would
want to repeat the Name... or user@host at the end. It does not
seem to add much useful information and is distracting.
Next attempt:
For each ``Name $$user@host$$'' or
Each caller of sha1_object_info_extended sets up an
object_info struct to tell the function which elements of
the object it wants to get. Until now, getting the type of
the object has always been required (and it is returned via
the return type rather than a pointer in object_info).
This can
We take in a struct object_info which contains pointers to
storage for items the caller cares about. But then rather
than pass the whole object to the low-level loose/packed
helper functions, we pass the individual pointers.
Let's pass the whole struct instead, which will make adding
more items
On Fri, Jul 12, 2013 at 2:34 AM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
... Is it desirable to do so
or should the user have more fine-grained control? (xargs -0 comes
to mind when thinking of a null-termination input switch.)
For the purposes
On Fri, Jul 12, 2013 at 2:18 AM, Junio C Hamano gits...@pobox.com wrote:
A command that has to deal with input/output that may contain LF
needs to offer the -z (--nul-terminated-records) option, and if it
does not support separate --nul-terminated-{input,output} options,
the -z option should
Hi Junio,
[administrivia: you seem to have mail-followup-to that points at you
and the list; is that really needed???]
I'm not subscribed to the list, so yes :-)
This happens when a client issues a fetch with a depth bigger or equal
to the number of commits the server is ahead of the
On Fri, Jul 12, 2013 at 12:54 PM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+ number of limitations (you cannot clone or fetch from it, nor
+ push into it), but is adequate if you are only interested in
+ the recent history of a large
On 07/12/2013 08:20 AM, Jeff King wrote:
A common use of cat-file --batch-check is to feed a list
of objects from rev-list --objects or a similar command.
In this instance, all of our input objects are 40-byte sha1
ids. However, cat-file has always allowed arbitrary revision
specifiers, and
#1 is Dale's suggested change. Dale, to include it we'd need your
Signed-off-by as per Documentation/SubmittingPatches.
#2 is a similar error-checking fix; I reviewed 'git grep \bopen\b'
and found one case where the return value was obviously not tested.
The corresponding Windows code path has
From: Dale R. Worley wor...@alum.mit.edu
open() returns -1 on failure, and indeed 0 is a possible success value
if the user closed stdin in our process. Fix the test.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
wrapper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
dup_devnull() did not check the return values of open() and dup2().
Fix this omission.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
run-command.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/run-command.c b/run-command.c
index aece872..1b7f88e 100644
---
On Fri, Jul 12, 2013 at 10:47:46AM +0200, Michael Haggerty wrote:
The solution feels a little hacky, but I'm not sure there is a better
one short of reverting the warning entirely.
We could also tie it to warn_ambiguous_refs (or add another config
variable), but I don't think that
On Thu, Jul 11, 2013 at 02:50:03PM -0700, Kyle J. McKay wrote:
The url value is considered a match to a url if the url value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So https://example.com/test; will
match https://example.com/test; and
On Thu, Jul 11, 2013 at 04:26:02PM -0700, Junio C Hamano wrote:
Thanks.
The differences since the last round I see are these. And I think
the series overall makes sense (I haven't look hard enough to pick
any nits yet, though).
Both v4 and the interdiff look fine to me. I gave it one more
On 07/12/2013 11:22 AM, Jeff King wrote:
Yet another option is to consider what the check is doing, and
accomplish the same thing in a different way. The real pain is that we
are individually trying to resolve each object by hitting the filesystem
(and doing lots of silly checks on the refname
On Thu, Jul 11, 2013 at 09:09:55AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Wed, Jul 10, 2013 at 12:36:40PM -0400, Brian Gernhardt wrote:
The newest test in t0008 streaming support for --stdin, seems to
hang sporadically on my MacBook Pro (running 10.8.4). The
The url value is considered a match to a url if the url value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So https://example.com/test; will
match https://example.com/test; and https://example.com/test/too;
but not https://example.com/testextra;.
People change email addresses quite often and sometimes
forget to add their entry to the mailmap file.
I have contacted lots of people, whose name occurs
multiple times in the short log having different
email addresses. The entries in the mailmap of
this patch are either confirmed by them or are
By now I contacted more than half the people, who might
get some .mailmap entries. Not all of them have responded,
but maybe 2/3 of those, whom I contacted.
I used 2 branches to get this work done. One branch having
all the proposed patches, where each patch just changes one
name, so I can send
(please Cc: me in replies, not subscribed to the lists)
Hi Cygwin and git developers,
Does following scenario show signs of bugs in Cygwin and/or git?
# setup git repo
$ cd /tmp
$ mkdir foo cd foo
$ git init
# create x: directory
$ mkdir x:
$ ls
x:
# create Windows X: drive, cygwin utils can
On Jul 12, 2013, at 02:59, Jeff King wrote:
On Thu, Jul 11, 2013 at 02:50:03PM -0700, Kyle J. McKay wrote:
A few comments on the implementation:
+enum http_option_type {
+ opt_post_buffer = 0,
+ opt_min_sessions,
We usually put enum fields in ALL_CAPS to mark them as constants
Webmail actualización
20GB 23GB
Su buzón ha superado el límite de almacenamiento lo establecido por el
administrador y usted no será capaz de recibir nuevos correos hasta
que vuelva a validar. Para revalidar:
On 07/12/2013 08:42 AM, Mikko Rapeli wrote:
(please Cc: me in replies, not subscribed to the lists)
Hi Cygwin and git developers,
Does following scenario show signs of bugs in Cygwin and/or git?
# setup git repo
$ cd /tmp
$ mkdir foo cd foo
$ git init
# create x: directory
$ mkdir x:
$ ls
Hello,
you may have noticed I am currently trying to bring the
mailmap file of git itself up to date. I noticed
some behavior, which I did not expect. Have a look yourself:
---
# prepare test environment:
mkdir testmailmap
cd testmailmap/
git init
# do a
Jeff King p...@peff.net writes:
On Tue, Jul 09, 2013 at 10:26:04PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
...
I'm torn on this one. It really does provide us with more compile-time
safety checks, but it's annoying that -Wall -Werror will no longer
work out of the
Jeff King p...@peff.net writes:
Subject: [PATCH] t0008: avoid SIGPIPE race condition on fifo
To test check-ignore's --stdin feature, we use two fifos to
send and receive data. We carefully keep a descriptor to its
input open so that it does not receive EOF between input
lines. However, we
Stefan Beller stefanbel...@googlemail.com writes:
By now I contacted more than half the people, who might
get some .mailmap entries. Not all of them have responded,
but maybe 2/3 of those, whom I contacted.
I used 2 branches to get this work done. One branch having
all the proposed patches,
Stefan Beller stefanbel...@googlemail.com writes:
People change email addresses quite often and sometimes
forget to add their entry to the mailmap file.
I have contacted lots of people, whose name occurs
multiple times in the short log having different
email addresses. The entries in the
On Jul 12, 2013, at 6:35 AM, Jeff King p...@peff.net wrote:
Subject: [PATCH] t0008: avoid SIGPIPE race condition on fifo
Was able to complete a prove run with this patch. Many thanks.
~~ Brian
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
configuration that says something like:
[remote ko]
url =
Jeff King p...@peff.net writes:
The results for running (in linux.git):
$ git rev-list --objects --all objects
$ git cat-file --batch-check='%(objectsize:disk)' objects /dev/null
I can see how these patches are very logical avenue to grab only
on-disk footprint for large number of
t2104 currently checks for the exact index version 2 or 3,
depending if there is a skip-worktree flag or not. Other
index versions do not use extended flags and thus cannot
be tested for version changes.
Make this test update the index to version 2 at the beginning
of the test. Testing the
Add the possibility of re-reading the index file, if it changed
while reading.
The index file might change during the read, causing outdated
information to be displayed. We check if the index file changed
by using its stat data as heuristic.
Helped-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Move index version 2 specific functions to their own file. The non-index
specific functions will be in read-cache.c, while the index version 2
specific functions will be in read-cache-v2.c.
Helped-by: Nguyen Thai Ngoc Duy pclo...@gmail.com
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Add documentation for the index reading api. This also includes
documentation for the new api functions introduced in the next patch.
Helped-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Documentation/technical/api-in-core-index.txt | 54
Add an api for access to the index file. Currently there is only a very
basic api for accessing the index file, which only allows a full read of
the index, and lets the users of the data filter it. The new index api
gives the users the possibility to use only part of the index and
provides
A partially read index file currently cannot be written to disk. Make
sure that never happens, by erroring out when a caller tries to change a
partially read index. The caller is responsible for reading the whole
index when it's trying to change it later.
Forcing the caller to load the right
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
builtin/grep.c | 71 ++
1 file changed, 37 insertions(+), 34 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index a419cda..8b02644 100644
--- a/builtin/grep.c
+++
Use the index api to read only part of the index, if the on-disk version
of the index is index-v5.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
builtin/ls-files.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/builtin/ls-files.c
Thomas Rast tr...@inf.ethz.ch writes:
#1 is Dale's suggested change. Dale, to include it we'd need your
Signed-off-by as per Documentation/SubmittingPatches.
#2 is a similar error-checking fix; I reviewed 'git grep \bopen\b'
and found one case where the return value was obviously not
The same kind of cleanup as sent earlier today
(2e2ae79df4fabea0157c5eb527b5396eb89185a1 locally here)
I asked all the people before, whether
they like their lines added. Many had
requests to change the order of the mail address.
When having this patch applied, you'll notice the
bug as described
Make the in-memory format aware of the stat_crc used by index-v5.
It is simply ignored by index version prior to v5.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
cache.h | 1 +
read-cache.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/cache.h
Add a documentation of the index file format version 5 to
Documentation/technical.
Helped-by: Michael Haggerty mhag...@alum.mit.edu
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Thomas Rast tr...@student.ethz.ch
Helped-by: Nguyen Thai Ngoc Duy pclo...@gmail.com
Helped-by: Robin Rosenberg
Since the cache-tree data is saved as part of the directory data,
we already read it at the beginning of the index. The cache-tree
is only converted from this directory data.
The cache-tree data is arranged in a tree, with the children sorted by
pathlen at each node, while the ondisk format is
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk format of the index file version 5, conflicts and
resolved data is read at the same time, and the resolve-undo
data is then converted to the in-memory format.
Helped-by:
Make git read the index file version 5 without complaining.
This version of the reader doesn't read neither the cache-tree
nor the resolve undo data, but doesn't choke on an index that
includes such data.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Nguyen Thai Ngoc Duy
Write the cache-tree data for the index version 5 file format. The
in-memory cache-tree data is converted to the ondisk format, by adding
it to the directory entries, that were compiled from the cache-entries
in the step before.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Make update-index always rewrite the index when a index-version
is given, even if the index already has the right version.
This option is used for performance testing the writer and
reader.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
builtin/update-index.c | 4 ++--
1 file changed, 2
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk format of the index file version 5, conflicts and
resolved data is read at the same time, and the resolve-undo
data is then converted to the in-memory format.
Helped-by:
Write the index version 5 file format to disk. This version doesn't
write the cache-tree data and resolve-undo data to the file.
The main work is done when filtering out the directories from the
current in-memory format, where in the same turn also the conflicts
and the file data is calculated.
From: Thomas Rast tr...@inf.ethz.ch
Add a performance test for index version [23]/4/5 by using
git update-index --index-version=x, thus testing both the reader
and the writer speed of all index formats.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
Signed-off-by: Thomas Gummerer
Stefan Beller stefanbel...@googlemail.com writes:
Hello,
you may have noticed I am currently trying to bring the
mailmap file of git itself up to date. I noticed
some behavior, which I did not expect. Have a look yourself:
---
# prepare test environment:
mkdir testmailmap
Johannes Sixt j...@kdbg.org writes:
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
configuration that says something like:
The commands are exactly as given in the first mail.
(I run it multiple times, and this exact behavior comes up)
I think there is some problem with the capitalisation
of the first (if not all) characters. (Hence the small 'a')
So either check with these example commands yourself, or take my
Kyle J. McKay mack...@gmail.com writes:
The url value is considered a match to a url if the url value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So https://example.com/test; will
match https://example.com/test; and
Kyle J. McKay mack...@gmail.com writes:
+ if (!strcmp(sslcertpasswordprotected, key)) {
+ if (check_matched_len(opt_passwd_req, matchlen))
+ return 0;
if (git_config_bool(var, value))
ssl_cert_password_required = 1;
The existing code triggers only when the configuration variable is
set to true. Once the variable is set to true in a more generic
configuration file (e.g. ~/.gitconfig), it cannot be overriden to
false in the repository specific one (e.g. .git/config).
Signed-off-by: Junio C Hamano
Stefan Beller wrote:
--- a/.mailmap
+++ b/.mailmap
@@ -5,99 +5,146 @@
[...]
Chris Shoemaker c.shoema...@cox.net
-Dan Johnson computerdr...@gmail.com
Dana L. How dana...@gmail.com
Dana L. How h...@deathvalley.cswitch.com
Daniel Barkalow barka...@iabervon.org
+Dan Johnson
Which tool would you recommend to sort stuff?
Or rather the exact parameters for /usr/bin/sort ?
Thanks,
Stefan
On 07/12/2013 08:57 PM, Jonathan Nieder wrote:
Stefan Beller wrote:
--- a/.mailmap
+++ b/.mailmap
@@ -5,99 +5,146 @@
[...]
Chris Shoemaker c.shoema...@cox.net
-Dan Johnson
Junio C Hamano wrote:
The existing code triggers only when the configuration variable is
set to true. Once the variable is set to true in a more generic
configuration file (e.g. ~/.gitconfig), it cannot be overriden to
false in the repository specific one (e.g. .git/config).
[...]
---
From the man page
*** WARNING *** The locale specified by the environment affects sort
order. Set LC_ALL=C to get the traditional sort order that uses
native byte values.
And indeed I can avoid being nitpicked again for wrong sorting. ;)
On 07/12/2013 09:02 PM, Stefan Beller wrote:
Ok I am sending all confirmed changes now again
in one big patch, as the sorting was wrong.
Stefan Beller (1):
.mailmap: Map email addresses to names
.mailmap | 135 +++
1 file changed, 110 insertions(+), 25 deletions(-)
--
People change email addresses quite often and sometimes
forget to add their entry to the mailmap file.
I have contacted lots of people, whose name occurs
multiple times in the short log having different
email addresses. The entries in the mailmap of
this patch are either confirmed by them or are
Stefan Beller stefanbel...@googlemail.com writes:
Ok I am sending all confirmed changes now again
in one big patch, as the sorting was wrong.
Stefan Beller (1):
.mailmap: Map email addresses to names
So this corresponds to both of your patches, or just the first
batch?
--
To unsubscribe
Jonathan Nieder jrnie...@gmail.com writes:
FWIW the GIT_SSL_CERT_PASSWORD_PROTECTED envvar has a similar can
only enable behavior, but since it's documented, that's not as big
of a problem. Do you remember why it was written that way?
Not me ;-).
If I have to guess, it is probably that
Am 12.07.2013 19:40, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
Stefan Beller stefanbel...@googlemail.com writes:
Additionally to adding (name, email) mappings to the
.mailmap file, it has also been sorted alphabetically.
(which explains the removals, which are added
3 lines later on again).
What is this 3 lines later on again about? Is it a remnant
On Fri, Jul 12, 2013 at 10:23:34AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
The results for running (in linux.git):
$ git rev-list --objects --all objects
$ git cat-file --batch-check='%(objectsize:disk)' objects /dev/null
I can see how these patches are very
Stefan Beller stefanbel...@googlemail.com writes:
# Adding the line to the mailmap should make life easy, so we know
# it's the same person
echo A a...@example.org changed_em...@example.org .mailmap
While I was looking at this, I noticed this piece of code:
diff --git
On 07/12/2013 10:28 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
# Adding the line to the mailmap should make life easy, so we know
# it's the same person
echo A a...@example.org changed_em...@example.org .mailmap
While I was looking at this,
Junio C Hamano gits...@pobox.com writes:
Stefan Beller stefanbel...@googlemail.com writes:
git shortlog -sne
1 A a...@example.org
1 A a...@example.org
This is coming from mailmap.c::add_mapping() that downcases the
e-mail address.
On Fri, Jul 12, 2013 at 09:23:54AM -0700, Junio C Hamano wrote:
In that case, check-ignore gets a SIGPIPE and dies. The
outer shell then tries to open the output fifo but blocks
indefinitely, because there is no writer. We can fix it by
keeping a descriptor open through the whole
On Fri, Jul 12, 2013 at 09:10:30AM -0700, Junio C Hamano wrote:
You can fix it with -Wno-zero-format-length, so the hassle is not
huge. But I am also inclined to just drop this one. We have lived
without the extra safety for a long time, and list review does tend to
catch such problems in
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Stefan Beller stefanbel...@googlemail.com writes:
git shortlog -sne
1 A a...@example.org
1 A a...@example.org
This is coming from mailmap.c::add_mapping() that downcases the
At 06:07 -0700 12 Jul 2013, Kyle J. McKay mack...@gmail.com wrote:
I don't think it's necessary to split the URL apart though. Whatever
URL the user gave to git on the command line (at some point even if
it's now stored as a remote setting in config) complete with URL-
encoding, user names,
Your patch seems to do it.
I added a test case which doesn't fail, if your patch is added.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
t/t4203-mailmap.sh | 33 +
1 file changed, 33 insertions(+)
diff --git a/t/t4203-mailmap.sh
Johannes Sixt j...@kdbg.org writes:
We have three independent options that the user can choose in any
combination:
o --force given or not;
o --lockref semantics enabled or not;
o refspec with or without +;
and these two orthogonal preconditions of the push
o push is fast-forward
In parse_name_and_email() function, there is this line:
*name = (nstart nend ? nstart : NULL);
When the function is given a buffer A a...@example.org old@x.z,
nstart scans from the beginning of the buffer, skipping whitespaces
(there isn't any, so nstart points at the buffer), while
From: Stefan Beller stefanbel...@googlemail.com
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t4203-mailmap.sh | 33 +
1 file changed, 33 insertions(+)
diff --git a/t/t4203-mailmap.sh
There were a few bugs in mailmap parsing and matching code.
Junio C Hamano (3):
mailmap: do not lose single-letter names
mailmap: do not downcase mailmap entries
mailmap: style fixes
Stefan Beller (1):
Add a testcase for checking case insensitivity of mailmap
mailmap.c | 37
Wrap overlong lines and format the multi-line comments to match our
coding style.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
mailmap.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index a7e92db..5a3347d 100644
--- a/mailmap.c
The email addresses in the records read from the .mailmap file are
downcased very early, and then used to match against e-mail
addresses in the input. Because we do use case insensitive version
of string list to manage these entries, there is no need to do this,
and worse yet, downcasing the
On Fri, Jul 12, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
From: Stefan Beller stefanbel...@googlemail.com
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t4203-mailmap.sh | 33 +
1
Here is my previous review comments in a squashable patch form. The
result seems to pass all 27 combinations (fetch.prune, remote.*.prune
and command line all are tristate yes/no/unspecified).
Without the fix-up in *.c files, three combinations seem to fail.
Documentation/config.txt | 3 +-
On Fri, Jul 12, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
From: Stefan Beller stefanbel...@googlemail.com
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t4203-mailmap.sh | 33 +
1
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As many of you may know, I hate to do back-to-back What's cooking,
but we ended up acquiring many new topics, and many existing ones
have moved
1 - 100 of 108 matches
Mail list logo
