git diff -M --stat can detect rename and show renamed file name like
foofoofoo = barbarbar, but if destination filename is long the line
is shortened like ...barbarbar so there is no way to know whether the
file is renamed or existed in the source commit.
This commit makes it visible like ...foo =
On Wed, Oct 09, 2013 at 12:51:26PM -0400, Nicolas Pitre wrote:
Now let's mitigate the deep delta chaining effect in the tree encoding:
$ rm .git/objects/pack/pack-foo.*
$ ../../git/test-packv4 --min-tree-copy=50 orig/pack-*.pack
.git/objects/pack/pack-foo.pack
Scanning objects: 100%
Hi,
Another iteration, identical to v2, except for the fixes suggested by
Eric Sunshine.
...Johan
Johan Herland (3):
Documentation/git-svn: Promote the use of --prefix in docs + examples
git-svn: Warn about changing default for --prefix in Git v2.0
Git 2.0: git svn: Set default
Currently, the git-svn defaults to using an empty prefix, which ends
up placing the SVN-tracking refs directly in refs/remotes/*. This
placement runs counter to Git's convention of placing remote-tracking
branches in refs/remotes/$remote/*.
Furthermore, combining git-svn with regular Git remotes
git-svn by default puts its Subversion-tracking refs directly in
refs/remotes/*. This runs counter to Git's convention of using
refs/remotes/$remote/* for storing remote-tracking branches.
Furthermore, combining git-svn with regular git remotes run the risk of
clobbering refs under refs/remotes
In Git v2.0, we will change the default --prefix for init/clone from
none/empty to origin/ (which causes SVN-tracking branches to be
placed at refs/remotes/origin/* instead of refs/remotes/*).
This patch warns users about the upcoming change, both in the git-svn
manual page, and on stderr when
On Fri, Oct 11, 2013 at 07:22:59PM +0700, Duy Nguyen wrote:
Maybe we could make an exception and allow the tree walker to pass
pv4_tree_cache* directly to decode_entries so it does not need to do
the first lookup every time..
Suggestions?
Looking at decode_entries() traces I think
git diff -M --stat can detect rename and show renamed file name like
foofoofoo = barbarbar, but if destination filename is long the line
is shortened like ...barbarbar so there is no way to know whether the
file is renamed or existed in the source commit.
This commit makes it visible like ...foo =
- Original Message -
From: Jeff King p...@peff.net
Sent: Thursday, October 10, 2013 1:36:28 PM
Subject: Re: A workflow for local patch maintenance
... snip ...
That being said, there are some new downsides, as you noted:
1. Resolving conflicts between your version and the
Hi,
I'm getting this warning:
warning: Could not find section in .gitmodules where path=XXX
whenever I use git mv to move a file in a repository containing a
submodule. The file is outside the submodule and is completely
unrelated, so I do not understand the intent of the warning.
My
On Fri, Oct 11, 2013 at 09:22:28AM -0400, Stephen Bash wrote:
To mitigate problem 1, I will sometimes revert a local topic before
doing the upstream merge, if I know it has been reworked.
Peff (slightly off topic) - A coworker of mine actually ran into this
problem earlier this week. Is
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Especially helpful when cherry-picking multiple commits.
t/t7512-status-help.sh | 10 ++
wt-status.c| 7 +--
wt-status.h| 1 +
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git
Ralf Thielow ralf.thie...@gmail.com writes:
Especially helpful when cherry-picking multiple commits.
I think this would deserve to be in the commit message (but don't
consider that blocking).
Other than that, looks good to me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To
Since 920b691 (clone: refuse to clone if --branch
points to bogus ref) we refuse to clone with option
-b if the specified branch does not exist in the
(non-empty) upstream. If the upstream repository is empty,
the branch doesn't exist, either. So refuse the clone too.
Signed-off-by: Ralf Thielow
Ralf Thielow wrote:
Especially helpful when cherry-picking multiple commits.
Neat, thanks.
[...]
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -626,9 +626,10 @@ test_expect_success 'prepare for cherry-pick conflicts' '
test_expect_success 'status when cherry-picking before
Hi Matthieu,
Am 11.10.2013 16:29, schrieb Matthieu Moy:
I'm getting this warning:
warning: Could not find section in .gitmodules where path=XXX
whenever I use git mv to move a file in a repository containing a
submodule. The file is outside the submodule and is completely
unrelated, so
On Fri, Oct 11, 2013 at 7:42 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ralf Thielow wrote:
Especially helpful when cherry-picking multiple commits.
Neat, thanks.
[...]
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -626,9 +626,10 @@ test_expect_success 'prepare for
Several uses of the '^' operator are being interpreted by asciidoc
as requests to show the following text as a superscript. In order
to fix this problem, use backticks (`) to quote the text of the
affected git command invocations.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi
On 10/11/2013 06:07 AM, Yoshioka Tsuneo wrote:
+ prefix_len = ((prefix_len = 0) ? prefix_len :
0);
+ strncpy(pre_arrow, arrow - prefix_len,
prefix_len);
+ pre_arrow[prefix_len] = '¥0';
This seems to be an
Passing to git clean wrong (non-existent) paths together with valid
ones, causes it to delete stuff that it shouldn't.
Am I right?
Script to reproduce:
mkdir test
cd test
git init .
mkdir ba
mkdir ba/ca
# So far so good.
# Should clean directory ba/ca
git clean -dn -- ba/ca
# Should clean
Hi.
Passing to git clean wrong (non-existent) paths together with valid
ones, causes it to delete stuff that it shouldn't.
Am I right?
Script to reproduce:
mkdir test
cd test
git init .
mkdir ba
mkdir ba/ca
# So far so good.
# Should clean directory ba/ca
git clean -dn -- ba/ca
# Should clean
The text contains two 'grep' invocations which include the 'start
of line' regular expression character '^'. Asciidoc mis-interprets
this use of '^' as a superscript request. In order to fix this
formatting problem, use backticks (`) to quote the text of the
affected 'grep' command invocations.
On Thu, Oct 10, 2013 at 01:14:28AM -0700, Shawn Pearce wrote:
If a large enough percentage of users are stuck behind a proxy that
doesn't support 100-continue, it is hard to rely on that part of HTTP
1.1. You need to build the work-around for them anyway, so you might
as well just make
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
Explain the reason for and behavior of the new http.continue option, and that it
is disabled 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
---
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.
Changes from v1:
* Default to disabled.
brian m. carlson (2):
http: add option to enable 100 Continue
brian m. carlson wrote:
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
brian m. carlson wrote:
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1516,6 +1516,15 @@ http.postBuffer::
massive pack file locally. Default is 1 MiB, which is
sufficient for most requests.
+http.continue::
+ Ensure that authentication succeeds
Richard Hansen wrote:
On 2013-09-09 18:49, Felipe Contreras wrote:
On Mon, Sep 9, 2013 at 4:23 PM, Richard Hansen rhan...@bbn.com wrote:
On 2013-09-08 21:23, Felipe Contreras wrote:
The old configurations still work, but get deprecated.
Should some tests for the deprecated configs be
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, Sep 9, 2013 at 9:21 PM, Jeff King p...@peff.net wrote:
On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote:
These deprecation warning messages should be written to stderr, and
should
On Fri, Oct 11, 2013 at 04:43:07PM -0700, Jonathan Nieder wrote:
By default means when allowed to make its own choice, right? (i.e.,
the behavior git never gave libcurl a chance to try :))
Makes sense.
Yes, at least according to Daniel Stenberg. I don't believe it is ever
triggered the way
On Fri, Oct 11, 2013 at 04:50:52PM -0700, Jonathan Nieder wrote:
brian m. carlson wrote:
+http.continue::
+ Ensure that authentication succeeds before sending the pack data when
+ POSTing data using the smart HTTP transport. This is done by
+ requesting a 100 Continue response.
On 2013-10-11 19:56, Felipe Contreras wrote:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, Sep 9, 2013 at 9:21 PM, Jeff King p...@peff.net wrote:
On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote:
These deprecation warning messages should be
The style for multi-line comments is often mentioned and should be documented
for clarity.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/CodingGuidelines | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/CodingGuidelines
On Fri, Oct 11, 2013 at 06:56:23PM -0500, Felipe Contreras wrote:
These deprecation warning messages should be written to stderr, and
should probably be prefixed with WARNING: .
Is there any deprecation warning that works this way?
The ones in C code typically use warning(),
On Fri, Oct 11, 2013 at 7:50 PM, Jeff King p...@peff.net wrote:
On Fri, Oct 11, 2013 at 06:56:23PM -0500, Felipe Contreras wrote:
These deprecation warning messages should be written to stderr, and
should probably be prefixed with WARNING: .
Is there any deprecation warning that
On Fri, Oct 11, 2013 at 08:15:46PM -0500, Felipe Contreras wrote:
You are free to go ahead and implement 'warning ()' in git-sh-setup.sh, in
the
meantime no shell script does that, and that's no reason to reject this
patch
series.
You are completely missing Matthieu's point that
On Fri, Oct 11, 2013 at 3:31 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Thu, Oct 10, 2013 at 01:14:28AM -0700, Shawn Pearce wrote:
Even if you want to live in the fairy land where all servers support
100-continue, I'm not sure clients should pay that 100-160ms latency
penalty
On Fri, Oct 11, 2013 at 8:25 PM, Jeff King p...@peff.net wrote:
On Fri, Oct 11, 2013 at 08:15:46PM -0500, Felipe Contreras wrote:
You are free to go ahead and implement 'warning ()' in git-sh-setup.sh,
in the
meantime no shell script does that, and that's no reason to reject this
patch
Hi,
Just wondering if this has been considered and dropped before.
Currently we use try_delta() for every object including trees. But
trees are special. All tree entries must be unique and sorted. That
helps simplify diff algorithm, as demonstrated by diff_tree() and
pv4_encode_tree(). A quick
I'm getting the following error when I do:
git send-email --compose --from Fernando Ortiz eratos2...@gmail.com --to
forti...@gmail.com --cc forti...@gmail.com
0001-Change-zcat-to-gzcat-to-fix-build-restore-steps.patch
Net::SSLeay version 1.46 required--this is only version 1.36 at
On 2013-10-11 22:08, Felipe Contreras wrote:
I'm fine with 'echo warning: foo 2', but still, if you really
cared about consistency, there would be a warn() function
So add one! It's only one simple line:
warning() { printf %s\\n warning: $* 2; }
So much discussion for something so
DiffMerge is a non-free (but gratis) tool that supports OS X, Windows and Linux.
See http://www.sourcegear.com/diffmerge/
DiffMerge includes a script `/usr/bin/diffmerge` that can be used to launch the
graphical compare tool.
This change adds mergetool support for DiffMerge and adds
Sam Vilain s...@vilain.net writes:
On 10/11/2013 06:07 AM, Yoshioka Tsuneo wrote:
+prefix_len = ((prefix_len = 0) ? prefix_len :
0);
+strncpy(pre_arrow, arrow - prefix_len,
prefix_len);
+
44 matches
Mail list logo
