Am 12.07.2013 23:19, schrieb Junio C Hamano:
> Johannes Sixt 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 orthogona
On 07/13/2013 02:35 AM, Eric Sunshine wrote:
> Two tests in t4203-mailmap.sh set up the mapping =>
> in an apparent attempt to check that email address
> remapping works as expected (in addition to name remapping which is also
> tested). To test the remapping, git-shortlog is invoked but the
> i
On Jul 11, 2013, at 10:41 AM, Junio C Hamano wrote:
> Doug Bell writes:
>
>> The docs seem to say that doing
>>
>> git show-ref --head --tags
>>
>> would show both the HEAD ref and all the tag refs. However, doing
>> both --head and either of --tags or --heads would filter out the HEAD
>
Updated the documentation to describe the new behavior.
Doug Bell (1):
show-ref: make --head always show the HEAD ref
Documentation/git-show-ref.txt | 10 ++
builtin/show-ref.c | 8 ++--
2 files changed, 12 insertions(+), 6 deletions(-)
--
1.7.12.4
--
To unsubscribe
The docs seem to say that doing
git show-ref --head --tags
would show both the HEAD ref and all the tag refs. However, doing
both --head and either of --tags or --heads would filter out the HEAD
ref.
Also update the documentation to describe the new behavior.
Signed-off-by: Doug Bell
-
Introduce command check-mailmap, similar to check-attr and check-ignore,
which allows direct testing of .mailmap configuration.
As plumbing accessible to scripts and other porcelain, check-mailmap
publishes the stable, well-tested .mailmap functionality employed by
built-in Git commands. Conseque
Test the command-line interface of check-mailmap.
(Actual .mailmap functionality is already covered by existing tests.)
Signed-off-by: Eric Sunshine
---
t/t4203-mailmap.sh | 43 +++
1 file changed, 43 insertions(+)
diff --git a/t/t4203-mailmap.sh b/t/t42
This is a re-roll of v2 [1] which introduces git-check-mailmap. The
primary motivation for this command is to expose git's stable,
well-tested C-implementation of .mailmap functionality to scripts and
porcelains, thus relieving them of the need to re-implement support
themselves. The git-contacts [
Two tests in t4203-mailmap.sh set up the mapping =>
in an apparent attempt to check that email address
remapping works as expected (in addition to name remapping which is also
tested). To test the remapping, git-shortlog is invoked but the
invocation lacks the -e option instructing it to show em
On Mon, Jul 8, 2013 at 3:03 PM, Matthieu Brucher
wrote:
> Hi,
>
> I tried without spec, but then it tried importing everything, even
> though there was a .gitignore and a .git/config/exclude file.
> Then, it crashed during the importation because it could find an old
> branch (I don't have access
On Wed, Jul 10, 2013 at 3:10 AM, Muhammad Bashir Al-Noimi
wrote:
> On Tue, Jul 9, 2013 at 10:47 PM, Muhammad Bashir Al-Noimi
> wrote:
>> Now I've to make some tests because the new version is completely different
>> than the old one so I'll send a feedback soon.
>
> Thanks guys, the recent git-co
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 move
On Fri, Jul 12, 2013 at 5:38 PM, Junio C Hamano wrote:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Junio C Hamano
> ---
> t/t4203-mailmap.sh | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/t/t4203-mailmap.sh b/t/t4203-mail
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 +-
b
On Fri, Jul 12, 2013 at 5:38 PM, Junio C Hamano wrote:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Junio C Hamano
> ---
> t/t4203-mailmap.sh | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/t/t4203-mailmap.sh b/t/t4203-mail
Wrap overlong lines and format the multi-line comments to match our
coding style.
Signed-off-by: Junio C Hamano
---
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
+++ b/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 rewri
From: Stefan Beller
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
t/t4203-mailmap.sh | 33 +
1 file changed, 33 insertions(+)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 842b754..07152e9 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4
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 +++
In parse_name_and_email() function, there is this line:
*name = (nstart < nend ? nstart : NULL);
When the function is given a buffer "A ",
nstart scans from the beginning of the buffer, skipping whitespaces
(there isn't any, so nstart points at the buffer), while nend starts
from one byt
Johannes Sixt 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 or
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
---
t/t4203-mailmap.sh | 33 +
1 file changed, 33 insertions(+)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 842b754..07152e9 10
At 06:07 -0700 12 Jul 2013, "Kyle J. McKay" 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, port names, etc. i
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Stefan Beller writes:
>>
>>> git shortlog -sne
>>> 1 A
>>> 1 A
>>
>> This is coming from mailmap.c::add_mapping() that downcases the
>> e-mail address.
>>
>> changed_em...@example.org is mapped to a...@exampl
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 pr
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
Junio C Hamano writes:
> Stefan Beller writes:
>
>> git shortlog -sne
>> 1 A
>> 1 A
>
> This is coming from mailmap.c::add_mapping() that downcases the
> e-mail address.
>
> changed_em...@example.org is mapped to a...@example.org because of this
> downcasing,
On 07/12/2013 10:28 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> # Adding the line to the mailmap should make life easy, so we know
>> # it's the same person
>> echo "A " > .mailmap
>
> While I was looking at this, I noticed this piece of code:
>
> diff --git a/mailmap
Stefan Beller writes:
> # Adding the line to the mailmap should make life easy, so we know
> # it's the same person
> echo "A " > .mailmap
While I was looking at this, I noticed this piece of code:
diff --git a/mailmap.c b/mailmap.c
index 2a7b366..418081e 100644
--- a/mailmap
On Fri, Jul 12, 2013 at 10:23:34AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The results for running (in linux.git):
> >
> > $ git rev-list --objects --all >objects
> > $ git cat-file --batch-check='%(objectsize:disk)' /dev/null
>
> I can see how these patches are very logical
Stefan Beller 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 from
the previous iterati
Am 12.07.2013 19:40, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 12.07.2013 00:14, schrieb Junio C Hamano:
>>> Johannes Sixt writes:
>>>
Again: Why not just define +refspec as the way to achieve this check?
>>>
>>> What justification do we have to break existing people's
>>> con
Jonathan Nieder 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 these two are thou
Stefan Beller 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 from this list: send the
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 tr
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(-)
--
1.8.3.2.
>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:
>
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).
[...]
> --- a
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
>> -Dan Johnson
>> Dan
Stefan Beller wrote:
> --- a/.mailmap
> +++ b/.mailmap
> @@ -5,99 +5,146 @@
[...]
> Chris Shoemaker
> -Dan Johnson
> Dana L. How
> Dana L. How
> Daniel Barkalow
> +Dan Johnson
Small nit: the sorting looks broken here and in similar places below
(the usual ordering is Dan < Dana < Daniel
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
---
http.c
"Kyle J. McKay" 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;
>
"Kyle J. McKay" writes:
> The value is considered a match to a url if the 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 n
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 lates
Johannes Sixt writes:
> Am 12.07.2013 00:14, schrieb Junio C Hamano:
>> Johannes Sixt 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:
>>
>> [remo
Stefan Beller 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
> cd testmailma
From: Thomas Rast
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
Signed-off-by: Thomas Gummerer
---
t/perf/p0003-index.sh | 59 +++
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.
H
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: Thom
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
---
read-cache-v5.c | 53 +++
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
---
builtin/update-index.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
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: Thom
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
Helped-by: Nguyen Thai Ngoc Duy
Helped-by: Thomas Rast
Signed-o
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 sor
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
---
cache.h | 1 +
read-cache.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/cache.h b/cache.h
index 455b77
Add a documentation of the index file format version 5 to
Documentation/technical.
Helped-by: Michael Haggerty
Helped-by: Junio C Hamano
Helped-by: Thomas Rast
Helped-by: Nguyen Thai Ngoc Duy
Helped-by: Robin Rosenberg
Signed-off-by: Thomas Gummerer
---
Documentation/technical/index-file-fo
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
Thomas Rast 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 tested.
> The cor
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
---
builtin/ls-files.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
i
Signed-off-by: Thomas Gummerer
---
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
+++ b/builtin/grep.c
@@ -368,41 +36
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 par
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 functi
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
Signed-off-by: Thomas Gummerer
---
Documentation/technical/api-in-core-index.txt | 54 +--
1 file change
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
Signed-off-by: Thomas Gummerer
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
Signed-off-by: Thomas Gummerer
---
Makefile | 2 +
cache.h
Split index file version specific functionality to their own functions,
to prepare for moving the index file version specific parts to their own
file. This makes it easier to add a new index file format later.
Signed-off-by: Thomas Gummerer
---
cache.h | 5 +-
read-cache.c
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 skip-wo
Hi,
previous rounds (without api) are at $gmane/202752, $gmane/202923,
$gmane/203088 and $gmane/203517, the previous round with api was at
$gmane/229732. Thanks to Junio, Duy and Eric for their comments on
the previous round.
Changes since the previous round:
Add documentation for the index rea
Jeff King writes:
> The results for running (in linux.git):
>
> $ git rev-list --objects --all >objects
> $ git cat-file --batch-check='%(objectsize:disk)' /dev/null
I can see how these patches are very logical avenue to grab only
on-disk footprint for large number of objects, but among the
Am 12.07.2013 00:14, schrieb Junio C Hamano:
> Johannes Sixt 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 = ke
On Jul 12, 2013, at 6:35 AM, Jeff King 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 majord...@vger.ker
Stefan Beller 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 mailmap of
> this patch ar
Stefan Beller 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, where each patch just
Jeff King 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 do not do
Jeff King writes:
> On Tue, Jul 09, 2013 at 10:26:04PM -0700, Junio C Hamano wrote:
>
>> Jeff King 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 box.
>>
>>
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
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
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:
https://docs.google.com/a/uc.cl/spreadsheet/viewform?formkey=dC1aMjNqcThwR3BLaVJW
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
(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 ca
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 tr
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 it
The value is considered a match to a url if the 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";.
On Thu, Jul 11, 2013 at 09:09:55AM -0700, Junio C Hamano wrote:
> Jeff King 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 h
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 refn
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
On Thu, Jul 11, 2013 at 02:50:03PM -0700, Kyle J. McKay wrote:
> The value is considered a match to a url if the 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 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
dup_devnull() did not check the return values of open() and dup2().
Fix this omission.
Signed-off-by: Thomas Rast
---
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
--- a/run-command.c
+++ b/run-co
#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"
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
---
wrapper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wrapper.c b/wrapper.c
index dd7ecbb
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
> specifier
On Fri, Jul 12, 2013 at 12:54 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy 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 project with a long history
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
94 matches
Mail list logo
