From: "Junio C Hamano"
Philip Oakley 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
---
This updates 431260cc8dd
It appears that the original has already been merged to 'next', so
w
On Tue, Oct 15, 2013 at 11:03:26PM -0500, Felipe Contreras wrote:
> > not some "next" behavior that may change in future.
>
> But I'm suggesting to add a core.addremove option as well, like you suggested,
> am I not?
Yes, I think we both agreed on adding core.addremove. I'm just not
convinced if
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,
John Szakmeister wrote:
> On Tue, Oct 15, 2013 at 10:51 AM, 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:
> >> > >
Junio C Hamano wrote:
> Jeff King 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
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Signed-off-by: Felipe Contreras
> > ---
>
> 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 the end r
From: Brandon Casey
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: Brandon Casey
---
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
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
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 reason
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
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 op
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_ex
On Tue, 15 Oct 2013, Junio C Hamano wrote:
> Nicolas Vigier 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.
> >
> >
Jonathan Nieder 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 shou
Jonathan Nieder 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 f
Junio C Hamano wrote:
> From: Felipe Contreras
> 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 changed, 5 inser
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
Ramsay Jones 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 http://vger.kernel.org/majordomo-info.html
Junio C Hamano writes:
> Yoshioka Tsuneo 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
Nicolas Vigier 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 /tmp/opt.sh
> #!/bin/
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 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 source commit.
Steffen Prohaska writes:
> Labeled lists require a double colon.
>
> Signed-off-by: Steffen Prohaska
> ---
Looks sensible; it would have been nicer if the log message said
something like
I eyeballed the output from
git grep '[^:]:$' Documentation/\*.txt
and these are the only
Junio C Hamano writes:
> Roberto Tyley 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
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
Roberto Tyley 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 entires to the
> re
Jeff King 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 "ch
Felipe Contreras writes:
> Signed-off-by: Felipe Contreras
> ---
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 the end result does not have a potentially cumberso
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 upda
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 push.default=simple sets exact
b
Philip Oakley 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
> ---
>
> This updates 431260cc8dd
It appears that the original has already been merged to 'next', so
we need to make t
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 arg
Jeff King 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 additio
Nicolas Pitre 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.
>> index
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 h
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,
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 wh
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 re
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 experienc
Jeff King 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 understand than thre
Jonathan Nieder 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 resolution,
- reconstruc
On Tue, Oct 15, 2013 at 10:52:55AM -0700, Junio C Hamano wrote:
> Jeff King 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 thin
Jeff King 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 pass
On Tue, Oct 15, 2013 at 10:51 AM, 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 af
Le 15 oct. 2013 à 01:35, Eric Wong a écrit :
> Jeff King wrote:
>> On Mon, Oct 14, 2013 at 06:40:05PM +, Eric Wong wrote:
>>
arnaud.brej...@gmail.com wrote:
> Signed-off-by: Arnaud Brejeon gmail.com>
Thanks.
Can you say a little more about the context?
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 witho
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
>
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
Hi,
On Fri, Oct 11, 2013 at 10:42:10AM -0700, Jonathan Nieder wrote:
> -- >8 --
> Subject: status test: add missing && to <
> 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 "succ
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=
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 m
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 v
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
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 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[], --gpg-sign[=]'
> > to git-rebase, similar to the option in git-
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
renewal
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
wrote:
> On Tue, Oct 15, 2013 at 4:45 AM, Yoshioka Tsuneo
> wrote:
>>
>> "g
"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
On Tue, Oct 15, 2013 at 4:45 AM, Yoshioka Tsuneo
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 is renamed o
Hello Thomas
Thank you very much for your kind review.
Now, I just posted "PATCH v4" that will include your suggestion like keeping
"{", "}"
while omitting, improving commit message and comment, and test.
Thanks!
---
Tsuneo Yoshioka (吉岡 恒夫)
yoshiokatsu...@gmail.com
On Oct 13, 2013, at 11:2
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
"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
On 15.10.13 02:12, Jeff King wrote:
> On Sun, Oct 13, 2013 at 10:00:12PM +0200, Torsten Bögershausen wrote:
>
>> On 05.10.13 21:48, Torsten Bögershausen wrote:
>>> On 2013-10-03 03.31, Jeff King wrote:
http://article.gmane.org/gmane.comp.version-control.git/235473
>> What do we think a
64 matches
Mail list logo
