Not every server out there supports fixing thin packs, so let's send
them a full pack.
Signed-off-by: Carlos Martín Nieto c...@elego.de
---
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
On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto c...@elego.de 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
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 pclo...@gmail.com 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 c...@elego.de 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 @@
On Tue, Oct 8, 2013 at 4:44 PM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto c...@elego.de 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
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=n] [--depth=n]
[--revs [--unpacked |
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
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 christopherar...@gmail.com
---
builtin/blame.c | 51 +--
1 file changed, 49
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
On Tue, 3 Sep 2013 13:35:44 -0400 Jeff King p...@peff.net 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
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 file, to see what I mean. The
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
Chris J Arges christopherar...@gmail.com 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
On 10/08/2013 10:16 AM, Junio C Hamano wrote:
Chris J Arges christopherar...@gmail.com 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
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 prev goes
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
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 backwards
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
On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder jrnie...@gmail.com 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
+++
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 t...@lifelogs.com
---
contrib/credential/netrc/git-credential-netrc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/netrc/git-credential-netrc
Ted Zlatanov wrote:
On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder jrnie...@gmail.com 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
On Tue, 08 Oct 2013 21:58:41 +0200 Stefan Beller stefanbel...@googlemail.com
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
On Tue, 8 Oct 2013 13:02:35 -0700 Jonathan Nieder jrnie...@gmail.com wrote:
JN Ted Zlatanov wrote:
On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder jrnie...@gmail.com
wrote:
JN Ted Zlatanov wrote:
Simple patch to avoid unitialized warning and log what we'll do.
JN Sign-off?
I didn't
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 90
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 sand...@crustytoothpaste.net
---
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
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
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.
---
(Apologies to Lucas
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
On Sat, Oct 5, 2013 at 7:30 PM, Johan Herland jo...@herland.net 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
On Sat, Oct 5, 2013 at 7:30 PM, Johan Herland jo...@herland.net 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
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 p.giarru...@gmail.com
---
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
