On 10/23/2013 08:36 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> "git fetch" was being used with contrived refspecs to create tags and
>> remote-tracking branches in test repositories in preparation for the
>> actual tests. This is obscure and also makes one wonder whether this
>> i
Am 10/24/2013 7:25, schrieb Duy Nguyen:
> On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi
> wrote:
It is not clear to me how you envision to make it work.
>>>
>>> I don't have the source code.
>>
>> Now you do:
>> https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/reso
On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi wrote:
>>> It is not clear to me how you envision to make it work.
>>
>> I don't have the source code.
>
> Now you do:
> https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/resources/com/google/gerrit/server/tools/root/hooks/com
On Oct 23, 2013, at 8:07 PM, Duy Nguyen wrote:
> On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>>> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano wrote:
It would be just the matter of updating commit_tree_extended() in
commit.c to:
- de
On Wed, Oct 23, 2013 at 10:43:36PM +0200, Matthieu Moy wrote:
> That may be an option. In the case of "git add -u", it was a bit more
> complicated, since a badly used "git add" somehow looses data (not very
> serious, you may only loos the index). So, saying after the fact "oh, by
> the way, I me
On Wed, Oct 23, 2013 at 12:31 PM, Junio C Hamano wrote:
> Jed Brown writes:
>
>> Junio C Hamano writes:
>>
>>> Jed Brown writes:
>>>
Junio C Hamano writes:
> I suspect that it would be too late for 2.0 we want to do sometime
> early next year, though.
How would you manag
On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano wrote:
>>> It would be just the matter of updating commit_tree_extended() in
>>> commit.c to:
>>>
>>> - detect the need to add a new Change-Id: trailer;
>>>
>>> - c
The old code does not do boundary check so any paths longer than
PATH_MAX can cause buffer overflow. Replace it with strbuf to handle
paths of arbitrary length.
The OS may reject if the path is too long though. But in that case we
report the cause (e.g. name too long) and usually move on to checki
On Thu, Oct 24, 2013 at 12:52 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> The strcpy call in open_output_fd() implies that the output buffer
>> must be at least 25 chars long.
>
> Hmph, where does that 25 come from?
>
> [snipped]
Much better. Thanks.
--
Duy
--
To unsubscribe f
Am 19.10.2013 16:08, schrieb Philip Oakley:
> From: "Karsten Blees"
>> Am 15.10.2013 00:29, schrieb Felipe Contreras:
>>> tl;dr: everyone except Junio C Hamano and Drew Northup agrees; we
>>> should move
>>> away from the name "the index".
>>>
>>> It has been discussed many times in the past that
On Tue, Oct 22, 2013 at 08:21:48PM -0700, Shawn Pearce wrote:
> From my perspective, it is OK to defaulting to use 100-continue if the
> server supports Negotiate. If the user is stuck behind a broken proxy
> and can't authenticate, they can't authenticate. They can either set
> the variable to fal
On Wed, Oct 23, 2013 at 08:47:57AM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > Wouldn't a natural fix be to *always* use "Expect: 100-continue" when
> > and only when the probe_rpc() revealed a server supporting
> > GSS-Negotiate authentication?
>
> A stupid question. Is GSS-Neg
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
wor...@alum.mit.edu (Dale R. Worley) writes:
> It seems to me that the two sets of Git commands should be invokable
> under the same circumstances, that there is a design specification as
> to how Git can be invoked, and both implementations should match that.
As far as I know, the design for any
Jed Brown writes:
> Junio C Hamano writes:
>
>> Jed Brown writes:
>>
>>> Junio C Hamano writes:
I suspect that it would be too late for 2.0 we want to do sometime
early next year, though.
>>>
>>> How would you manage transition from the current behavior? Warning
>>> people to explic
> The pattern I use is to have this:
>
> /repository/.git
> with core.worktree = /working
> /working/...
>
> then
>
> cd /repository
> git add /working/x/y
> git ...
The point I'm trying to make is that it appears that all of the Git
command
Jed Brown writes:
> Junio C Hamano writes:
>
>> Jed Brown writes:
>>
>>> Junio C Hamano writes:
I suspect that it would be too late for 2.0 we want to do sometime
early next year, though.
>>>
>>> How would you manage transition from the current behavior? Warning
>>> people to explic
I have this situation and an accompanying sample repository
reproducing the issue:
https://gist.github.com/fj/7124501/raw/8d37058c1452379d0ae58bd87b0b9e0380bd80b2/gistfile1.txt
* I would like to rebase and delete a spurious ancestor merge commit
(bbd8966 in the example).
* When I do that, howeve
Junio C Hamano writes:
> Jed Brown writes:
>
>> Junio C Hamano writes:
>>> I suspect that it would be too late for 2.0 we want to do sometime
>>> early next year, though.
>>
>> How would you manage transition from the current behavior? Warning
>> people to explicitly use "." or ":/" during som
Jed Brown writes:
> Junio C Hamano writes:
>> I suspect that it would be too late for 2.0 we want to do sometime
>> early next year, though.
>
> How would you manage transition from the current behavior? Warning
> people to explicitly use "." or ":/" during some interim period sounds
> worse th
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
Up to this point the patches all look very sensible (modulo minor
nits I sent separately). Will come back to the rest of the topics
later.
Thanks.
> ---
> remote.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
>
Michael Haggerty writes:
> Rename "refs" -> "refspecs" and "ref_count" -> "refspec_count" to
> reduce confusion, because they describe an array of "struct refspec",
> as opposed to the "struct ref" objects that are also used in this
> function.
Good. In general, we'd prefer to name an array of
Michael Haggerty writes:
>> Subject: Re: [PATCH 04/15] api-remote.txt: correct section "struct refspect"
refspect???
> * Replace reference to function parse_ref_spec() with references to
> functions parse_fetch_refspec() and parse_push_refspec().
>
> * Correct description of src and dst: they
Michael Haggerty writes:
> "git fetch" was being used with contrived refspecs to create tags and
> remote-tracking branches in test repositories in preparation for the
> actual tests. This is obscure and also makes one wonder whether this
> is indeed just preparation or whether some side-effect
Junio C Hamano writes:
> I suspect that it would be too late for 2.0 we want to do sometime
> early next year, though.
How would you manage transition from the current behavior? Warning
people to explicitly use "." or ":/" during some interim period sounds
worse than just switching the default b
On Wed, Oct 23, 2013 at 11:09:27AM -0700, Junio C Hamano wrote:
> > This is not something you introduced, but while we are here, you may
> > want to use ce->namelen, which would be a little faster than treating it
> > as a string (especially for strbuf, as it can then know up front how big
> > the
Jeff King writes:
> On Wed, Oct 23, 2013 at 07:55:06PM +0700, Nguyen Thai Ngoc Duy wrote:
> ...
>> -memcpy(path, state->base_dir, len);
>> -strcpy(path + len, ce->name);
>> -len += ce_namelen(ce);
>> +strbuf_reset(&path_buf);
>> +strbuf_addf(&path_buf, "%.*s%s", state->base_di
Nguyễn Thái Ngọc Duy writes:
> The strcpy call in open_output_fd() implies that the output buffer
> must be at least 25 chars long.
Hmph, where does that 25 come from?
> And it's true. The only caller that
> can trigger that code is checkout-index, which has the buffer of
> PATH_MAX chars (and
On Wed, Oct 23, 2013 at 07:34:18PM +0200, Erik Faye-Lund wrote:
> >> - memcpy(path, state->base_dir, len);
> >> - strcpy(path + len, ce->name);
> >> - len += ce_namelen(ce);
> >> + strbuf_reset(&path_buf);
> >> + strbuf_addf(&path_buf, "%.*s%s", state->base_dir_len,
> >> state
On Wed, Oct 23, 2013 at 7:29 PM, Jeff King wrote:
> On Wed, Oct 23, 2013 at 07:55:06PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> The old code does not do boundary check so any paths longer than
>> PATH_MAX can cause buffer overflow. Replace it with strbuf to handle
>> paths of arbitrary length.
>
>
On Wed, Oct 23, 2013 at 07:55:06PM +0700, Nguyen Thai Ngoc Duy wrote:
> The old code does not do boundary check so any paths longer than
> PATH_MAX can cause buffer overflow. Replace it with strbuf to handle
> paths of arbitrary length.
I think this is a reasonable solution. If we have such a lon
Matthieu Moy writes:
> In summary: changing is painful. The case of "git add" was really bad,
> since the same command had different behavior depending on the options
> given, so it was clearly worth the pain. In the case of "git grep", the
> current behavior is not _that_ bad, so nobody bothered
Michael Haggerty writes:
> This is my proposed fix for the "local tag killer" problem that I
> reported recently [1].
>
> There are three main things changed by this patch series:
> ...
Haven't looked at any of the 1-15 messages, but the basic design to
demote "--tags" from being an explicit "re
Piotr Krukowiecki writes:
> I think there were discussion about how there are several git commands
> which do not search in whole tree by default and that it's going to be
> changed. I think "add" is one of such commands. Is 'grep' left
> unchanged?
In summary: changing is painful. The case of "
Jens Lindström writes:
> On Tue, Oct 22, 2013 at 8:42 PM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>
>>> Life would have been simpler if fd[1] was _always_ closed by
>>> send_pack(), like in c20181e (start_command(), if .in/.out > 0, closes
>>> file descriptors, not the callers - 2008-02-21)
Duy Nguyen writes:
> On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano wrote:
>> It would be just the matter of updating commit_tree_extended() in
>> commit.c to:
>>
>> - detect the need to add a new Change-Id: trailer;
>>
>> - call hash_sha1_file() on the commit object buffer (assuming that
>>
Reorder function definitions to remove the need for forward
declarations.
Signed-off-by: Michael Haggerty
---
builtin/remote.c | 159 +++
1 file changed, 78 insertions(+), 81 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index
Rename "refs" -> "refspecs" and "ref_count" -> "refspec_count" to
reduce confusion, because they describe an array of "struct refspec",
as opposed to the "struct ref" objects that are also used in this
function.
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 12 ++--
1 file change
Reorder function definitions to avoid the need for a forward
declaration of function find_non_local_tags().
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 198 +++-
1 file changed, 97 insertions(+), 101 deletions(-)
diff --git a/builtin
Previously, fetch's "--tags" option was considered equivalent to
specifying the refspec "refs/tags/*:refs/tags/*" on the command line;
in particular, it caused the remote..refspec configuration to be
ignored.
But it is not very useful to fetch tags without also fetching other
references, whereas i
If --no-prune is passed to one of the following commands:
git fetch --all
git fetch --multiple
git fetch --recurse-submodules
git remote update
then it must also be passed to the "fetch" subprocesses that those
commands use to do their work. Otherwise there might be a fetch.prune
The old behavior of "fetch --prune" was to prune whatever was being
fetched. In particular, "fetch --prune --tags" caused tags not only
to be fetched, but also to be pruned. This is inappropriate because
there is only one tags namespace that is shared among the local
repository and all remotes.
This is my proposed fix for the "local tag killer" problem that I
reported recently [1].
There are three main things changed by this patch series:
1. "git fetch --tags" causes tags to be fetched *in addition to* any
other refspecs that are configured for the remote, rather than
*instead of*
"git fetch --prune --tags" is currently interpreted as follows:
* "--tags" is equivalent to specifying a refspec
"refs/tags/*:refs/tags/*", and supersedes any default refspecs
configured via remote.$REMOTE.fetch.
* "--prune" only operates on the refspecs being fetched.
Therefore, "git fetch
* Replace reference to function parse_ref_spec() with references to
functions parse_fetch_refspec() and parse_push_refspec().
* Correct description of src and dst: they *do* include the '*'
characters.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-remote.txt | 20 +
* Use a dedicated variable, ref, for referring to the current item
rather than using the ref_map pointer for this purpose.
* Use a (struct ref **) as iteration variable to avoid having to keep
track of prev and next in addition to the pointer to the current
item.
Signed-off-by: Michael Hagg
Guten Tag ,
Ich bin Mr. Gabriel Brock Leiter Rechnungswesen Revision der Credit Suisse
Bank North West London, hier in England.
Ich schreibe Ihnen aus meinem Büro , die von einer großen immensen Nutzen
für beide von uns sein wird. In meiner Abteilung , ein Filialleiter
(Greater London region) ,
On Wed, Oct 23, 2013 at 5:44 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>>> def c_style_unescape(string):
>>> if string[0] == string[-1] == '"':
>>> return string.decode('string-escape')[1:-1]
>>> return string
>>>
>>> It's in git-remote-bzr.py.
>>
>> Yeah, that's certa
Signed-off-by: Michael Haggerty
---
remote.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/remote.c b/remote.c
index 5ade07f..ff5b62a 100644
--- a/remote.c
+++ b/remote.c
@@ -829,6 +829,8 @@ static int query_refspecs(struct refspec *refs, int
ref_count, struct refspec *
Use struct argv_array for calling the "git fetch" subprocesses.
Signed-off-by: Michael Haggerty
---
builtin/remote.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index ecedd96..bffe2f9 100644
--- a/bui
"git fetch" was being used with contrived refspecs to create tags and
remote-tracking branches in test repositories in preparation for the
actual tests. This is obscure and also makes one wonder whether this
is indeed just preparation or whether some side-effect of "git fetch"
is being tested.
So
The old code called string_list_lookup(), and if that failed called
string_list_insert(), thus doing the bisection search through the
string list twice in the latter code path.
Instead, just call string_list_insert() right away. If an entry for
that peer reference name already existed, then its u
Signed-off-by: Michael Haggerty
---
remote.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/remote.h b/remote.h
index 131130a..40293c0 100644
--- a/remote.h
+++ b/remote.h
@@ -149,7 +149,14 @@ int resolve_remote_symref(struct ref *ref, struct ref
*list);
int ref_new
Fix an apparent copy-paste error: A few lines earlier, a tag
"refs/tags/sometag" is created. Check for the (non-)existence of that
tag, not "somebranch", which is otherwise never mentioned in the
script.
Signed-off-by: Michael Haggerty
---
t/t5510-fetch.sh | 2 +-
1 file changed, 1 insertion(+)
Jonathan Nieder writes:
> Wouldn't a natural fix be to *always* use "Expect: 100-continue" when
> and only when the probe_rpc() revealed a server supporting
> GSS-Negotiate authentication?
A stupid question. Is GSS-Negotiate the only special case?
--
To unsubscribe from this list: send the line
Antoine Pelisse writes:
>> def c_style_unescape(string):
>> if string[0] == string[-1] == '"':
>> return string.decode('string-escape')[1:-1]
>> return string
>>
>> It's in git-remote-bzr.py.
>
> Yeah, that's certainly better,
>
> Thanks,
OK, so an amended one will look like this
On Wed, Oct 23, 2013 at 3:04 PM, Duy Nguyen wrote:
> On Wed, Oct 23, 2013 at 7:58 PM, Antoine Pelisse wrote:
>>> diff --git a/entry.c b/entry.c
>>> index acc892f..d955af5 100644
>>> --- a/entry.c
>>> +++ b/entry.c
>>> @@ -237,16 +237,18 @@ static int check_path(const char *path, int len,
>>> str
On Wed, Oct 23, 2013 at 7:58 PM, Antoine Pelisse wrote:
>> diff --git a/entry.c b/entry.c
>> index acc892f..d955af5 100644
>> --- a/entry.c
>> +++ b/entry.c
>> @@ -237,16 +237,18 @@ static int check_path(const char *path, int len,
>> struct stat *st, int skiplen)
>> int checkout_entry(struct cac
On Tue, Oct 22, 2013 at 8:36 PM, Jens Lindström wrote:
> From: Jens Lindstrom
>
> In send_pack(), clear the fd passed to pack_objects() by setting
> it to -1, since pack_objects() closes the fd (via a call to
> run_command()). Likewise, in get_pack(), clear the fd passed to
> run_command().
>
>
On Wed, Oct 23, 2013 at 2:55 PM, Nguyễn Thái Ngọc Duy wrote:
> The old code does not do boundary check so any paths longer than
> PATH_MAX can cause buffer overflow. Replace it with strbuf to handle
> paths of arbitrary length.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> To get this topic go
On Tue, Oct 22, 2013 at 2:02 AM, Johannes Sixt wrote:
>> (or maybe at higher level to skip checking out those paths).
>
> More like this, yeah.
The good thing is we do not stop checking out if one entry fails. But
due to the lack of worktree entries, one may accidentally remove files
in new commi
The strcpy call in open_output_fd() implies that the output buffer
must be at least 25 chars long. And it's true. The only caller that
can trigger that code is checkout-index, which has the buffer of
PATH_MAX chars (and any systems that have PATH_MAX shorter than 25
chars are just insane).
But in
The old code does not do boundary check so any paths longer than
PATH_MAX can cause buffer overflow. Replace it with strbuf to handle
paths of arbitrary length.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
To get this topic going again. These two patches kill PATH_MAX in
entry.c and builtin/checkout
On Wed, Oct 23, 2013 at 2:52 PM, Perry Hutchison wrote:
> At least in version 1.7.0.4, it seems git does not like being run
> from outside the repository, even if the file(s) being operated
> on are inside the repository, unless it is given a pointer to the
> repository via the --git-dir= option o
On Wed, Oct 23, 2013 at 2:45 AM, Felipe Contreras
wrote:
> On Tue, Oct 22, 2013 at 3:49 PM, Antoine Pelisse wrote:
>
>> It is true that I have expected "valid output" from git-fast-export.
>> And I don't have in mind any easy solution to detect that the output
>> is broken, yet still accepted as
At least in version 1.7.0.4, it seems git does not like being run
from outside the repository, even if the file(s) being operated
on are inside the repository, unless it is given a pointer to the
repository via the --git-dir= option or the GIT_DIR enironment
variable.
For example, suppose /foo/bar
Hi,
it would be nice if grep searched not only in current directory and
subdirectories, but in whole tree.
I know I can use ":/" as a pathspec, but since most git commands work
tree, I got used to this and forgot that grep is different.
It's easy to make a mistake and believe that your code does
On Tue, Oct 22, 2013 at 8:42 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>> Life would have been simpler if fd[1] was _always_ closed by
>> send_pack(), like in c20181e (start_command(), if .in/.out > 0, closes
>> file descriptors, not the callers - 2008-02-21).
>
> Yeah, that was also my fir
68 matches
Mail list logo
