On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano gits...@pobox.com 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
a commit object
On Tue, Oct 22, 2013 at 8:42 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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).
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
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
On Wed, Oct 23, 2013 at 2:45 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Oct 22, 2013 at 3:49 PM, Antoine Pelisse apeli...@gmail.com 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
On Wed, Oct 23, 2013 at 2:52 PM, Perry Hutchison per...@pluto.rain.com 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
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 pclo...@gmail.com
---
To get this topic going again. These two patches kill PATH_MAX in
entry.c
On Tue, Oct 22, 2013 at 2:02 AM, Johannes Sixt j...@kdbg.org 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
On Wed, Oct 23, 2013 at 2:55 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com 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 pclo...@gmail.com
On Wed, Oct 23, 2013 at 7:58 PM, Antoine Pelisse apeli...@gmail.com 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
On Wed, Oct 23, 2013 at 3:04 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Oct 23, 2013 at 7:58 PM, Antoine Pelisse apeli...@gmail.com 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
Antoine Pelisse apeli...@gmail.com 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
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 mhag...@alum.mit.edu
---
t/t5510-fetch.sh | 2 +-
1 file
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
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
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
Use struct argv_array for calling the git fetch subprocesses.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
On Wed, Oct 23, 2013 at 5:44 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com 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,
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) ,
* 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
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 --prune
* 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 mhag...@alum.mit.edu
---
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*.
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.
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 mhag...@alum.mit.edu
---
builtin/fetch.c | 12 ++--
1 file
Reorder function definitions to avoid the need for a forward
declaration of function find_non_local_tags().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch.c | 198 +++-
1 file changed, 97 insertions(+), 101 deletions(-)
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.name.refspec configuration to be
ignored.
But it is not very useful to fetch tags without also fetching other
references, whereas
Reorder function definitions to remove the need for forward
declarations.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 159 +++
1 file changed, 78 insertions(+), 81 deletions(-)
diff --git a/builtin/remote.c
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
Duy Nguyen pclo...@gmail.com writes:
On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano gits...@pobox.com 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
Jens Lindström j...@opera.com writes:
On Tue, Oct 22, 2013 at 8:42 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
Piotr Krukowiecki piotr.krukowie...@gmail.com 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
Michael Haggerty mhag...@alum.mit.edu 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
Matthieu Moy matthieu@grenoble-inp.fr 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_
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 long
On Wed, Oct 23, 2013 at 7:29 PM, Jeff King p...@peff.net 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
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-base_dir, ce-name);
+
Jeff King p...@peff.net 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,
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 size
Junio C Hamano gits...@pobox.com 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
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
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
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com writes:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com 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
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,
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com 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
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
commands
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com 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
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
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
On Wed, Oct 23, 2013 at 08:47:57AM -0700, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
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 false,
Am 19.10.2013 16:08, schrieb Philip Oakley:
From: Karsten Blees karsten.bl...@gmail.com
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
On Thu, Oct 24, 2013 at 12:52 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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.
--
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
On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano gits...@pobox.com wrote:
It would be just the matter of updating commit_tree_extended() in
commit.c to:
- detect the need to add a
On Wed, Oct 23, 2013 at 12:31 PM, Junio C Hamano gits...@pobox.com wrote:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
Jed Brown j...@59a2.org writes:
Junio C Hamano gits...@pobox.com writes:
I suspect that it would be too late for 2.0 we want to do sometime
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 messed up
On Oct 23, 2013, at 8:07 PM, Duy Nguyen wrote:
On Wed, Oct 23, 2013 at 11:00 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Wed, Oct 23, 2013 at 2:50 AM, Junio C Hamano gits...@pobox.com wrote:
It would be just the matter of updating
On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi nas...@codeaurora.org wrote:
It is not clear to me how you envision to make it work.
I don't have the source code.
Now you do:
64 matches
Mail list logo
