Jeff King p...@peff.net wrote:
I am more concerned with Windows, which may not compile your original
patch at all.
The code I introduced in e47a8583a20256851e7fc882233e3bd5bf33dc6e
(enable SO_KEEPALIVE for connected TCP sockets Dec 2011)
didn't trigger the addition of any new #ifdef guards. I
Hello Duy
Thank you very much your suggestion.
As you suggested, I tried to reuse intermediate result of pprint_rename(),
instead of
parsing the output again.
I just posted the new patch as PATCH v4
Thanks !
---
Tsuneo Yoshioka (吉岡 恒夫)
yoshiokatsu...@gmail.com
On Oct 14, 2013, at 10:04 PM,
On Tue, Oct 15, 2013 at 4:45 AM, Yoshioka Tsuneo
yoshiokatsu...@gmail.com wrote:
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
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.
Make sure there is always an arrow, like
Hello Felipe
Thank you for pointing out the style issue again.
I just fixed it and posted as [PATCH v5].
Thanks!
---
Tsuneo Yoshioka (吉岡 恒夫)
yoshiokatsu...@gmail.com
On Oct 15, 2013, at 1:07 PM, Felipe Contreras felipe.contre...@gmail.com
wrote:
On Tue, Oct 15, 2013 at 4:45 AM, Yoshioka
Greetings,
How are you and the family?
My contacting you again is based on neglecting my previous email of
investment establishment in your country.
Be aware that I am in a desire of any investments establishment that
will guaranty a safe and secured profitable returns in terms of energy
On Mon, 14 Oct 2013, brian m. carlson wrote:
On Mon, Oct 14, 2013 at 05:25:29PM +0200, Nicolas Vigier wrote:
The reason that I looked at this documentation in the first place was
that I was looking at adding an option '-S[keyid], --gpg-sign[=keyid]'
to git-rebase, similar to the option in
git rev-parse --parseopt does not allow us to see the difference
between an option with an optional argument starting with a dash, and an
option with an unset optional argument followed by an other option.
If I use this script :
$ cat /tmp/opt.sh
#!/bin/sh
OPTIONS_SPEC=\
git [options]
On Thu, Oct 10, 2013 at 04:43:22PM +0200, Julien Carsique wrote:
It's fixed.
Thanks, the updated patch looks good to me.
Note '+=' was already used line 114:
svn_url_pattern+=\\|$value
I guess noone has tried to use the upstream status indicator with an
SVN upstream and an
On Mon, Oct 14, 2013 at 04:35:50PM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote:
So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre v2.0 behave as Git v2.0.
Krzysztof Mazur wrote:
On Mon, Oct 14, 2013 at 04:35:50PM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote:
So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre
On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
But with core.mode = next after upgrade you may experience incompatible
change without any warning.
Yes, and that is actually what the user wants. I mean, why would the user set
core.mode=next, if
Hi,
On Fri, Oct 11, 2013 at 10:42:10AM -0700, Jonathan Nieder wrote:
-- 8 --
Subject: status test: add missing to EOF blocks
When a test forgets to include after each command, it is possible
for an early command to succeed but the test to fail, which can hide
bugs.
Surely you meant
Krzysztof Mazur wrote:
On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
But with core.mode = next after upgrade you may experience incompatible
change without any warning.
Yes, and that is actually what the user wants. I mean, why would the
On 15/10/13 00:25, Jonathan Nieder wrote:
Ramsay Jones wrote:
These patches don't have too much in common, hence the subject
line, except perhaps that 4 of them fix sparse warnings.
Thanks. These look good.
I tweaked the descriptions a bit to focus on what sparse was warning
about
On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
But with core.mode = next after upgrade you may experience incompatible
change without any warning.
Le 15 oct. 2013 à 01:35, Eric Wong normalper...@yhbt.net a écrit :
Jeff King p...@peff.net wrote:
On Mon, Oct 14, 2013 at 06:40:05PM +, Eric Wong wrote:
arnaud.brej...@gmail.com wrote:
Signed-off-by: Arnaud Brejeon arnaud.brejeon at gmail.com
Thanks.
Can you say a little more
On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur krzys...@podlesie.net wrote:
On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
But with core.mode = next
Jeff King p...@peff.net writes:
Yeah, unrolling the loop is probably better. You may even be able
to do so in a single pass with an extra last seen pointer
variable without too much additional code complexity, I would think.
I'm not sure what you mean here.
If you mean doing a single
On Tue, Oct 15, 2013 at 10:52:55AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Yeah, unrolling the loop is probably better. You may even be able
to do so in a single pass with an extra last seen pointer
variable without too much additional code complexity, I would
Jonathan Nieder jrnie...@gmail.com writes:
What's cooking in git.git (Oct 2013, #02; Mon, 14)
Tying up loose ends before the hand-off.
I'll try:
- slurping your integration branches,
- teasing the topics apart out of your 'pu',
- populating my rerere database to match your confict
Jeff King p...@peff.net writes:
My version seems a little clearer to me, but that is probably because I
wrote it. If you strongly prefer the other, feel free to mark up my
patch.
I do not have strong preference either way. Just that I thought two
loops would be shorter and easier to
Krzysztof Mazur wrote:
On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
But with core.mode = next after upgrade you may experience
Junio C Hamano wrote:
I'll try:
- slurping your integration branches,
- teasing the topics apart out of your 'pu',
- populating my rerere database to match your confict resolution,
- reconstructing the Meta/Reintegrate insn for 'pu', and
- rebuilding 'pu' to make sure the end result
Am 15.10.2013 02:12, schrieb Jonathan Nieder:
* jl/submodule-mv (2013-10-13) 1 commit
- mv: Fix spurious warning when moving a file in presence of submodules
Moving a regular file in a repository with a .gitmodules file was
producing a warning 'Could not find section in .gitmodules where
Am 15.10.2013 21:16, schrieb Jonathan Nieder:
So I suspect this will fix more scripts than it breaks, though it may
still break some. :/
Hmm, I'm really not sure if we should do this or not.
It might make sense to warn when passed multiple arguments and some
include shell metacharacters,
Jens Lehmann wrote:
Am 15.10.2013 21:16, schrieb Jonathan Nieder:
So I suspect this will fix more scripts than it breaks, though it may
still break some. :/
Hmm, I'm really not sure if we should do this or not.
What convinced me was Anders's observation that the current behavior
can have
Nicolas Pitre n...@fluxnic.net writes:
On Sat, 21 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
This contains many bug fixes or cleanups. Also you can now run the
test suite with v4 by setting GIT_TEST_OPTS=--packv4. The test suite
passes now. pack size limit is not officially not supported with v4.
Jeff King p...@peff.net writes:
I wondered if we might also leak when seeing duplicate config options
(i.e., leaking the old one when replacing it with the new). But we don't
actually strdup() the configured remote names, but instead just point
into the struct branch, which owns the data.
In
Commit 1bbcc224 (http: refactor options to http_get_*, 28-09-2013)
changed the type of final 'options' argument of the http_get_file()
function from an int to an 'struct http_get_options' pointer.
However, it neglected to update the (single) call site. Since this
call was passing '0' to that
Philip Oakley philipoak...@iee.org writes:
The Git cli will accept dot '.' (period) as the relative path,
and thus the current repository. Explain this action.
Signed-off-by: Philip Oakley philipoak...@iee.org
---
This updates 431260cc8dd
It appears that the original has already been
On Tue, Oct 15, 2013 at 10:55:02PM +0100, Ramsay Jones wrote:
Commit 1bbcc224 (http: refactor options to http_get_*, 28-09-2013)
changed the type of final 'options' argument of the http_get_file()
function from an int to an 'struct http_get_options' pointer.
However, it neglected to update
Felipe Contreras felipe.contre...@gmail.com writes:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Let's do something like this instead.
- We usually refrain from making such a tree-wide change in order
to avoid unnecessary conflicts with other real work patches,
but
Jeff King p...@peff.net writes:
It seems[1] that some
people define ci as commit -a, and some people define st as
status -s or even status -sb.
These option variants aside.
Just like thinking that committing must be the same as publishing,
it is a cvs/svn induced braindamage to think that
Roberto Tyley roberto.ty...@gmail.com writes:
On 21/09/2013 23:16, Keshav Kini wrote:
[SNIP]
This situation came about because the BFG Repo-Cleaner doesn't write new
reflog entries after creating its new objects and moving refs around.
True enough - I don't think the BFG does write new
This seems to post-date what Jonathan has kept in his 'pu'; is this
the latest (I have a huge backlog to wade through, so I'd rather
skip it if another reroll is coming and move on to other topics).
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
Junio C Hamano gits...@pobox.com writes:
Roberto Tyley roberto.ty...@gmail.com writes:
On 21/09/2013 23:16, Keshav Kini wrote:
[SNIP]
This situation came about because the BFG Repo-Cleaner doesn't write new
reflog entries after creating its new objects and moving refs around.
True enough
Steffen Prohaska proha...@zib.de writes:
Labeled lists require a double colon.
Signed-off-by: Steffen Prohaska proha...@zib.de
---
Looks sensible; it would have been nicer if the log message said
something like
I eyeballed the output from
git grep '[^:]:$' Documentation/\*.txt
On 10/15/2013 3:40 PM, Junio C Hamano wrote:
This seems to post-date what Jonathan has kept in his 'pu'; is this
the latest (I have a huge backlog to wade through, so I'd rather
skip it if another reroll is coming and move on to other topics).
Thanks.
This is the latest.
I didn't have
Yoshioka Tsuneo yoshiokatsu...@gmail.com writes:
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
Nicolas Vigier bo...@mars-attacks.org writes:
git rev-parse --parseopt does not allow us to see the difference
between an option with an optional argument starting with a dash, and an
option with an unset optional argument followed by an other option.
If I use this script :
$ cat
Junio C Hamano gits...@pobox.com writes:
Yoshioka Tsuneo yoshiokatsu...@gmail.com writes:
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
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Also, I note that ma...@kernel.org != ma...@repo.or.cz/jrn
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Nicolas Vigier wrote:
$ cat /tmp/opt.sh
#!/bin/sh
OPTIONS_SPEC=\
git [options]
--
q,quiet be quiet
S,gpg-sign? GPG-sign commit
echo $OPTIONS_SPEC | git rev-parse --parseopt $parseopt_extra -- $@
Then the following two commands give us the same result :
$
Junio C Hamano wrote:
From: Felipe Contreras felipe.contre...@gmail.com
Subject: C: have space around and || operators
[...]
builtin/read-tree.c| 2 +-
builtin/rev-list.c | 2 +-
builtin/symbolic-ref.c | 2 +-
compat/regex/regcomp.c | 2 +-
xdiff/xemit.c | 2 +-
5 files
Jonathan Nieder jrnie...@gmail.com writes:
Nicolas Vigier wrote:
$ cat /tmp/opt.sh
#!/bin/sh
OPTIONS_SPEC=\
git [options]
--
q,quiet be quiet
S,gpg-sign? GPG-sign commit
echo $OPTIONS_SPEC | git rev-parse --parseopt $parseopt_extra -- $@
Then the following
Jonathan Nieder jrnie...@gmail.com writes:
- dfa-nodes[node].type == CHARACTER
+ dfa-nodes[node].type == CHARACTER
It took a little staring to see what changed here. The preimage has
a tab, probably from an autoformatter gone wild. I don't think fixing
it
On Tue, 15 Oct 2013, Junio C Hamano wrote:
Nicolas Vigier bo...@mars-attacks.org writes:
git rev-parse --parseopt does not allow us to see the difference
between an option with an optional argument starting with a dash, and an
option with an unset optional argument followed by an other
On Tue, 15 Oct 2013, Jonathan Nieder wrote:
Nicolas Vigier wrote:
$ cat /tmp/opt.sh
#!/bin/sh
OPTIONS_SPEC=\
git [options]
--
q,quiet be quiet
S,gpg-sign? GPG-sign commit
echo $OPTIONS_SPEC | git rev-parse --parseopt $parseopt_extra -- $@
Then
Junio C Hamano wrote:
You just made these two that the user clearly meant to express two
different things indistinguishable.
opt.sh -S
opt.sh -S ''
[...]
And that is exactly why gitcli.txt tells users to use the 'sticked'
form, and ends the bullet point with:
An option
The test 'choking git rm should not let it die with cruft' is
supposed to check 'git rm's behavior when interrupted by provoking a
SIGPIPE while 'git rm' is busily deleting files from a specially
crafted index.
This test is silently broken for the following reasons:
- The test crafts a special
SZEDER Gábor wrote:
The test 'choking git rm should not let it die with cruft' is
supposed to check 'git rm's behavior when interrupted by provoking a
SIGPIPE while 'git rm' is busily deleting files from a specially
crafted index.
This test is silently broken for the following reasons:
On Tue, Oct 15, 2013 at 05:18:04PM -0700, Jonathan Nieder wrote:
SZEDER Gábor wrote:
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -240,18 +240,15 @@ test_expect_success 'refresh index before checking if
it is up-to-date' '
test_expect_success 'choking git rm should not let it die
The test 'choking git rm should not let it die with cruft' is
supposed to check 'git rm's behavior when interrupted by provoking a
SIGPIPE while 'git rm' is busily deleting files from a specially
crafted index.
This test is silently broken for the following reasons:
- The test crafts a special
From: Brandon Casey draf...@gmail.com
The setting of denyDeleteCurrent applies to both bare and non-bare
repositories. Correct the description on this point, and expand it to
provide some background justification for the current behavior and
describe the full suite of settings.
Signed-off-by:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Let's do something like this instead.
- We usually refrain from making such a tree-wide change in order
to avoid unnecessary conflicts with
Junio C Hamano wrote:
Jeff King p...@peff.net writes:
It seems[1] that some
people define ci as commit -a, and some people define st as
status -s or even status -sb.
These option variants aside.
Just like thinking that committing must be the same as publishing,
it is a cvs/svn
John Szakmeister wrote:
On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur krzys...@podlesie.net
wrote:
On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
Krzysztof Mazur wrote:
Krzysztof Mazur wrote:
On Tue, Oct 15, 2013 at 01:51:41PM -0500, Felipe Contreras wrote:
I don't see what is the problem. We haven't had the need for push.default =
simplewarning, have we? If you want the warning, you don't change anything,
if
simplewarning makes no sense, because
59 matches
Mail list logo
