It used to be that if "--all", "--depth", and also explicit references
were sought, then the explicit references were not handled correctly
in filter_refs() because the "--all --depth" code took precedence over
the explicit reference handling, and the explicit references were
never noted as having
Set the final value at initialization rather than initializing it then
sometimes changing it.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 3d3
This simplifies the logic without changing the behavior.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 056ccb8..fb2a423 100644
--- a/builtin/fetch-pack.c
+++ b/b
This fixes a test in t5500.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 2 +-
t/t5500-fetch-pack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index fb2a423..3d388b5 100644
--- a/builtin/fetch-pack.c
+++ b/bu
Instead of temporarily storing matched refs to temporary array
"return_refs", simply append them to newlist as we go. This changes
the order of references in newlist to strictly sorted if "--all" and
"--depth" and named references are all specified, but that usage is
broken anyway (see the last tw
Remove any references that are available from the remote from the
sought list (rather than overwriting their names with NUL characters,
as previously). Mark matching entries by writing a non-NULL pointer
to string_list_item::util during the iteration, then use
filter_string_list() later to filter
fetch_pack() removes duplicates from the "sought" list, thereby
shrinking the list. But previously, the caller was not informed about
the shrinkage. This would cause a spurious error message to be
emitted by cmd_fetch_pack() if "git fetch-pack" is called with
duplicate refnames.
Instead, remove
Instead of juggling (sometimes called
), pass around the list of references to be sought in
a single string_list variable called "sought". Future commits will
make more use of string_list functionality.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 88 +++--
Avoid confusion with the non-static function of the same name from
fetch-pack.h.
Signed-off-by: Michael Haggerty
---
http-walker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-walker.c b/http-walker.c
index 51a906e..1516c5e 100644
--- a/http-walker.c
+++ b/http-wa
Simplify flow within loop: first decide whether to keep the reference,
then keep/free it. This makes it clearer that each ref has exactly
two possible destinies, and removes duplication of the code for
appending the reference to the linked list.
Signed-off-by: Michael Haggerty
---
builtin/fetch
Once a match has been found at sought_pos, the entry is zeroed and no
future attempts will match that entry. So increment sought_pos to
avoid checking against the zeroed-out entry during the next iteration.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 2 +-
1 file changed, 1 inser
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 8
fetch-pack.h | 12 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index fdda36f..30990c0 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetc
Document some bugs in "git fetch-pack":
1. If "git fetch-pack" is called with "--all", "--depth", and an
explicit existing non-tag reference to fetch, then it falsely reports
that the reference was not found, even though it was fetched
correctly.
2. If "git fetch-pack" is called with "--all", "--
If "git fetch-pack" is called with reference names that do not exist
on the remote, then it should emit an error message
error: no such remote ref refs/heads/xyzzy
This is currently broken if *only* missing references are passed to
"git fetch-pack".
Signed-off-by: Michael Haggerty
---
t/t5
This patch series depends on the "Add some string_list-related
functions" series that I just submitted.
This series is a significant rewrite of v2 based on the realization
that the pair that is passed around in these
functions is better expressed as a string_list. I hope you will find
that this
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 8
string-list.c | 20 +++
string-list.h | 8
t/t0063-string-list.sh | 30 +++
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 8
string-list.c | 17 +
string-list.h | 9 +
3 files changed, 34 insertions(+)
diff --git a/Documentation/technical/a
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 4
string-list.c | 17 +
string-list.h | 5 +
3 files changed, 26 insertions(+)
diff --git a/Documentation/technical/api-strin
Split a string into a string_list on a separator character.
This is similar to the strbuf_split_*() functions except that it works
with the more powerful string_list interface. If strdup_strings is
false, it reuses the memory from the input string (thereby needing no
string memory allocations, th
This patch series adds a few functions to the string_list API. They
will be used in two upcoming patch series. Unfortunately, both of the
series (which are otherwise logically independent) need the same
function; therefore, I am submitting these string-list enhancements as
a separate series on wh
Junio C Hamano writes:
> (4) if it only runs once at the very beginning of the test and sets
> a variable that is named prominently clear what it means and lives
> throughout the test, then we do not even have to say "hopefully" and
> appear lazy and loose to the readers of the test who wonders w
I've applied these two, on top of Paul's master branch at
git://ozlabs.org/~paulus/gitk.git
and tentatively queued in 'pu', but I would prefer to see it
eyeballed by and queued in his tree first.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
Michael Haggerty writes:
> On 09/07/2012 01:09 AM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> Signed-off-by: Michael Haggerty
>>> ---
>>
>> I think I asked why this matters (iow, why it is the right thing to
>> do to reject an empty string, instead of treating it as "the current
Michael Haggerty writes:
> The possibility is obvious. Are you advocating it?
>
> I considered that approach, but came to the opinion that it would be
> overkill that would only complicate the code for no real advantage,
> given that (1) I picked a name that is pretty implausible for an
> existi
On 09/07/2012 01:09 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Signed-off-by: Michael Haggerty
>> ---
>
> I think I asked why this matters (iow, why it is the right thing to
> do to reject an empty string, instead of treating it as "the current
> directory") in the previous round
Will queue (together with the latest MKDIR one). Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The built-in "binary" attribute macro expands to "-diff -text", so
that textual diff is not produced, and the contents will not go
through any CR/LF conversion ever. During a merge, it should also
choose the "binary" low-level merge driver, but it didn't.
Make it expand to "-diff -merge -text".
The (discouraged) -Xours/-Xtheirs modes of merge are supposed to
give a quick and dirty way to come up with a random mixture of
cleanly merged parts and punted conflict resolution to take contents
from one side in conflicting parts. These options however were only
passed down to the low level merg
The part that grants Stephen's wish is unchanged from the earlier
"perhaps like this" patch, but this time with a bit of documentation
and test.
A more important change between the two actually is [PATCH 2/2].
When a "binary" synthetic attribute is given to a path, we used to
(1) disable textual d
On 09/07/2012 01:08 AM, Junio C Hamano wrote:
> mhag...@alum.mit.edu writes:
>
>> From: Michael Haggerty
>>
>> There is currently a bug: if passed an absolute top-level path that
>> doesn't exist (e.g., "/foo") it incorrectly interprets the path as a
>> relative path (e.g., returns "$(pwd)/foo").
"Philip Oakley" writes:
> Having said that, it would therefore be better to point folk at gitcli
> in a few more places, not just the 'see also' line at the very end of
> the general 'git' page, and buried within rev-parse.
Didn't we update the very early part of git(1) for exactly for that
reas
From: "Junio C Hamano"
Sent: Friday, September 07, 2012 9:49 PM
Junio C Hamano writes:
But that is not what is happening at all. What goes on is far
simpler than that.
- the shell sees '*', matches it against working tree files, to
obtain "f1" and "f2";
- the shell tells "git" to "che
Name the 'tagcontents' variable similarly to the rest of the
variables cleared in the changedrefs() function.
This makes the naming consistent and provides a hint that it
should be cleared when reloading gitk's cache.
Suggested-by: Junio C Hamano
Signed-off-by: David Aguilar
---
Follow-up to '
On Saturday 2012-09-08 20:59, Junio C Hamano wrote:
>> diff --git a/daemon.c b/daemon.c
>> index 4602b46..eaf08c2 100644
>> --- a/daemon.c
>> +++ b/daemon.c
>> @@ -1,3 +1,4 @@
>> +#include
>> #include "cache.h"
>> #include "pkt-line.h"
>> #include "exec_cmd.h"
>
>Platform agnostic parts of the
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Saturday, September 08, 2012 9:04 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] daemon: restore getpeername(0,...) use
>
> "Joachim Schmitz" writes:
>
> >> + setenv("REMOTE_PORT", portbuf, true);
> >
> > setenv
On Saturday 2012-09-08 20:57, Junio C Hamano wrote:
>Please don't throw a pull request for a patch whose worth hasn't
>been justified in a discussion on the list. Thanks.
Let me postulate that people like to get cover letters with the
git:// URL so they can fetch+look at it, a diffstat and short
"Joachim Schmitz" writes:
>> + setenv("REMOTE_PORT", portbuf, true);
>
> setenv() is not a function available on all plattfomrs.
Please do some homework before adding irrelevant noise. At the
minimum, run "git grep" to see if we already use it in other places,
and investigate why we can use it
Tag contents, once read, are forever cached in memory.
This makes gitk unable to notice when tag contents change.
Allow users to cause a reload of the tag contents by using
the "File->Reread references" action.
Reported-by: Tim McCormack
Suggested-by: Junio C Hamano
Signed-off-by: David Aguilar
Jan Engelhardt writes:
> This reverts f9c87be6b42dd0f8b31a4bb8c6a44326879fdd1a, in a sense,
> because that commit broke logging of "Connection from ..." when
> git-daemon is run under xinetd.
>
> This patch here computes the text representation of the peer and then
> copies that to environment va
Please don't throw a pull request for a patch whose worth hasn't
been justified in a discussion on the list. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-inf
Angelo Borsotti writes:
> It makes quite clear that the command accepts wildcards
> (not expanded by the shell), which was is not clear in the current
> man page (although one could imagine that could also be a
> wildcard).
>
> P.S. In the man page there is also a
>
> "*git checkout* [-p|--
With the git.git repository:
$ git show abcd
error: short SHA1 abcd is ambiguous.
error: short SHA1 abcd is ambiguous.
fatal: ambiguous argument 'abcd': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
The "is ambiguous" message shouldn't be sh
Jan Engelhardt wrote:
This reverts f9c87be6b42dd0f8b31a4bb8c6a44326879fdd1a, in a sense,
because that commit broke logging of "Connection from ..." when
git-daemon is run under xinetd.
This patch here computes the text representation of the peer and then
copies that to environment variables such
The following changes since commit 0ce986446163b37c7f663ce7a408e7f94c31ba63:
The fourth batch for 1.8.0 (2012-09-07 11:25:22 -0700)
are available in the git repository at:
git://git.inai.de/git master
for you to fetch changes up to 864633738f6432574402afc43b6bd83c83fc8916:
daemon: resto
This reverts f9c87be6b42dd0f8b31a4bb8c6a44326879fdd1a, in a sense,
because that commit broke logging of "Connection from ..." when
git-daemon is run under xinetd.
This patch here computes the text representation of the peer and then
copies that to environment variables such that the code in execut
Signed-off-by: Joachim Schmitz
---
Makefile | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Makefile b/Makefile
index 66e8216..21b4816 100644
--- a/Makefile
+++ b/Makefile
@@ -90,6 +90,8 @@ all::
#
# Define NO_MKDTEMP if you don't have mkdtemp in the C library.
#
+# Define MKDIR_WO_TR
HP NonStop (currently) doesn't have setitimer().
As setitimer() is only used in cases of perceived latency and it doesn't affect
correctness, it gets disabled entirely if NO_SETITIMER is set.
HP NonStop does provide struct itimerval, but other platforms may not, so this
is taken care of in this com
On Sat, Sep 8, 2012 at 12:14 AM, Junio C Hamano wrote:
> Michael J Gruber writes:
>>> Documentation/git-log.txt | 6 ++
>>> Documentation/rev-list-options.txt | 3 ++-
>>> 2 tập tin đã bị thay đổi, 4 được thêm vào(+), 5 bị xóa(-)
>>
>> That is one reason why "core.local=C" (repo spe
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
> Sent: Friday, September 07, 2012 11:55 AM
> To: 'Junio C Hamano'
> Cc: 'git@vger.kernel.org'
> Subject: RE: [PATCH v3] Support for setitimer() on platforms lacking it
>
> HP NonStop (currently) doesn't have setitimer(). The previous attemp
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
> Sent: Friday, September 07, 2012 8:28 PM
> To: 'Junio C Hamano'
> Cc: 'git@vger.kernel.org'
> Subject: RE: [PATCH] Document MKDIR_WO_TRAILING_SLASH in Makefile
>
>
>
> > -Original Message-
> > From: Junio C Hamano [mailto:gits...
Junio C Hamano writes:
> Robin Stocker writes:
>
> > Junio C Hamano writes:
> >> Robin Stocker writes:
> >>
> >> > if (opts->record_origin) {
> >> > + /* Some implementations don't terminate message with final \n,
> >> > so
> >> > add it */
> >> > + if (msg.message[strlen(msg.me
> From: Erik Faye-Lund [mailto:kusmab...@gmail.com]
> Sent: Saturday, September 08, 2012 1:32 PM
> To: Joachim Schmitz
> Cc: Junio C Hamano; git@vger.kernel.org
> Subject: Re: [PATCH v4 4/4] make poll() work on platforms that can't recv()
> on a non-socket
>
> On Fri, Sep 7, 2012 at 5:43 PM, Joac
On Fri, Sep 7, 2012 at 5:43 PM, Joachim Schmitz wrote:
> This way it gets added to gnulib too.
>
> Signed-off-by: Joachim Schmitz
> ---
> compat/poll/poll.c | 5 +
> 1 file changed, 4 insertions(+)
>
> diff --git a/compat/poll/poll.c b/compat/poll/poll.c
> index e4b8319..10a204e 100644
> ---
On 03.09.12 00:59, Robin Rosenberg wrote:
> Torsten Bögershausen skrev 2012-09-01 08.11:> Allow path names to be encoded
> in UTF-8 in the repository
>> and checkout out as e.g. ISO-8859-1 in the working tree.
>
> Ack for attempting this.
>
> Did it myself if 2007, but times weren't ripe then, I
54 matches
Mail list logo
