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
>> Signed-off-by: Mich
On 11/21/2014 05:44 PM, Junio C Hamano wrote:
> On Fri, Nov 21, 2014 at 6:09 AM, Michael Haggerty
> 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 removes dup
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 :
> Hello Junio,
>
> I returned static to git_etc_gitattributes return valu
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
h
On Mon, Nov 24, 2014 at 08:58:37PM -0800, Junio C Hamano wrote:
> Jeff King 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 t
On Mon, Nov 24, 2014 at 08:55:13PM -0800, Junio C Hamano wrote:
> Jeff King 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
Jeff King 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 "noamen
Jeff King 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 most
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 re
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 b
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
On Tue, Nov 25, 2014 at 08:52:58AM +0700, Duy Nguyen wrote:
> On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder 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
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 a
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 alread
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 wrote:
> On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder wrote:
>> I think
On Mon, Nov 24, 2014 at 4:52 PM, Stefan Beller 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 amount should n
On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder 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 to Git. Painful but
Nobody is using this function any more, let's get rid of it.
Signed-off-by: Stefan Beller
---
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
--- a/string-list.c
+++ b/stri
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
On Tue, Nov 25, 2014 at 1:14 AM, Nico Williams 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 long way towards mak
On Mon, Nov 24, 2014 at 4:25 PM, Junio C Hamano wrote:
> Stefan Beller 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
>>
On Mon, Nov 24, 2014 at 4:07 PM, Richard Littauer
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 Documentation to identify specific
On 11/21/2014 07:00 PM, Junio C Hamano wrote:
> Michael Haggerty 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 effort of
>> chec
Dan Wyand 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 Documentation/SubmittingPatches)
Stefan Beller 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 of string_list
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
th
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
th
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 rem
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
---
git-sh-setup.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
On Mon, Nov 24, 2014 at 6:21 AM, Øystein Walle 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 commit hook th
Jeff King 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 weird, what
On 24/11/14 22:50, Junio C Hamano wrote:
> Ramsay Jones 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'
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 b/git-
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 21:44, Junio C Hamano wrote:
> Ramsay Jones 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 i
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
Ramsay Jones 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 that in the old header t
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.
> >
>
On 23/11/14 23:15, Ramsay Jones wrote:
> On 23/11/14 18:53, Junio C Hamano wrote:
>> Ramsay Jones 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'
[-Wimplicit-func
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 incompatibiliti
On Monday 24 November 2014 14:04:07 Junio C Hamano wrote:
> Peter Wu 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 w
Peter Wu 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
this?
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 alrea
Stefan Beller 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 majord...@vger.kernel.org
More maj
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(
Ramsay Jones 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 was converted from
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
>>
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 writes:
>>>
On 23/11/14 14:16, Torsten Bögershausen wrote:
> gcc under cygwin reports several warnings like this:
> warning: implicit
Anything holding this back?
On Thu, Nov 20, 2014 at 4:38 PM, Stefan Beller wrote:
> From: Ronnie Sahlberg
>
> 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 thing if we write a sha1 ref differen
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 thi
Signed-off-by: Stefan Beller
---
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 string_list
*list, int
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 alrea
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 'us
Alex Kuleshov 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;
>>
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 s
Alex Kuleshov writes:
> Junio C Hamano @ 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 = read_attr_from_file(etc_attributes
Junio C Hamano @ 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 returned
>
> 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 >a
0xAX 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
> ---
> -static const char *git_etc_gitattributes(v
> 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?
>
> 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 clas
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 a/bin/
Jeff King писал в своём письме 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 all-Cyrillic string in
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 uns
Junio C Hamano писал в своём письме Mon, 24 Nov 2014
10:27:51 +0300:
On Sun, Nov 23, 2014 at 3:50 PM, Роман Донченко
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 th
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 #def
Jeff King writes:
> On Sun, Nov 23, 2014 at 10:10:47AM -0800, Junio C Hamano wrote:
>
>> Jeff King 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 inconsistent s
>
> 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
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
> > withou
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 w
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 characte
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
---
attr.c| 8 +++---
builtin/config.c | 73 +
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 syst
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
---
attr.c| 8 +++---
builtin/config.c | 73
On Mon, Nov 24, 2014 at 5:15 PM, Michael J Gruber
wrote:
> Duy Nguyen schrieb am 24.11.2014 um 02:23:
>> On Tue, Nov 18, 2014 at 4:26 AM, Jeff King 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 ha
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.
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)
>>> +'
>>
>>
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 subj
Duy Nguyen schrieb am 24.11.2014 um 02:23:
> On Tue, Nov 18, 2014 at 4:26 AM, Jeff King 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 data f
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 disable
Junio C Hamano @ 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
> wrote:
>>
>> Junio C Hamano:
>>
>>>Fixing these callers are done as separate patches, that can be
>>>applied either before or after t
81 matches
Mail list logo
