Junio C Hamano gits...@pobox.com @ 2014-11-24 13:37 ALMT:
[jc: added those who were mentioned but were missing back to Cc]
On Sun, Nov 23, 2014 at 11:02 PM, Alex Kuleshov kuleshovm...@gmail.com
wrote:
Junio C Hamano:
Fixing these callers are done as separate patches, that can be
applied
Hello Guys,
I found bug in http-backend.c with config-flag http.receivepack You describe
in our documentation: This serves git send-pack clients, allowing push. It is
disabled by default for anonymous users, and enabled by default for users
authenticated by the web server. It can be disabled
Duy Nguyen schrieb am 24.11.2014 um 02:23:
On Tue, Nov 18, 2014 at 4:26 AM, Jeff King p...@peff.net wrote:
Yes, it is only as safe as SHA-1 in the sense that you have GPG-signed
only a SHA-1 hash. If somebody can find a collision with a hash you have
signed, they can substitute the colliding
Jeff King schrieb am 21.11.2014 um 19:01:
On Fri, Nov 21, 2014 at 05:08:19PM +0100, Michael J Gruber wrote:
git add foo bar adds neither foo nor bar when bar is ignored, but dies
to let the user recheck their command invocation. This becomes less
helpful when git add foo.* is subject to
Torsten Bögershausen schrieb am 22.11.2014 um 15:59:
+test_expect_success 'error out when attempting to add ignored ones but add
others' '
+ touch a.if
+ test_must_fail git add a.??
+ ! (git ls-files | grep \\.ig)
+ (git ls-files | grep a.if)
+'
I am somewhat allergic to pipes
When a commit is amended a pre-commit hook that verifies the commit's
contents might not find what it's looking for if for example it looks at
the differences against HEAD when HEAD~1 might be more appropriate.
Inform the commit hook that --amend is being used so that hook authors
can do e.g.
On Mon, Nov 24, 2014 at 5:15 PM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Duy Nguyen schrieb am 24.11.2014 um 02:23:
On Tue, Nov 18, 2014 at 4:26 AM, Jeff King p...@peff.net wrote:
Yes, it is only as safe as SHA-1 in the sense that you have GPG-signed
only a SHA-1 hash. If somebody
Now system_path returns path which is allocated string to callers;
It prevents memory leaks in some places. All callers of system_path
are owners of path string and they must release it.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
attr.c| 8 +++---
builtin/config.c
Now system_path returns path which is allocated string to callers;
It prevents memory leaks in some places. All callers of system_path
are owners of path string and they must release it.
Added new parameter to wrapper.c/int access_or_die - etc_config, because
only etc_config in this case use
Now system_path returns path which is allocated string to callers;
It prevents memory leaks in some places. All callers of system_path
are owners of path string and they must release it.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
attr.c| 8 +++---
builtin/config.c
On Mon, Nov 24, 2014 at 02:50:04AM +0300, Роман Донченко wrote:
The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).
I change the sender's name to an all-Cyrillic string in the tests so that
its encoded form goes over the 76 characters
On Sun, Nov 23, 2014 at 11:27:51PM -0800, Junio C Hamano wrote:
Was the change to the test to use Cyrillic really necessary, or did it
suffice if you simply extended the existsing Funny Name spelled with
strange accents, but you substituted the whole string anyway?
Until I found out what
On Mon, Nov 24, 2014 at 11:15:34AM +0100, Michael J Gruber wrote:
I wonder if we can have an option to sign all blob content of the tree
associated to a commit, and the content of parent commit(s). It's more
expensive than signing just commit/tag content. But it's also safer
without
It depends what we mean with old:
cygwin 1.5 is old, and I lost my test installation this summer:
One netbook was converted from XP to Linux, the other machine needs to be
re-installed and CYGWIN 1.5 is no longer available for download.
I can confirm that Ramsays patch works with CYGWIN
Jeff King p...@peff.net writes:
On Sun, Nov 23, 2014 at 10:10:47AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... Possibly because I do not know that those instructions
are written down anywhere. We usually catch such things in review these
days, but there are many
Torsten Bögershausen wrote:
gcc under cygwin reports several warnings like this:
warning: implicit declaration of function 'memmem'
[-Wimplicit-function-declaration]
This has been observed under CYGWIN-32 with GCC 4.7.3 as well
as CYGWIN-64 with gcc v4.8.3-5 x86-64
Do not #define
Junio C Hamano gits...@pobox.com писал в своём письме Mon, 24 Nov 2014
10:27:51 +0300:
On Sun, Nov 23, 2014 at 3:50 PM, Роман Донченко d...@corrigendum.ru
wrote:
The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).
I change the sender's
Is there a plan for upgrading to a better hash function in the future?
(E.g., should it become an urgent need.)
What are the roadblocks to adoption of a replacement hash function?
Just documenting this would go a long way towards making it possible
to upgrade some day.
Thanks,
Nico
--
--
To
Jeff King p...@peff.net писал в своём письме Mon, 24 Nov 2014 18:36:09
+0300:
On Mon, Nov 24, 2014 at 02:50:04AM +0300, Роман Донченко wrote:
The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).
I change the sender's name to an
In their effort to emulate POSIX as close as possible, the MSYS tools
and Cygwin treat the file name foo.exe as foo when the latter is
asked for, but not present, but the former is present.
Following this rule, 'cp /bin/sh a/bin' actually copies the file
/bin/sh.exe, so that we now have
Patch looks good to me. Do you know if this has been reported to the
Cygwin maintainers? The behavior seems counterintuitive --- I would
expect _GNU_SOURCE to override everything else (since I thought that
was the point of _GNU_SOURCE).
I don't know, it seems that CYGWIN is now in class
I agree that the approach taken here is a sensible way to implement
the design, _if_ the design and the problem it tries to solve makes
sense. I am not sure about that yet myself, though.
This is a first things first.
What aspect of the problem to be solved is in question?
0xAX kuleshovm...@gmail.com writes:
Now system_path returns path which is allocated string to callers;
It prevents memory leaks in some places. All callers of system_path
are owners of path string and they must release it.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index d01bbdc..4b68bba 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -101,7 +101,7 @@ test_expect_success \
ten=0123456789 hundred=$ten$ten$ten$ten$ten$ten$ten$ten$ten$ten
echo long filename
Junio C Hamano gits...@pobox.com @ 2014-11-25 01:33 ALMT:
-static const char *git_etc_gitattributes(void)
+static char *git_etc_gitattributes(void)
Hmph, I think this should keep returning const char *, as the
caller is not expected to free the pointer or write into the memory
held by the
Alex Kuleshov kuleshovm...@gmail.com writes:
Junio C Hamano gits...@pobox.com @ 2014-11-25 01:33 ALMT:
...
if (git_attr_system()) {
- elem = read_attr_from_file(git_etc_gitattributes(), 1);
+ char *etc_attributes = git_etc_gitattributes();
+ elem =
On 2014-11-24 18.41, Junio C Hamano wrote:
...
Do we refer to t/README from CodingGuidelines where we tell the
developers to always write tests to prevent other people from
breaking tomorrow what you did today? If not, perhaps that is what
needs to be added.
That might make sense. It might
Alex Kuleshov kuleshovm...@gmail.com writes:
One thing to note is that this illustration does not consider memory
pointed at by the system_wide variable here (from attr.c)
static const char *git_etc_gitattributes(void)
{
static const char *system_wide;
I've been confused several times by the docs when running across
the word 'usually'. It is difficult to know before hand if it
means 'under normal conditions' or 'by default'. I've gone through
the Documentation to identify specific cases where I think that 'by
default' is more explanatory than
This function behaves the same as string_list_insert, just the
starting indexes for searching, where to insert into the list is also
a parameter. So if you have knowledge on where to search for the string
to be inserted, you may have a speed up version of string_list_insert.
As we're not using
Signed-off-by: Stefan Beller sbel...@google.com
---
string-list.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/string-list.h b/string-list.h
index 494eb5d..40ffe0c 100644
--- a/string-list.h
+++ b/string-list.h
@@ -55,9 +55,19 @@ void string_list_remove_empty_items(struct
No functional changes intended. This commit makes user of higher level
and better documented functions of the string list API, so the code is
more understandable.
Note that also the required computational amount should not change
in principal as we need to look up the item no matter if it is
Anything holding this back?
On Thu, Nov 20, 2014 at 4:38 PM, Stefan Beller sbel...@google.com wrote:
From: Ronnie Sahlberg sahlb...@google.com
write_ref_sha1 tries to update the reflog while updating the ref.
Move these reflog changes out into its own function so that we can do the
same
On 24/11/14 07:20, Torsten Bögershausen wrote:
On 2014-11-24 00.15, Ramsay Jones wrote:
On 23/11/14 18:53, Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
On 23/11/14 14:16, Torsten Bögershausen wrote:
gcc under cygwin reports several warnings like this:
warning:
On 24/11/14 17:59, Jonathan Nieder wrote:
Torsten Bögershausen wrote:
gcc under cygwin reports several warnings like this:
warning: implicit declaration of function 'memmem'
[-Wimplicit-function-declaration]
This has been observed under CYGWIN-32 with GCC 4.7.3 as well
as CYGWIN-64
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
I updated from cygwin 1.5 to cygwin 1.7 at the beginning of the year.
Since it is no longer supported, I don't think we need to worry about
version 1.5. When I said 'old installation' I meant my old version 1.7
32-bit installation.
One netbook
ping?
I asked around and the people who know of `git remote` fell in these two
categories:
- those who know of this bug and then first set the fetch URL and
then the push URL.
- those who did not expect the current behavior.
The command 'git remote set-url NAME URL' reads as set the URL(s)
Stefan Beller sbel...@google.com writes:
Anything holding this back?
I do not recall anything objectionable offhand. Perhaps fell
between the cracks during a patch storm or something.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
No functional changes intended. This commit makes user of higher level
and better documented functions of the string list API, so the code is
more understandable.
Note that also the required computational amount should not change
in principal as we need to look up the item no matter if it is
Peter Wu pe...@lekensteyn.nl writes:
I propose to add the option --fetch next to --push with the meaning set
the fetch/push URL of remote NAME to URL. Then --fetch --push means
set the fetch and push URL of remote NAME to URL.
What would (and should) the configuration look like after you did
On Monday 24 November 2014 14:04:07 Junio C Hamano wrote:
Peter Wu pe...@lekensteyn.nl writes:
I propose to add the option --fetch next to --push with the meaning set
the fetch/push URL of remote NAME to URL. Then --fetch --push means
set the fetch and push URL of remote NAME to URL.
On Mon, Nov 24, 2014 at 11:16:03PM +0100, Peter Wu wrote:
A new option --fetch introducing a different behaviour is
perfectly fine; existing users who are not using it will not be
harmed by sudden behaviour change.
As stated before, I took care to avoid backwards incompatibilities. The
On 23/11/14 23:15, Ramsay Jones wrote:
On 23/11/14 18:53, Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
On 23/11/14 14:16, Torsten Bögershausen wrote:
gcc under cygwin reports several warnings like this:
warning: implicit declaration of function 'memmem'
On Monday 24 November 2014 17:22:44 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:16:03PM +0100, Peter Wu wrote:
A new option --fetch introducing a different behaviour is
perfectly fine; existing users who are not using it will not be
harmed by sudden behaviour change.
As stated
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
...
Although I have not done an actual diff of the various cdef.h files, they
do appear to be more or less the same. In other words, I no longer think
that the change results from a 'change in priority of _XOPEN_SOURCE'. The
issue is simply
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
Right. My original complaint was only that --fetch is not as
orthogonal to --push (and an optionless set-url) as it could be. I
think the alternatives for going forward are basically:
1. Name it something besides --fetch (but
On 24/11/14 21:44, Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
I updated from cygwin 1.5 to cygwin 1.7 at the beginning of the year.
Since it is no longer supported, I don't think we need to worry about
version 1.5. When I said 'old installation' I meant my old
Calling basename on a argument that starts with a dash, like a login shell,
will result in an error. This patch adds '--' before the argument so that the
argument is interpreted properly.
---
git-sh-setup.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-sh-setup.sh
On Mon, Nov 24, 2014 at 09:26:22PM +0300, Роман Донченко wrote:
Yeah, I did realize that token is more restrictive than encoded-text, but I
didn't want to stray too far from the subject line of the patch. What I'll
probably do is split the patch into two, one for regex tweaking and one for
On 24/11/14 22:50, Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
...
Although I have not done an actual diff of the various cdef.h files, they
do appear to be more or less the same. In other words, I no longer think
that the change results from a 'change in priority
Jeff King p...@peff.net writes:
My complaint is that you have three possible options to provide: --push,
--fetch, or no option at all. And --fetch sometimes behaves like no
option, and sometimes not. Which is the confusing/non-orthogonal part.
I can understand that --fetch sounds a bit
On Mon, Nov 24, 2014 at 6:21 AM, Øystein Walle oys...@gmail.com wrote:
When a commit is amended a pre-commit hook that verifies the commit's
contents might not find what it's looking for if for example it looks at
the differences against HEAD when HEAD~1 might be more appropriate.
Inform the
Calling basename on a argument that starts with a dash, like a login shell,
will result in an error. This patch adds '--' before the argument so that the
argument is interpreted properly.
Signed-off-by: Dan Wyand danwy...@gmail.com
---
git-sh-setup.sh | 2 +-
1 file changed, 1 insertion(+), 1
On Monday 24 November 2014 17:54:57 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
I can understand that --fetch sounds a bit weird, what about this
natural translation:
git remote: set the URL (only the fetch one) for NAME to URL
git remote set-url
Hi, this is David Wu from Shanghai, China.
We are a printing company, we can print color box, corrugated box,
label, hang tag etc.
Please let me know if you need these.
I will send you the website then.
Best regards,
David Wu
--
To unsubscribe from this list: send the line unsubscribe git in
the
Hi, this is David Wu from Shanghai, China.
We are a printing company, we can print color box, corrugated box,
label, hang tag etc.
Please let me know if you need these.
I will send you the website then.
Best regards,
David Wu
--
To unsubscribe from this list: send the line unsubscribe git in
the
Stefan Beller sbel...@google.com writes:
This function behaves the same as string_list_insert, just the
starting indexes for searching, where to insert into the list is also
a parameter. So if you have knowledge on where to search for the string
to be inserted, you may have a speed up version
Dan Wyand danwy...@gmail.com writes:
Calling basename on a argument that starts with a dash, like a login shell,
will result in an error. This patch adds '--' before the argument so that the
argument is interpreted properly.
---
Makes sense.
Please sign-off your patch (see
On 11/21/2014 07:00 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I don't think that those iterations changed anything substantial that
overlaps with my version, but TBH it's such a pain in the ass working
with patches in email that I don't think I'll go to the
On Mon, Nov 24, 2014 at 4:07 PM, Richard Littauer
richard.litta...@gmail.com wrote:
I've been confused several times by the docs when running across
the word 'usually'. It is difficult to know before hand if it
means 'under normal conditions' or 'by default'. I've gone through
the
On Mon, Nov 24, 2014 at 4:25 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
This function behaves the same as string_list_insert, just the
starting indexes for searching, where to insert into the list is also
a parameter. So if you have knowledge on where
On Tue, Nov 25, 2014 at 1:14 AM, Nico Williams n...@cryptonector.com wrote:
Is there a plan for upgrading to a better hash function in the future?
(E.g., should it become an urgent need.)
What are the roadblocks to adoption of a replacement hash function?
Just documenting this would go a
Duy Nguyen wrote:
The biggest obstacle is the assumption of SHA-1 everywhere in the
source code (e.g. assume the object name always takes 20 bytes). Brian
started on cleaning that up [1] but I think it's stalled. Then we need
to deal with upgrade path for SHA-1 repos.
I think the biggest
Nobody is using this function any more, let's get rid of it.
Signed-off-by: Stefan Beller sbel...@google.com
---
string-list.c | 8 +---
string-list.h | 2 --
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/string-list.c b/string-list.c
index c5aa076..9584fa6 100644
---
On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder jrnie...@gmail.com wrote:
I think the biggest obstacle is the upgrade path. ;-)
In the worst case we can always treat new repos as a different VCS. So
people will need a migration from SHA-1 to the new format, just like
they migrate from SVN/CVS
On Mon, Nov 24, 2014 at 4:52 PM, Stefan Beller sbel...@google.com wrote:
No functional changes intended. This commit makes user of higher level
s/user/use/
and better documented functions of the string list API, so the code is
more understandable.
Note that also the required computational
That's not *as* painful, because you'd have the beautiful
fast-{import/export} tools in your new and old version control system.
But yeah, there might be better ways to do so.
On Mon, Nov 24, 2014 at 5:52 PM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder
No functional changes intended. This commit makes use of higher level
and better documented functions of the string list API, so the code is
more understandable.
Note that also the required computational amount should not change
in principal as we need to look up the item no matter if it is
On Mon, Nov 24, 2014 at 12:21:51PM +0100, Øystein Walle wrote:
This hook is invoked by 'git commit', and can be bypassed
-with `--no-verify` option. It takes no parameter, and is
+with `--no-verify` option. It takes one parameter which is amend if
+`--amend` was used when committing and
On Tue, Nov 25, 2014 at 08:52:58AM +0700, Duy Nguyen wrote:
On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder jrnie...@gmail.com wrote:
I think the biggest obstacle is the upgrade path. ;-)
In the worst case we can always treat new repos as a different VCS. So
people will need a migration
On Mon, Nov 24, 2014 at 09:18:52AM +0100, Springer, Stephan wrote:
I found bug in http-backend.c with config-flag http.receivepack You
describe in our documentation: This serves git send-pack clients,
allowing push. It is disabled by default for anonymous users, and
enabled by default for
On Mon, Nov 24, 2014 at 09:41:00AM -0800, Junio C Hamano wrote:
We actually do not have a reference to it anywhere. For now, this
should suffice.
Documentation/SubmittingPatches | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches
On Tue, Nov 25, 2014 at 12:27:31AM +0100, Peter Wu wrote:
On Monday 24 November 2014 17:54:57 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
I can understand that --fetch sounds a bit weird, what about this
natural translation:
git remote: set the
Jeff King p...@peff.net writes:
However, I think what removed the confusion for me in your --only=both
proposal was the presence of a both option, since it made it more
clear that is not what no-option means. So what about just --push,
--fetch, and --both?
I think that is the set that is
Jeff King p...@peff.net writes:
1. It is a bit more obvious when debugging or dumping arguments (e.g.,
via GIT_TRACE), especially if new options are added after the
first.
2. It makes it easier for a script to work on old and new versions of
git. It sees either amend or
On Mon, Nov 24, 2014 at 08:55:13PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
However, I think what removed the confusion for me in your --only=both
proposal was the presence of a both option, since it made it more
clear that is not what no-option means. So what about
On Mon, Nov 24, 2014 at 08:58:37PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
1. It is a bit more obvious when debugging or dumping arguments (e.g.,
via GIT_TRACE), especially if new options are added after the
first.
2. It makes it easier for a script
Hello Junio,
I returned static to git_etc_gitattributes return value, but now i
can't understand where to free 'system_wide'. As i understand
correctly attr.c has following API for querying attributes:
git_attr
git_check_attr
And as i see in code git_attr doesn't use git_attr_check, so now we
But if we still static const char* for git_etc_gitattributes and will
not free it in bootstrap_attr_stack there will no memory leak, just
tested it, so i'll remove free for it.
2014-11-25 12:45 GMT+06:00 Alexander Kuleshov kuleshovm...@gmail.com:
Hello Junio,
I returned static to
On 11/21/2014 05:44 PM, Junio C Hamano wrote:
On Fri, Nov 21, 2014 at 6:09 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Inserting items into a list in sorted order is O(N^2) whereas
appending them unsorted and then sorting the list all at once is
O(N lg N).
string_list_insert() also
On 11/22/2014 10:17 PM, Jonathan Nieder wrote:
Michael Haggerty wrote:
All of the callers have string_lists available already
Technically ref_transaction_commit doesn't, but that doesn't matter.
You're right. I'll correct this.
Suggested-by: Ronnie Sahlberg sahlb...@google.com
81 matches
Mail list logo
