* [PATCH 2/3] show_ref(): remove unused "flag" and "cb_data" arguments
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
The function is not used as a callback, so it doesn't need these
arguments. Also change its return type to void.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
I suppose, though I didn't verify, that the old function signature was
a vestige of its earlier having been used as a callback function. But
it doesn't really matter; the point is that the extra arguments are
currently not needed.
builtin/receive-pack.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 08df17e..65d129c 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -115,7 +115,7 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return git_default_config(var, value, cb);
}
-static int show_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static void show_ref(const char *path, const unsigned char *sha1)
{
if (sent_capabilities)
packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
@@ -125,10 +125,9 @@ static int show_ref(const char *path, const unsigned char *sha1, int flag, void
" report-status delete-refs side-band-64k",
prefer_ofs_delta ? " ofs-delta" : "");
sent_capabilities = 1;
- return 0;
}
-static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, void *unused)
{
path = strip_namespace(path);
/*
@@ -141,7 +140,8 @@ static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, vo
*/
if (!path)
path = ".have";
- return show_ref(path, sha1, flag, cb_data);
+ show_ref(path, sha1);
+ return 0;
}
static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
@@ -163,7 +163,7 @@ static void write_head_info(void)
sha1_array_clear(&sa);
for_each_ref(show_ref_cb, NULL);
if (!sent_capabilities)
- show_ref("capabilities^{}", null_sha1, 0, NULL);
+ show_ref("capabilities^{}", null_sha1);
clear_extra_refs();
/* EOF */
--
1.7.8.2
^ permalink raw reply related
* [PATCH 1/3] receive-pack: move more work into write_head_info()
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Move some more code from the calling site into write_head_info(), and
inline add_alternate_refs() there. (Some more simplification is
coming, and it is easier if all this code is in the same place.)
Move some helper functions to avoid the need for forward declarations.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/receive-pack.c | 42 ++++++++++++++++++------------------------
1 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index d2dcb7e..08df17e 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -144,12 +144,30 @@ static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, vo
return show_ref(path, sha1, flag, cb_data);
}
+static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
+{
+ add_extra_ref(".have", sha1, 0);
+}
+
+static void collect_one_alternate_ref(const struct ref *ref, void *data)
+{
+ struct sha1_array *sa = data;
+ sha1_array_append(sa, ref->old_sha1);
+}
+
static void write_head_info(void)
{
+ struct sha1_array sa = SHA1_ARRAY_INIT;
+ for_each_alternate_ref(collect_one_alternate_ref, &sa);
+ sha1_array_for_each_unique(&sa, add_one_alternate_sha1, NULL);
+ sha1_array_clear(&sa);
for_each_ref(show_ref_cb, NULL);
if (!sent_capabilities)
show_ref("capabilities^{}", null_sha1, 0, NULL);
+ clear_extra_refs();
+ /* EOF */
+ packet_flush(1);
}
struct command {
@@ -869,25 +887,6 @@ static int delete_only(struct command *commands)
return 1;
}
-static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
-{
- add_extra_ref(".have", sha1, 0);
-}
-
-static void collect_one_alternate_ref(const struct ref *ref, void *data)
-{
- struct sha1_array *sa = data;
- sha1_array_append(sa, ref->old_sha1);
-}
-
-static void add_alternate_refs(void)
-{
- struct sha1_array sa = SHA1_ARRAY_INIT;
- for_each_alternate_ref(collect_one_alternate_ref, &sa);
- sha1_array_for_each_unique(&sa, add_one_alternate_sha1, NULL);
- sha1_array_clear(&sa);
-}
-
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
int advertise_refs = 0;
@@ -937,12 +936,7 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
unpack_limit = receive_unpack_limit;
if (advertise_refs || !stateless_rpc) {
- add_alternate_refs();
write_head_info();
- clear_extra_refs();
-
- /* EOF */
- packet_flush(1);
}
if (advertise_refs)
return 0;
--
1.7.8.2
^ permalink raw reply related
* [PATCH 3/3] write_head_info(): handle "extra refs" locally
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
The old code basically did:
generate array of SHA1s for alternate refs
for each unique SHA1 in array:
add_extra_ref(".have", sha1)
for each ref (including real refs and extra refs):
show_ref(refname, sha1)
But there is no need to stuff the alternate refs in extra_refs; we can
call show_ref() directly when iterating over the array, then handle
real refs separately. So change the code to:
generate array of SHA1s for alternate refs
for each unique SHA1 in array:
show_ref(".have", sha1)
for each ref (this now only includes real refs):
show_ref(refname, sha1)
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/receive-pack.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 65d129c..8c9e91e 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -144,9 +144,9 @@ static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, vo
return 0;
}
-static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
+static void show_one_alternate_sha1(const unsigned char sha1[20], void *unused)
{
- add_extra_ref(".have", sha1, 0);
+ show_ref(".have", sha1);
}
static void collect_one_alternate_ref(const struct ref *ref, void *data)
@@ -159,12 +159,11 @@ static void write_head_info(void)
{
struct sha1_array sa = SHA1_ARRAY_INIT;
for_each_alternate_ref(collect_one_alternate_ref, &sa);
- sha1_array_for_each_unique(&sa, add_one_alternate_sha1, NULL);
+ sha1_array_for_each_unique(&sa, show_one_alternate_sha1, NULL);
sha1_array_clear(&sa);
for_each_ref(show_ref_cb, NULL);
if (!sent_capabilities)
show_ref("capabilities^{}", null_sha1);
- clear_extra_refs();
/* EOF */
packet_flush(1);
--
1.7.8.2
^ permalink raw reply related
* [PATCH 0/3] Eliminate one user of extra_refs
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
From: Michael Haggerty <mhagger@alum.mit.edu>
Receive pack currently uses "extra refs" to keep track of ".have"
references, which in turn are used to tell the source the SHA1s of
references that are already known to the repository via alternates.
But the code already creates an array holding the alternate SHA1s. So
just read the SHA1s out of this array rather then round-tripping them
through the extra_refs mechanism.
This is one step towards hopefully abolishing extra_refs altogether.
I still have to examine the other user.
Michael Haggerty (3):
receive-pack: move more work into write_head_info()
show_ref(): remove unused "flag" and "cb_data" arguments
write_head_info(): handle "extra refs" locally
builtin/receive-pack.c | 51 ++++++++++++++++++++---------------------------
1 files changed, 22 insertions(+), 29 deletions(-)
--
1.7.8.2
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Phil Hord @ 2012-01-06 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, Antony Male, git, iveqy
In-Reply-To: <7vlipllmfh.fsf@alter.siamese.dyndns.org>
On Thu, Jan 5, 2012 at 7:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> If not I'm fine with just setting core.worktree to a relative path in
>> the git-submodule.sh script (like I did for the gitfile). And I'll look
>> into teaching "git mv" about submodules right after that.
>
> ... teaching "git mv" may be a good move, I would think. I do think keeping
> core.worktree pointing at the right directory is necessary, but I do not
> see much point in making it a relative path, though.
I do, in the case of submodules, as already discussed.
Do you see any _problem_ with making core.worktree a relative
directory in the specific case of git submodules?
Phil
^ permalink raw reply
* Re: Warning from AV software about kill.exe
From: Erik Blake @ 2012-01-06 13:51 UTC (permalink / raw)
To: kusmabite; +Cc: Pat Thoyts, Thomas Rast, git
In-Reply-To: <CABPQNSbd++dAOGu+5+WNMXzF6xtsdTpZq=xeXPbHwmxputXVRA@mail.gmail.com>
On 2012-01-05 17:33, Erik Faye-Lund wrote:
> On Wed, Jan 4, 2012 at 10:15 AM, Erik Blake<erik@icefield.yk.ca> wrote:
>> On 2011-12-22 19:19, Pat Thoyts wrote:
>>> Thomas Rast<trast@student.ethz.ch> writes:
>>>> Erik Blake<erik@icefield.yk.ca> writes:
>>>>
>>>>> I'm running git under Win7 64. As I selected "Repository|Visualize all
>>>>> branch history" in the git gui, my AV software (Trustport) trapped the
>>>>> bin\kill.exe program for "trying to modify system global settings
>>>>> (time, timezone, registry quota, etc.)"
>>>>>
>>>>> Does anyone know the details of this process and what it's function
>>>>> is? First time I've seen it, though I'm a relatively new user.
>>>> 'kill' is a standard unix utility that sends signals to processes, in
>>>> particular signals that cause the processes to exit or be killed
>>>> forcibly by the kernel, hence the name. (I don't know how the windows
>>>> equivalent works under the hood, but presumably it's something similar.)
>>>>
>>>> git-gui and gitk use kill to terminate background worker processes that
>>>> are no longer needed because you closed the window their output would
>>>> have been displayed in, etc.
>>> You might try replacing the command in the tcl scripts with 'exec
>>> taskkill /f /pid $pid' and see if that avoids the error. taskkill is
>>> present on XP and above as part of the OS distribution so shouldn't
>>> suffer any AV complaints.
>>>
>> Another way to implement this (on Windows) would be for the git programs to
>> tag themselves with a mutex. Then the "kill" program can determine which git
>> programs are running and send them user-defined windows messages to shut
>> themselves down. Alternatively, you could send the programs the standard
>> windows WM_CLOSE message, but the OS or an AV program might still be
>> troubled by that behaviour.
>>
>> This is how we implement this type of behaviour in our windows programs. It
>> does not raise the ire of the OS or AV since you do not have one process
>> trying to shut down another. It also bypasses all issues with process
>> privileges etc.
>>
>> Erik
>>
> No thanks. A process is allowed to terminate another process on
> Windows (as long as they are running as the same user, and the access
> token has not been messed with). If your AV detects this and prevents
> it, then your AV is broken. Re-building a kind of cooperative process
> termination for that reason is not the way forward.
>
> But the problem might be that MSYS' kill does more than it's supposed
> to (or misbehaves in some other way). This is, however, something you
> should take up with the MSYS developers, not the git development
> community.
>
> I would take this up with Trustport support. Overly eager AV
> heuristics is a fairly common problem, and usually gets fixed quickly.
>
Either solution should work, but "trying to modify system global
settings (time, timezone, registry quota, etc.)" suggests kill.exe is
overstepping the requirements for terminating another process. As you
suggest, I'll send a note to the MSYS developers. Maybe also ask
Trustport for details on that triggers this message.
e.
^ permalink raw reply
* Re: [PATCH] clone: allow detached checkout when --branch takes a tag
From: Jeff King @ 2012-01-06 14:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8BSzQiTScOhvQjLz8mQZC0g3fEOayBxn7n65t1tKwWnsw@mail.gmail.com>
On Fri, Jan 06, 2012 at 06:09:16PM +0700, Nguyen Thai Ngoc Duy wrote:
> > I wonder, though, if the original code makes any sense. By using
> > "refs/", I would have to say "--branch=heads/foo", which is kind of
> > weird and undocumented. I think it should probably always be
> > "refs/heads/", no matter if we are mirroring or not.
>
> --branch should not be used with --mirror in my opinion. --branch
> changes HEAD so it's no longer an exact mirror.
You could be making a repo that mirrors all of the refs, but has a
different HEAD (e.g., the upstream has "development" as the main branch,
but you want a local mirror with "production" as the HEAD).
I agree it's an unlikely combination (which is probably why nobody has
complained about the weird behavior), but I don't see a particular
reason to forbid it.
-Peff
^ permalink raw reply
* Re: [PATCH 0/3] Eliminate one user of extra_refs
From: Jeff King @ 2012-01-06 14:53 UTC (permalink / raw)
To: mhagger; +Cc: Junio C Hamano, git, Jakub Narebski, Heiko Voigt, Johan Herland
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
On Fri, Jan 06, 2012 at 03:12:30PM +0100, mhagger@alum.mit.edu wrote:
> Receive pack currently uses "extra refs" to keep track of ".have"
> references, which in turn are used to tell the source the SHA1s of
> references that are already known to the repository via alternates.
>
> But the code already creates an array holding the alternate SHA1s. So
> just read the SHA1s out of this array rather then round-tripping them
> through the extra_refs mechanism.
>
> This is one step towards hopefully abolishing extra_refs altogether.
> I still have to examine the other user.
Thanks, this is a nice simplification. The patches look good to me, and
they produce the same output for a simple test (I happened to be fiddling
with receive-pack and alternates yesterday, so I had a nice test case
right at hand :) ).
> receive-pack: move more work into write_head_info()
BTW, I have a patch to make sending ".have" refs configurable[1] (it
adds a receive.advertiseAlternates config variable), which this patch
conflicts with. I don't think that is your problem, but I thought I
would mention it since you are working in the area. Is that something we
want in git?
-Peff
[1] We are using it at GitHub because our alternates repos are so huge
that the overhead of advertising the refs outweighs the minor
benefits you get from avoiding object transfer.
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Nguyen Thai Ngoc Duy @ 2012-01-06 15:07 UTC (permalink / raw)
To: Phil Hord; +Cc: Junio C Hamano, Jens Lehmann, Antony Male, git, iveqy
In-Reply-To: <CABURp0rFOFfX7eu-v6ZK07iTfXwhOne60d70GkCdOvx0k8BZkQ@mail.gmail.com>
On Fri, Jan 6, 2012 at 9:26 PM, Phil Hord <phil.hord@gmail.com> wrote:
> Do you see any _problem_ with making core.worktree a relative
> directory in the specific case of git submodules?
Not a problem per se, but you should look at the comment at the top of
t1510 to see where it is relative to. Two interesting rules:
2. .git file is relative to parent directory. .git file is basically
symlink in disguise. The directory where .git file points to will
become new git_dir.
3. core.worktree is relative to git_dir.
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Jeff King @ 2012-01-06 15:52 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, git, Jonathan Nieder, Erik Faye-Lund,
Ilari Liusvaara, Nguyễn Thái Ngọc Duy
In-Reply-To: <20120105160612.GA27251@ecki.lan>
On Thu, Jan 05, 2012 at 05:06:15PM +0100, Clemens Buchacher wrote:
> On Wed, Jan 04, 2012 at 09:55:59PM -0500, Jeff King wrote:
> >
> > It so happens that I have just the patch you need. I've been meaning to
> > go over it again and submit it:
> >
> > run-command: optionally kill children on exit
> > https://github.com/peff/git/commit/5523d7ebf2a0386c9c61d7bfbc21375041df4989
>
> Thanks, looks great. But if I add this on top (to enable this for
> "git daemon"), then t0001 kills my entire X session. Not sure yet
> what's going.
Yikes. Thanks for noticing.
What happens is we have a failure case in start_command, set pid to -1,
and then fall through to the end of the function. So we end up marking
"-1" for cleanup, which attempts to kill all processes.
I never noticed it because it can only happen when fork() fails, or when
a child process signals an exec failure (which happens all the time with
aliases, but could not be triggered until your patch).
The fix is to move the recording of the PID up to a spot where we are
certain that it's a real PID. Fixup patch is below, and I'll push a new
version out to my github repo.
-Peff
diff --git a/run-command.c b/run-command.c
index aeb9c6e..614b722 100644
--- a/run-command.c
+++ b/run-command.c
@@ -353,6 +353,8 @@ fail_pipe:
if (cmd->pid < 0)
error("cannot fork() for %s: %s", cmd->argv[0],
strerror(failed_errno = errno));
+ else if (cmd->clean_on_exit)
+ mark_child_for_cleanup(cmd->pid);
/*
* Wait for child's execvp. If the execvp succeeds (or if fork()
@@ -374,8 +376,6 @@ fail_pipe:
}
close(notify_pipe[0]);
- if (cmd->clean_on_exit)
- mark_child_for_cleanup(cmd->pid);
}
#else
{
^ permalink raw reply related
* Re: [RFD] Handling of non-UTF8 data in gitweb
From: Jakub Narebski @ 2012-01-06 16:35 UTC (permalink / raw)
To: git; +Cc: Jürgen Kreileder, John Hawley, Jeff King, Junio C Hamano
In-Reply-To: <201112041709.32212.jnareb@gmail.com>
On Sun, 4 Dec 2011, Jakub Narebski wrote:
>
> Currently gitweb converts data it receives from git commands to Perl
> internal utf8 representation via to_utf8() subroutine
[...]
> Each part of data must be handled separately. It is quite error prone
> process, as can be seen from quite a number of patches that fix handling
> of UTF-8 data (latest from Jürgen).
>
>
> Much, much simpler would be to force opening of all files (including
> output pipes from git commands) in ':utf8' mode:
>
> use open qw(:std :utf8);
>
> [Note: perhaps instead of ':utf8' it should be ':encoding(UTF-8)'
> there...]
>
> But doing this would change gitweb behavior. [...]
[...]
> I don't know if people are relying on the old behavior. I guess
> it could be emulated by defining our own 'utf-8-with-fallback'
> encoding, or by defining our own PerlIO layer with PerlIO::via.
> But it no longer be simple solution (though still automatic).
I have now created simple Encode::UTF8WithFallback module, so that
use Encode::UTF8WithFallback;
use open IN => ':encoding(utf8-with-fallback)';
should be able to replace all calls to to_utf8() without any change
in behavior; at least simple tests shows that.
There however are two problems with this solution:
1. Encode::UTF8WithFallback should really be a separate Perl module
in a separate file (e.g. 'gitweb/lib/Encode/UTF8WithFallback.pm');
I was not able to make it work without a separate file.
This means that it very much requires the change that allows splitting
gitweb into many files and/or load extra helper modules, and/or require
extra non-core modules but provide and install them with gitweb if they
are not available. These changes are ready, and can be find in
'gitweb/split'
branch in my git.git repositories:
http://repo.or.cz/w/git/jnareb-git.git
https://github.com/jnareb/git
2. It turned out that the "open" pragma 1.04 from Perl v5.8.6 does not
work correctly. We need at least "open" 1.06 (version 1.05 consists
supposedly only of documentation-only change).
Because "open" is a core Perl module (core pragma), this means that
gitweb will require in practice Perl v5.8.9 at least, increasing
version requirement from current v5.8.0
--
Jakub Narebski
Poland
^ permalink raw reply
* Aborting "git commit --interactive" discards updates to index (was: Re: [ANNOUNCE] Git 1.7.6)
From: demerphq @ 2012-01-06 16:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ævar Arnfjörð Bjarmason
On 27 June 2011 17:59, Junio C Hamano <gitster@pobox.com> wrote:
> The latest feature release Git 1.7.6 is available at the usual
> places:
>
> http://www.kernel.org/pub/software/scm/git/
[snip]
> * Aborting "git commit --interactive" discards updates to the index
> made during the interactive session.
Hi, I am wondering why this change was made?
I can sort of understand if people do CTL-C during an interactive
commit that throwing the results away might be useful (although I
don't see why personally), but what I don't understand at all is why
it happens when the "add --interactive" is completed properly, but the
user decided not to actually commit. For me and a number of colleagues
the normal reason we exit the commit part (that is exit the editor
without modifying the commit message) is because we realize we forgot
something, such as adding a new file, and want to exit out and re-add
it. I am writing this after spending about 45 minutes showing a
colleague how to use git commit --interactive, when we realized that
we had forgotten to add a file. Needless to say he wasn't too happy
about losing 45 minutes work and having to redo it.
The new behavior potentially means that a lot of work (such as via the
'e' option) is instantly discarded. I don't understand why this is
perceived to be sensible behavior -- I thought the default policy for
git would be to not lose work!
I would really like an git config option to revert to the previous
behavior of not throwing away what I staged, or even better have git
commit --interactive ask me what I want to do, after all, it is an
interactive process so it seems reasonable it asks before it does
something like throw away work.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] xdiff: print post-image for common records instead of pre-image
From: René Scharfe @ 2012-01-06 17:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Joey Hess
In-Reply-To: <7vlipx4q3r.fsf@alter.siamese.dyndns.org>
Normally it doesn't matter if we show the pre-image or th post-image
for the common parts of a diff because they are the same. If
white-space changes are ignored they can differ, though. The
new text after applying the diff is more interesting in that case,
so show that instead of the old contents.
Note: GNU diff shows the pre-image.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
t/t4015-diff-whitespace.sh | 14 +++++++-------
xdiff/xemit.c | 12 ++++++------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 9059bcd..cc3db13 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -103,7 +103,7 @@ test_expect_success 'another test, with -w --ignore-space-at-eol' 'test_cmp expe
git diff -w -b --ignore-space-at-eol > out
test_expect_success 'another test, with -w -b --ignore-space-at-eol' 'test_cmp expect out'
-tr 'Q' '\015' << EOF > expect
+tr 'Q_' '\015 ' << EOF > expect
diff --git a/x b/x
index d99af23..8b32fb5 100644
--- a/x
@@ -111,19 +111,19 @@ index d99af23..8b32fb5 100644
@@ -1,6 +1,6 @@
-whitespace at beginning
+ whitespace at beginning
- whitespace change
+ whitespace change
-whitespace in the middle
+white space in the middle
- whitespace at end
+ whitespace at end__
unchanged line
- CR at endQ
+ CR at end
EOF
git diff -b > out
test_expect_success 'another test, with -b' 'test_cmp expect out'
git diff -b --ignore-space-at-eol > out
test_expect_success 'another test, with -b --ignore-space-at-eol' 'test_cmp expect out'
-tr 'Q' '\015' << EOF > expect
+tr 'Q_' '\015 ' << EOF > expect
diff --git a/x b/x
index d99af23..8b32fb5 100644
--- a/x
@@ -135,9 +135,9 @@ index d99af23..8b32fb5 100644
+ whitespace at beginning
+whitespace change
+white space in the middle
- whitespace at end
+ whitespace at end__
unchanged line
- CR at endQ
+ CR at end
EOF
git diff --ignore-space-at-eol > out
test_expect_success 'another test, with --ignore-space-at-eol' 'test_cmp expect out'
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 2e669c3..d11dbf9 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -87,7 +87,7 @@ static long def_ff(const char *rec, long len, char *buf, long sz, void *priv)
static int xdl_emit_common(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdemitconf_t const *xecfg) {
- xdfile_t *xdf = &xe->xdf1;
+ xdfile_t *xdf = &xe->xdf2;
const char *rchg = xdf->rchg;
long ix;
@@ -204,8 +204,8 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
/*
* Emit pre-context.
*/
- for (; s1 < xch->i1; s1++)
- if (xdl_emit_record(&xe->xdf1, s1, " ", ecb) < 0)
+ for (; s2 < xch->i2; s2++)
+ if (xdl_emit_record(&xe->xdf2, s2, " ", ecb) < 0)
return -1;
for (s1 = xch->i1, s2 = xch->i2;; xch = xch->next) {
@@ -213,7 +213,7 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
* Merge previous with current change atom.
*/
for (; s1 < xch->i1 && s2 < xch->i2; s1++, s2++)
- if (xdl_emit_record(&xe->xdf1, s1, " ", ecb) < 0)
+ if (xdl_emit_record(&xe->xdf2, s2, " ", ecb) < 0)
return -1;
/*
@@ -239,8 +239,8 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
/*
* Emit post-context.
*/
- for (s1 = xche->i1 + xche->chg1; s1 < e1; s1++)
- if (xdl_emit_record(&xe->xdf1, s1, " ", ecb) < 0)
+ for (s2 = xche->i2 + xche->chg2; s2 < e2; s2++)
+ if (xdl_emit_record(&xe->xdf2, s2, " ", ecb) < 0)
return -1;
}
--
1.7.8.2
^ permalink raw reply related
* Re: [PATCH v3] Limit refs to fetch to minimum in shallow clones
From: Junio C Hamano @ 2012-01-06 18:40 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Shawn O. Pearce
In-Reply-To: <1325833869-20078-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> The main purpose of shallow clones is to reduce download by only
> fetching objects up to a certain depth from the given refs. The number
> of objects depend on how many refs to follow. So:
>
> - Only fetch HEAD or the ref specified by --branch
> - Only fetch tags that reference to downloaded objects
>
> More tags/branches can be fetched later using git-fetch as usual.
>
> The old behaviour can still be called with --no-single-branch
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Thanks.
> @@ -179,6 +180,15 @@ objects from the source repository into a pack in the cloned repository.
> with a long history, and would want to send in fixes
> as patches.
>
> +--single-branch::
> +--no-single-branch::
> + These options are only valid when --depth is given.
> + `--single-branch` only fetches one branch (either HEAD or
> + specified by --branch) and tags that point to the downloaded
> + history. `--no-single-branch` fetches all branches and tags
> + like in normal clones. `--single-branch` is implied by
> + default.
> +
My first reaction after reading "is implied by default" was "Huh? didn't
we just read these kick in only when --depth is given?" and I had to read
it again. Here is my attempt to rephrase it.
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary branch
remote's `HEAD` points at. When creating a shallow clone with the
`--depth` option, this is the default, unless `--no-single-branch`
is given to fetch the histories near the tips of all branches.
Currently this option only works when creating a shallow clone and
does not have any effect without the `--depth` option.
We might want to later enhance this to work also with a full-depth clone
that tracks only one branch, and the above phrasing would make it clear.
> + if (!option_branch)
> + remote_head = guess_remote_head(head, refs, 0);
> + else {
> + struct strbuf sb = STRBUF_INIT;
> + strbuf_addstr(&sb, src_ref_prefix);
> + strbuf_addstr(&sb, option_branch);
> + remote_head = find_ref_by_name(refs, sb.buf);
> + strbuf_release(&sb);
> + }
> +
> + if (!remote_head)
> + die(_("Remote branch \"%s\" not found. Nothing to clone.\n"
> + "Try --no-single-branch to fetch all refs."),
> + option_branch ? option_branch : "HEAD");
Switching upon option_branch to tweak the message is a good idea, but
strictly speaking, we would hit this die() when guess_remote_head() does
not find where HEAD points at because it is detached, and in that case,
the error is not "Nothing to clone", but "We couldn't tell which branch
you meant to limit this cloning to".
> @@ -642,9 +679,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> transport_set_option(transport, TRANS_OPT_KEEP, "yes");
>
> - if (option_depth)
> + if (option_depth) {
> transport_set_option(transport, TRANS_OPT_DEPTH,
> option_depth);
> + transport_set_option(transport, TRANS_OPT_FOLLOWTAGS,
> + option_single_branch ? "1" : NULL);
Curious. Does anybody set FOLLOWTAGS to the transport by default becore we
come here (just asking)?
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Junio C Hamano @ 2012-01-06 18:53 UTC (permalink / raw)
To: Phil Hord; +Cc: Jens Lehmann, Antony Male, git, iveqy
In-Reply-To: <CABURp0rFOFfX7eu-v6ZK07iTfXwhOne60d70GkCdOvx0k8BZkQ@mail.gmail.com>
Phil Hord <phil.hord@gmail.com> writes:
> On Thu, Jan 5, 2012 at 7:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>> If not I'm fine with just setting core.worktree to a relative path in
>>> the git-submodule.sh script (like I did for the gitfile). And I'll look
>>> into teaching "git mv" about submodules right after that.
>>
>> ... teaching "git mv" may be a good move, I would think. I do think keeping
>> core.worktree pointing at the right directory is necessary, but I do not
>> see much point in making it a relative path, though.
>
> I do, in the case of submodules, as already discussed.
Of course you are right.
^ permalink raw reply
* Re: [PATCH] xdiff: print post-image for common records instead of pre-image
From: Junio C Hamano @ 2012-01-06 19:10 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Joey Hess
In-Reply-To: <4F072B9C.1030005@lsrfire.ath.cx>
Thanks.
^ permalink raw reply
* Re: [PATCH] parse_object: try internal cache before reading object db
From: Jeff King @ 2012-01-06 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, git-dev
In-Reply-To: <7vipkpn87d.fsf@alter.siamese.dyndns.org>
On Thu, Jan 05, 2012 at 01:35:50PM -0800, Junio C Hamano wrote:
> > For example, GitHub's alternates repository for git.git has
> > ~120,000 refs, of which only ~3200 are unique. The time for
> > upload-pack to print its list of advertised refs dropped
> > from 3.4s to 0.76s.
>
> Nice. I am more impressed by 120k/3.4 than 3.2k/0.76, though ;-)
Actually, we can do much better than that. Here are a few patches that
avoid parsing objects when possible. They drop the 3.4s to 2.0s. If you
combine them with the parse_object optimization, my 120K case drops to
around 0.68s.
I don't know if it is really that worth it on top of the parse_object
optimization. It's almost negligible for the normal case (though I get a
tiny speedup on my ~900-ref git.git repo), and a minor speedup on the
crazy alternates case. OTOH, if you had some totally insane ref
structure, like 120K _unique_ refs (which would probably imply that
you're making one ref per commit or something silly like that. But hey,
people have suggested it in the past), then it could be a big
improvement.
[1/2]: upload-pack: avoid parsing objects during ref advertisement
[2/2]: upload-pack: avoid parsing tag destinations
-Peff
^ permalink raw reply
* [PATCH 1/2] upload-pack: avoid parsing objects during ref advertisement
From: Jeff King @ 2012-01-06 19:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, git-dev
In-Reply-To: <7vipkpn87d.fsf@alter.siamese.dyndns.org>
When we advertise a ref, the first thing we do is parse the
pointed-to object. This gives us two things:
1. a "struct object" we can use to store flags
2. the type of the object, so we know whether we need to
dereference it as a tag
Instead, we can just use lookup_unknown_object to get an
object struct, and then fill in just the type field using
sha1_object_info (which, in the case of packed files, can
find the information without actually inflating the object
data).
This can save time if you have a large number of refs, and
the client isn't actually going to request those refs (e.g.,
because most of them are already up-to-date).
The downside is that we are no longer verifying objects that
we advertise by fully parsing them (however, we do still
know we actually have them, because sha1_object_info must
find them to get the type). While we might fail to detect a
corrupt object here, if the client actually fetches the
object, we will parse (and verify) it then.
On a repository with 120K refs, the advertisement portion of
upload-pack goes from ~3.4s to 3.2s (the failure to speed up
more is largely due to the fact that most of these refs are
tags, which need dereferenced to find the tag destination
anyway).
Signed-off-by: Jeff King <peff@peff.net>
---
upload-pack.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 6f36f62..65cb0ff 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -720,11 +720,14 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
" include-tag multi_ack_detailed";
- struct object *o = parse_object(sha1);
+ struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
- if (!o)
- die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+ if (o->type == OBJ_NONE) {
+ o->type = sha1_object_info(sha1, NULL);
+ if (o->type < 0)
+ die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+ }
if (capabilities)
packet_write(1, "%s %s%c%s%s\n", sha1_to_hex(sha1), refname_nons,
@@ -738,6 +741,7 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
nr_our_refs++;
}
if (o->type == OBJ_TAG) {
+ o = parse_object(o->sha1);
o = deref_tag(o, refname, 0);
if (o)
packet_write(1, "%s %s^{}\n", sha1_to_hex(o->sha1), refname_nons);
--
1.7.6.5.14.g7b06f
^ permalink raw reply related
* [PATCH 2/2] upload-pack: avoid parsing tag destinations
From: Jeff King @ 2012-01-06 19:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, git-dev
In-Reply-To: <7vipkpn87d.fsf@alter.siamese.dyndns.org>
When upload-pack advertises refs, it dereferences any tags
it sees, and shows the resulting sha1 to the client. It does
this by calling deref_tag. That function must load and parse
each tag object to find the sha1 of the tagged object.
However, it also ends up parsing the tagged object itself,
which is not strictly necessary for upload-pack's use.
Each tag produces two object loads (assuming it is not a
recursive tag), when it could get away with only a single
one. Dropping the second load halves the effort we spend.
The downside is that we are no longer verifying the
resulting object by loading it. In particular:
1. We never cross-check the "type" field given in the tag
object with the type of the pointed-to object. If the
tag says it points to a tag but doesn't, then we will
keep peeling and realize the error. If the tag says it
points to a non-tag but actually points to a tag, we
will stop peeling and just advertise the pointed-to
tag.
2. If we are missing the pointed-to object, we will not
realize (because we never even look it up in the object
db).
However, both of these are errors in the object database,
and both will be detected if a client actually requests the
broken objects in question. So we are simply pushing the
verification away from the advertising stage, and down to
the actual fetching stage.
On my test repo with 120K refs, this drops the time to
advertise the refs from ~3.2s to ~2.0s.
Signed-off-by: Jeff King <peff@peff.net>
---
tag.c | 12 ++++++++++++
tag.h | 1 +
upload-pack.c | 3 +--
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/tag.c b/tag.c
index 3aa186d..78d272b 100644
--- a/tag.c
+++ b/tag.c
@@ -24,6 +24,18 @@ struct object *deref_tag(struct object *o, const char *warn, int warnlen)
return o;
}
+struct object *deref_tag_noverify(struct object *o)
+{
+ while (o && o->type == OBJ_TAG) {
+ o = parse_object(o->sha1);
+ if (o && o->type == OBJ_TAG && ((struct tag *)o)->tagged)
+ o = ((struct tag *)o)->tagged;
+ else
+ o = NULL;
+ }
+ return o;
+}
+
struct tag *lookup_tag(const unsigned char *sha1)
{
struct object *obj = lookup_object(sha1);
diff --git a/tag.h b/tag.h
index 5ee88e6..bc8a1e4 100644
--- a/tag.h
+++ b/tag.h
@@ -16,6 +16,7 @@ extern struct tag *lookup_tag(const unsigned char *sha1);
extern int parse_tag_buffer(struct tag *item, const void *data, unsigned long size);
extern int parse_tag(struct tag *item);
extern struct object *deref_tag(struct object *, const char *, int);
+extern struct object *deref_tag_noverify(struct object *);
extern size_t parse_signature(const char *buf, unsigned long size);
#endif /* TAG_H */
diff --git a/upload-pack.c b/upload-pack.c
index 65cb0ff..c01e161 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -741,8 +741,7 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
nr_our_refs++;
}
if (o->type == OBJ_TAG) {
- o = parse_object(o->sha1);
- o = deref_tag(o, refname, 0);
+ o = deref_tag_noverify(o);
if (o)
packet_write(1, "%s %s^{}\n", sha1_to_hex(o->sha1), refname_nons);
}
--
1.7.6.5.14.g7b06f
^ permalink raw reply related
* Re: [PATCH 3/3] write_head_info(): handle "extra refs" locally
From: Junio C Hamano @ 2012-01-06 19:45 UTC (permalink / raw)
To: mhagger; +Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland
In-Reply-To: <1325859153-31016-4-git-send-email-mhagger@alum.mit.edu>
mhagger@alum.mit.edu writes:
> From: Michael Haggerty <mhagger@alum.mit.edu>
>
> The old code basically did:
>
> generate array of SHA1s for alternate refs
> for each unique SHA1 in array:
> add_extra_ref(".have", sha1)
> for each ref (including real refs and extra refs):
> show_ref(refname, sha1)
>
> But there is no need to stuff the alternate refs in extra_refs; we can
> call show_ref() directly when iterating over the array, then handle
> real refs separately. So change the code to:
>
> generate array of SHA1s for alternate refs
> for each unique SHA1 in array:
> show_ref(".have", sha1)
> for each ref (this now only includes real refs):
> show_ref(refname, sha1)
This updated logic should be equivalent to the old one as long as nobody
else called add_extra_ref() before we come to write_head_info() function,
which should hold true.
The entire series looks good. Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Clemens Buchacher @ 2012-01-06 19:48 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Jonathan Nieder, Erik Faye-Lund,
Ilari Liusvaara, Nguyễn Thái Ngọc Duy
In-Reply-To: <20120106155204.GA17355@sigill.intra.peff.net>
On Fri, Jan 06, 2012 at 10:52:04AM -0500, Jeff King wrote:
> > >
> > > run-command: optionally kill children on exit
> > > https://github.com/peff/git/commit/5523d7ebf2a0386c9c61d7bfbc21375041df4989
> >
> > Thanks, looks great. But if I add this on top (to enable this for
> > "git daemon"), then t0001 kills my entire X session. Not sure yet
> > what's going.
>
> The fix is to move the recording of the PID up to a spot where we are
> certain that it's a real PID. Fixup patch is below, and I'll push a new
> version out to my github repo.
I have rebased Junio's cb/git-daemon-tests onto your
jk/child-cleanup and replaced the call to pkill with a regular kill
command.
On top of that, I have added two commits to fix the discussed race
condition. I also verified that the race condition actually happens
by adding an artificial delay in the daemon (this change is
obviously not included).
I pushed the new cb/git-daemon-tests to
https://github.com/drizzd/git . If you have no objections I will
post the entire series including your run-command and send-pack
patches to the list.
Clemens
^ permalink raw reply
* Re: Managing signed git tags and expiring keys
From: Junio C Hamano @ 2012-01-06 20:09 UTC (permalink / raw)
To: Jonathan "Duke" Leto; +Cc: Git Users
In-Reply-To: <CABQG1aSY53-Z73CiUf2kstfaKLJ8zBGzu51CFdWHGiVR16JJ7w@mail.gmail.com>
"Jonathan \"Duke\" Leto" <jonathan@leto.net> writes:
> When the key changes, all existing tags are signed with the previous
> key in the chain of trust.
>
> Do people:
> 1) resign all the tags, causing people to overwrite their local tags
> 2) keep all versions of the keys in the chain of trust
> 3) something else more involved?
>
> Is anybody doing this currently?
Many kernel.org users (Linus and myself included) changed their signing
keys last year, so their project histories have tags signed with different
keys. I highly doubt anybody revoked old key and re-signed his tags with
new one.
^ permalink raw reply
* Re: [PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]
From: Junio C Hamano @ 2012-01-06 20:27 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <f697b8eff63a8cdd1207c6bfd6b88c532832c6b5.1325855112.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> git-rerere(1) does not mention the rr-cache fallback; I decided not to
> touch it as it's a bit of an implementation detail.
It is not an implementation detail but is a (n old) part of the external
UI. Creating .git/rr-cache directory has been the only way to enable it
for quite a while (ever since it was first written as a Perl script early
2006, and the design even survived the rewrite in C late 2006). When the
configuration variable rerere.enabled was introduced with b4372ef (Enable
"git rerere" by the config variable rerere.enabled, 2007-07-06), we
deliberately kept the external interface compatible to avoid disruption.
And your "By default, ... is enabled if there is ... directory" below is
exactly the right description.
The manual page for "rerere" talks about "configuration variable
rerere.enabled"; perhaps it should also refer to git config manual page to
make it more discoverable?
> ... OTOH the
> auto-creation of rr-cache can cause strange behavior if a user has
> rerere.enabled unset and tries it once, as in
>
> git config rerere.enabled true
> git merge ...
> git config --unset rerere.enabled
That is because the last one should be
git config --bool rerere.enabled false
Perhaps the description for "--unset" option in the manual of "git config"
is not clear enough that there is a difference between a variable not
being set (i.e. we do not know anything about what the user wants) and a
variable explicitly set to false (i.e. we do know the user does not want
it)? I doubt it, but you may want to check and clarify the section if
needed.
The patch itself looks good; it goes in the right direction.
Thanks.
> Documentation/config.txt | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 68cf702..04f5e19 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1783,10 +1783,10 @@ rerere.autoupdate::
>
> rerere.enabled::
> Activate recording of resolved conflicts, so that identical
> - conflict hunks can be resolved automatically, should they
> - be encountered again. linkgit:git-rerere[1] command is by
> - default enabled if you create `rr-cache` directory under
> - `$GIT_DIR`, but can be disabled by setting this option to false.
> + conflict hunks can be resolved automatically, should they be
> + encountered again. By default, linkgit:git-rerere[1] is
> + enabled if there is an `rr-cache` directory under the
> + `$GIT_DIR`.
>
> sendemail.identity::
> A configuration identity. When given, causes values in the
^ permalink raw reply
* Re: [PATCH] parse_object: try internal cache before reading object db
From: Junio C Hamano @ 2012-01-06 21:27 UTC (permalink / raw)
To: Jeff King; +Cc: git, git-dev
In-Reply-To: <20120106191654.GA11022@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Actually, we can do much better than that. Here are a few patches that
> avoid parsing objects when possible. They drop the 3.4s to 2.0s. If you
> combine them with the parse_object optimization, my 120K case drops to
> around 0.68s.
>
> I don't know if it is really that worth it on top of the parse_object
> optimization. It's almost negligible for the normal case...
> ... OTOH, if you had some totally insane ref
> structure, like 120K _unique_ refs (which would probably imply that
> you're making one ref per commit or something silly like that. But hey,
> people have suggested it in the past), then it could be a big
> improvement.
Even though it is a bit scary kind of loosening of sanity checks that I
hesitate to take at this late in the cycle, I think it makes sense. Let's
queue them on 'pu' and aim for the next cycle.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.8.3
From: Junio C Hamano @ 2012-01-06 21:53 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.7.8.3 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
e5eb8c289b69d69fd08c81b587a06eb5dd2b5c1c git-1.7.8.3.tar.gz
8a65d2425c1b6f646d130cf5846e92e9e0e93736 git-htmldocs-1.7.8.3.tar.gz
a6e2b7cff8181ee52a1cc00ebba7b349850d6680 git-manpages-1.7.8.3.tar.gz
Also the following public repositories all have a copy of the v1.7.8.3
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
----------------------------------------------------------------
Changes since v1.7.8.2 are as follows:
Brian Harring (1):
fix hang in git fetch if pointed at a 0 length bundle
Clemens Buchacher (2):
Documentation: read-tree --prefix works with existing subtrees
t5550: repack everything into one file
Jack Nagel (1):
Add MYMETA.json to perl/.gitignore
Jakub Narebski (1):
gitweb: Fix fallback mode of to_utf8 subroutine
Jens Lehmann (1):
docs: describe behavior of relative submodule URLs
Junio C Hamano (1):
Git 1.7.8.3
Jürgen Kreileder (3):
gitweb: Call to_utf8() on input string in chop_and_escape_str()
gitweb: esc_html() site name for title in OPML
gitweb: Output valid utf8 in git_blame_common('data')
Nguyễn Thái Ngọc Duy (1):
Catch invalid --depth option passed to clone or fetch
Thomas Rast (1):
Documentation: rerere.enabled is the primary way to configure rerere
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox