On Fri, Oct 11, 2013 at 11:40 PM, Richard Hansen wrote:
> 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() { p
Sam Vilain 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);
>> +pre_arrow[prefix_len]
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 'diffmer
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
I'm getting the following error when I do:
git send-email --compose --from Fernando Ortiz --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
/Users/fortiz/perl5/perlbrew/per
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 and
On Fri, Oct 11, 2013 at 8:25 PM, Jeff King 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
>> >> p
On Fri, Oct 11, 2013 at 3:31 PM, brian m. carlson
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 during ancestor negoti
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 Matth
On Fri, Oct 11, 2013 at 7:50 PM, Jeff King 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
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
The style for multi-line comments is often mentioned and should be documented
for clarity.
Signed-off-by: brian m. carlson
---
Documentation/CodingGuidelines | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index e5ca3b7.
On 2013-10-11 19:56, Felipe Contreras wrote:
> Matthieu Moy wrote:
>> Felipe Contreras writes:
>>
>>> On Mon, Sep 9, 2013 at 9:21 PM, Jeff King wrote:
On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote:
>> These deprecation warning messages should be written to stderr,
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 respo
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
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > On Mon, Sep 9, 2013 at 9:21 PM, Jeff King 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 probably be prefixed with "
Richard Hansen wrote:
> On 2013-09-09 18:49, Felipe Contreras wrote:
> > On Mon, Sep 9, 2013 at 4:23 PM, Richard Hansen 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 ad
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 succee
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 ht
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 response
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
---
Documentation/config.txt | 9 +
1 fi
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
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 ever
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.
S
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
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 "b
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 b
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
---
Hi Jonathan,
Just noticed this
On Fri, Oct 11, 2013 at 7:42 PM, Jonathan Nieder 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 cherry-pi
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
> unrel
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 bef
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 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 unsubscribe from this list: send
Signed-off-by: Ralf Thielow
---
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 a/t/t7512-status-help.sh b/t/t7512-s
- Original Message -
> From: "Jeff King"
> To: "Stephen Bash"
> Cc: git@vger.kernel.org, "Tony Finch"
> Sent: Friday, October 11, 2013 11:16:14 AM
> Subject: Re: A workflow for local patch maintenance
>
> On Fri, Oct 11, 2013 at 09:22:28AM -0400, Stephen Bash wrote:
>
> > > To mitigate
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
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 unders
- Original Message -
> From: "Jeff King"
> 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 reworke
"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 ".
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()
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 r
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 (e
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
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 --prefix='
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% (
"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 ".
On Wed, Oct 9, 2013 at 11:11 PM, Jonathan Nieder wrote:
> Paolo Giarrusso wrote:
>
>> Seeing the email, I wonder whether there's hope something like that
>> can be preserved in an email, and whether the code should use some
>> escape sequence instead.
>
> Yes, please. Mind if I amend it to
>
>
47 matches
Mail list logo
