Not every server out there supports fixing thin packs, so let's send
them a full pack.
Signed-off-by: Carlos Martín Nieto
---
It's not always possible to support thin packs (sometimes there isn't
even an object database to grab bases out of). And in any case git
shouldn't create thin packs if th
On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto wrote:
> diff --git a/send-pack.c b/send-pack.c
> index 7d172ef..7b88ac8 100644
> --- a/send-pack.c
> +++ b/send-pack.c
> @@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,
> quiet_supported = 1;
> if (server_s
Actually I only wanted to change one line to prevent a crash, when you
specify a non existing branch when cloning:
- if (option_branch) {
+ if (option_branch && our_head_points_at) {
However it turns out this is not a good idea as we still want to setup
Duy Nguyen writes:
On Tue, 2013-10-08 at 16:44 +0700, Duy Nguyen wrote:
>On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto wrote:
> > diff --git a/send-pack.c b/send-pack.c
> > index 7d172ef..7b88ac8 100644
> > --- a/send-pack.c
> > +++ b/send-pack.c
> > @@ -205,6 +205,8 @@ int send_pack(struc
On Tue, Oct 8, 2013 at 4:44 PM, Duy Nguyen wrote:
> On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto wrote:
>> diff --git a/send-pack.c b/send-pack.c
>> index 7d172ef..7b88ac8 100644
>> --- a/send-pack.c
>> +++ b/send-pack.c
>> @@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,
>>
Hi,
I've noticed that man git-pack-objects describes cmdline as following
SYNOPSYS
'git pack-objects' [-q | --progress | --all-progress] [--all-progress-implied]
[--no-reuse-delta] [--delta-base-offset] [--non-empty]
[--local] [--incremental] [--window=] [--depth=]
[--revs [--unpacked | --all]] [
Please Kindly find the attached file.
PDF.pdf
Description: Adobe PDF document
As a unix user I'd expect the SYNOPSIS section at the top of the man page to
include all options that the command accepts. Mutually exclusive options are
expected to be in the form [-q | --progress | --all-progress], such is already
done.
I believe that you'd be safe in following
http://pubs.
Add colorized text for git blame when color.interactive is enabled.
This work is based on the colorization code in builtin/clean.c.
Signed-off-by: Chris J Arges
---
builtin/blame.c | 51 +--
1 file changed, 49 insertions(+), 2 deletions(-)
diff
Simple patch to avoid unitialized warning and log what we'll do.
---
contrib/credential/netrc/git-credential-netrc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/netrc/git-credential-netrc
b/contrib/credential/netrc/git-credential-netrc
index 6c51c43..
On Tue, 3 Sep 2013 13:35:44 -0400 Jeff King wrote:
JK> On Tue, Sep 03, 2013 at 11:23:14AM -0400, Ted Zlatanov wrote:
>> Yes, you're right. Something like the following (untested) could work
>> and does the wildcards, which I will make into a proper patch and test
>> if it looks OK to you.
...
J
On 10/08/2013 04:18 PM, Chris J Arges wrote:
> Add colorized text for git blame when color.interactive is enabled.
> This work is based on the colorization code in builtin/clean.c.
>
Another way to color blame, would be by commit, not by row.
Try "git gui blame ", to see what I mean. The colorisa
I'm trying to set a http git server.
I do the following on the git server:
cd /var/www/html/
git clone --bare /path/to/dir/ gitproject.git
cd gitproject.git/
mv hooks/post-update.sample hooks/post-update
chmod a+x hooks/post-update
on the local machine run:
git clone http://server.name/g
Chris J Arges writes:
> Add colorized text for git blame when color.interactive is enabled.
It does not make any sense to tie this to color.interactive at all,
at least to me. The "check color.blame and if absent fall back to
color.ui", which is the usual pattern, would be more appropriate.
>
On 10/08/2013 10:16 AM, Junio C Hamano wrote:
> Chris J Arges writes:
>
>> Add colorized text for git blame when color.interactive is enabled.
>
> It does not make any sense to tie this to color.interactive at all,
> at least to me. The "check color.blame and if absent fall back to
> color.ui",
On 13-09-30 10:31 PM, Lucas Sandery [three am design] wrote:
> The "next" and "prev" buttons are lacking consistency and logic. For RTL
> languages previous is almost always on the left, and next on the right. The
> words are contradictory, "next" actually goes to backwards chronologically,
> and "
This is a copy of an article I published at
http://fanf.livejournal.com/128282.html
I'm sending a copy here because I'm interested to know what other ways
there might be of handling this situation.
--
We often need to patch the software that we run in order to fix bugs
quickly rather than wait fo
Hi,
Marc Branchaud wrote:
> On 13-09-30 10:31 PM, Lucas Sandery [three am design] wrote:
>> The "next" and "prev" buttons are lacking consistency and logic. For LTR
>> languages previous is almost always on the left, and next on the right. The
>> words are contradictory, "next" actually goes to b
Hi,
Ted Zlatanov wrote:
> Simple patch to avoid unitialized warning and log what we'll do.
Sign-off?
[...]
> --- a/contrib/credential/netrc/git-credential-netrc
> +++ b/contrib/credential/netrc/git-credential-netrc
> @@ -369,7 +369,10 @@ sub find_netrc_entry {
> {
> my $entr
On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder wrote:
JN> Ted Zlatanov wrote:
>> Simple patch to avoid unitialized warning and log what we'll do.
JN> Sign-off?
I didn't realize it was a requirement, must I?
JN> [...]
>> --- a/contrib/credential/netrc/git-credential-netrc
>> +++ b/contrib/
On 10/08/2013 09:55 PM, Ted Zlatanov wrote:
> JN> Sign-off?
>
> I didn't realize it was a requirement, must I?
Yes, this is a requirement. See Documentation/SubmittingPatches
to read what signing off actually means here.
Stefan
signature.asc
Description: OpenPGP digital signature
Simple patch to avoid unitialized warning and log what we'll do.
Signed-off-by: Ted Zlatanov
---
contrib/credential/netrc/git-credential-netrc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/netrc/git-credential-netrc
b/contrib/credential/netrc/git-cred
Ted Zlatanov wrote:
> On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder wrote:
> JN> Ted Zlatanov wrote:
>>> Simple patch to avoid unitialized warning and log what we'll do.
> JN> Sign-off?
>
> I didn't realize it was a requirement, must I?
See Documentation/SubmittingPatches, section '(5) Sign
On Tue, 08 Oct 2013 21:58:41 +0200 Stefan Beller
wrote:
SB> On 10/08/2013 09:55 PM, Ted Zlatanov wrote:
JN> Sign-off?
>>
>> I didn't realize it was a requirement, must I?
SB> Yes, this is a requirement. See Documentation/SubmittingPatches
SB> to read what signing off actually means here.
OK,
On Tue, 8 Oct 2013 13:02:35 -0700 Jonathan Nieder wrote:
JN> Ted Zlatanov wrote:
>> On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder
>> wrote:
JN> Ted Zlatanov wrote:
Simple patch to avoid unitialized warning and log what we'll do.
JN> Sign-off?
>>
>> I didn't realize it was a require
On 13-10-08 03:36 PM, Jonathan Nieder wrote:
>
> In a branchy history, it is possible for the next matching commit to
> actually be newer.
Chronologically, yes.
Gitk will often display a history like this (here the numbers represent
commit dates, so 1 is the oldest commit, and I've rotated this
Explain the reason for and behavior of the new http.continue option, and that it
is enabled by default. Furthermore, explain that it is required for large
GSS-Negotiate requests but incompatible with some proxies.
Signed-off-by: brian m. carlson
---
Documentation/config.txt | 9 +
1 fil
When using GSS-Negotiate authentication with libcurl, the authentication
provided will change every time, and so the probe that git uses to determine if
authentication is needed is not sufficient to guarantee that data can be sent.
If the data fits entirely in http.postBuffer bytes, the data can be
This patch set adds an option, http.continue, to enable requests for 100
Continue responses when pushing over HTTP. This is needed for large pushes
using GSS-Negotiate authentication.
I decided to be optimistic and default the option to on, which means that 100
Continue responses will be requeste
Users often find that "next" and "prev" do the opposite of what they
expect. For example, "next" moves to the next match down the list, but
that is almost always backwards in time. Renaming "next" to "older"
and "prev" to "newer" makes it clear where the buttons will take the user.
---
(Apologie
Duy Nguyen wrote:
> Or maybe it's not that late. How about you go with your patch and add
> thin-pack capability to receive-pack too?
>
> When new "git push" is used against old server, thin pack is disabled.
> But that's not a big deal (I hope).
Could we have separate patches to introduce the se
On Sat, Oct 5, 2013 at 7:30 PM, Johan Herland wrote:
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 4dd3bcb..da00671 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -973,6 +979,15 @@ without giving any repository layout options. If the
On Sat, Oct 5, 2013 at 7:30 PM, Johan Herland wrote:
> diff --git a/t/t9117-git-svn-init-clone.sh b/t/t9117-git-svn-init-clone.sh
> index b7ef9e2..1c8d049 100755
> --- a/t/t9117-git-svn-init-clone.sh
> +++ b/t/t9117-git-svn-init-clone.sh
> @@ -52,4 +52,71 @@ test_expect_success 'clone to target di
Since say uses echo, this uses echo -n, which is not portable - see
19c3c5fdcb35b66b792534c5dc4e8d87a3952d2a.
Without this commit, the output looks like:
...
-n 1891/1936 (1883)
-n 1892/1936 (1884)
-n 1893/1936 (1885)
...
Signed-off-by: Paolo G. Giarrusso
---
Please CC me on replie
Thanks for the review David, much appreciated.
> I think this line was already too long in its current form. Would you mind
> splitting up this long line?
I've updated the patch and had a look at how to avoid repeating the list of
available merge/difftools.
> ... follow it up with a change that
35 matches
Mail list logo
