On Mon, Jun 10, 2013 at 04:23:31PM -0700, Junio C Hamano wrote:
> OK, I pushed out a result of some renaming and rebasing. Notable
> changes are:
>
> - The data and API is called prio-queue and they live in prio-queue.[ch];
>
> - The test script is also named test-prio-queue.c, to leave the
>
On Mon, Jun 10, 2013 at 11:41 PM, Michael Haggerty wrote:
> On 06/10/2013 03:28 PM, Ramkumar Ramachandra wrote:
>> I've tried to write down a bare minimum, without restating the obvious.
>
> Thank you for drafting a proposed CommunityGuidelines document; I think
> such a document would be helpful.
On Mon, Jun 10, 2013 at 8:28 AM, Ramkumar Ramachandra
wrote:
> I've tried to write down a bare minimum, without restating the obvious.
I think there's an even more important number 0:
Always assume good faith. When discussing through digital mediums,
it's very easy to misconstrue the tone and in
On Mon, Jun 10, 2013 at 12:42 PM, Junio C Hamano wrote:
> "Robin H. Johnson" writes:
>
>> On Mon, Jun 10, 2013 at 04:04:29PM +0200, Matthieu Moy wrote:
>>> Célestin Matte writes:
>>>
>>> > Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
>>> >> 0. You do not take offense, no matter what. If
On Mon, Jun 10, 2013 at 11:37 PM, Martin von Zweigbergk
wrote:
> On Sun, Jun 9, 2013 at 9:40 AM, Felipe Contreras
> wrote:
>> Signed-off-by: Felipe Contreras
>> ---
>> t/t3425-rebase-topology-merges.sh | 15 ++-
>> 1 file changed, 6 insertions(+), 9 deletions(-)
>>
>> diff --git a/t
On 06/10/2013 03:28 PM, Ramkumar Ramachandra wrote:
> I've tried to write down a bare minimum, without restating the obvious.
Thank you for drafting a proposed CommunityGuidelines document; I think
such a document would be helpful. But I don't like the overall flavor
of your proposal; frankly, it
On Sun, Jun 9, 2013 at 9:40 AM, Felipe Contreras
wrote:
> Signed-off-by: Felipe Contreras
> ---
> t/t3425-rebase-topology-merges.sh | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/t/t3425-rebase-topology-merges.sh
> b/t/t3425-rebase-topology-merges.sh
>
On Mon, Jun 10, 2013 at 8:53 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> And I do not see the reason why builtin/*.o should not depend on
>> each other. It is not messed up at all. They are meant to be
>> linked into a single binary---that is what being "built-in" is.
>>
>> A good w
On Mon, Jun 10, 2013 at 7:04 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> *1* ... which is a very reasonable thing to do. But moving
>>> sequencer.o to builtin/sequencer.o is *not* the way to do this.
>>
>> By now we all know what is the *CURRENT* way to do this; in other
>> wo
On Mon, Jun 10, 2013 at 8:09 PM, Phil Hord wrote:
> On Mon, Jun 10, 2013 at 7:43 PM, Felipe Contreras
> wrote:
>> On Mon, Jun 10, 2013 at 5:55 PM, Phil Hord wrote:
>>> On Sun, Jun 9, 2013 at 3:37 PM, Felipe Contreras
>>> wrote:
On Sun, Jun 9, 2013 at 2:24 PM, Felipe Contreras
wr
Junio C Hamano writes:
> And I do not see the reason why builtin/*.o should not depend on
> each other. It is not messed up at all. They are meant to be
> linked into a single binary---that is what being "built-in" is.
>
> A good way forward, the way it *SHOULD* be, is to slim the builtin/*.o
>
Отправлено с iPhone пл
On Mon, Jun 10, 2013 at 7:43 PM, Felipe Contreras
wrote:
> On Mon, Jun 10, 2013 at 5:55 PM, Phil Hord wrote:
>> On Sun, Jun 9, 2013 at 3:37 PM, Felipe Contreras
>> wrote:
>>>
>>> On Sun, Jun 9, 2013 at 2:24 PM, Felipe Contreras
>>> wrote:
>>> > Same as before, but:
>>>
>>> Also, remove the patc
Отправлено с iPhone
Felipe Contreras writes:
>> *1* ... which is a very reasonable thing to do. But moving
>> sequencer.o to builtin/sequencer.o is *not* the way to do this.
>
> By now we all know what is the *CURRENT* way to do this; in other
> words, the status quo, which is BTW all messed up, because builtin
On Mon, Jun 10, 2013 at 6:41 PM, Junio C Hamano wrote:
> For the particular case of trying to make sequencer.o, which does
> not currently have dependencies on builtin/*.o, depend on something
> that is in builtin/notes.o, the link phase of standalone that wants
> anything from revision.o (which
On Mon, Jun 10, 2013 at 5:55 PM, Phil Hord wrote:
> On Sun, Jun 9, 2013 at 3:37 PM, Felipe Contreras
> wrote:
>>
>> On Sun, Jun 9, 2013 at 2:24 PM, Felipe Contreras
>> wrote:
>> > Same as before, but:
>>
>> Also, remove the patches from Martin von Zweigbergk, because
>> apparently some people ha
Junio C Hamano writes:
> Jeff King writes:
>
>> My general impression of the goal of our current code organization is:
>>
>> 1. builtin/*.c should each contain a single builtin command and its
>> supporting static functions. Each file gets linked into git.o to
>> make the "main" git
Отправлено с iPhonegmail--
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
Jeff King writes:
> On Mon, Jun 10, 2013 at 11:56:33AM -0700, Junio C Hamano wrote:
>
>> > or similar. I didn't change the name, either. It may be silly to call it
>> > "commit_queue" still since it is now more general. I simply called mine
>> > "queue" (I wanted "pqueue", but that conflicted wit
Jeff King writes:
> My general impression of the goal of our current code organization is:
>
> 1. builtin/*.c should each contain a single builtin command and its
> supporting static functions. Each file gets linked into git.o to
> make the "main" git executable.
Correct; that is wha
On Tue, Jun 11, 2013 at 12:57 AM, Junio C Hamano wrote:
> [PATCH 1/6] templates: Fewer subprocesses in pre-commit hook
>
> I agree with Peff that "less fork" is a bad justification for this
> change, and also
>
> echo 'First line
> second line
> third lie'
>
>
Richard Hartmann writes:
> On Mon, Jun 10, 2013 at 9:52 PM, Junio C Hamano wrote:
>
>
>> I think offsetting the actual commands to the right is correct, but
>> "if these match" and "if this is empty" should be flushed to left as
>> this patch shows.
>
> I actually considered this and decided aga
On Sun, Jun 9, 2013 at 3:37 PM, Felipe Contreras
wrote:
>
> On Sun, Jun 9, 2013 at 2:24 PM, Felipe Contreras
> wrote:
> > Same as before, but:
>
> Also, remove the patches from Martin von Zweigbergk, because
> apparently some people have trouble understanding that they were not
> part of this ser
On Mon, Jun 10, 2013 at 5:06 PM, Jeff King wrote:
> On Mon, Jun 10, 2013 at 04:52:57PM -0500, Felipe Contreras wrote:
>
>> On Mon, Jun 10, 2013 at 4:45 PM, Jeff King wrote:
>>
>> > That is what libgit.a _is_ now. I do not mean to imply any additional
>> > judgement on what it could be. But if th
On Mon, Jun 10, 2013 at 04:52:57PM -0500, Felipe Contreras wrote:
> On Mon, Jun 10, 2013 at 4:45 PM, Jeff King wrote:
>
> > That is what libgit.a _is_ now. I do not mean to imply any additional
> > judgement on what it could be. But if the goal is to make libgit.a
> > "functions that programs o
On Mon, Jun 10, 2013 at 10:46:38PM +0100, John Keeping wrote:
> > Overall, I think respecting diff.algorithm in add--interactive is a very
> > sane thing to do. I would even be tempted to say we should allow a few
> > other select diff options (e.g., fewer or more context lines). If you
> > allowe
On Mon, Jun 10, 2013 at 4:45 PM, Jeff King wrote:
> That is what libgit.a _is_ now. I do not mean to imply any additional
> judgement on what it could be. But if the goal is to make libgit.a
> "functions that programs outside git.git would want, and nothing else",
> we may want to additionally s
On Mon, Jun 10, 2013 at 9:52 PM, Junio C Hamano wrote:
> I think offsetting the actual commands to the right is correct, but
> "if these match" and "if this is empty" should be flushed to left as
> this patch shows.
I actually considered this and decided against it as it seemed to be
deliberate
On Mon, Jun 10, 2013 at 3:07 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> I think that's the only way forward, since the Git project doesn't
>> wish to be improved.
>>
>> Perhaps it's time for me to create a pseudonym, and when you have to
>> do that to land clearly good patches, y
On Mon, Jun 10, 2013 at 05:11:41PM -0400, Jeff King wrote:
> On Mon, Jun 10, 2013 at 12:28:55PM -0700, Junio C Hamano wrote:
> > John Keeping writes:
> >
> > > I think the first thing to do is read the "diff.algorithm" setting in
> > > git-add--interactive and pass its value to the underlying dif
On Sun, Jun 09, 2013 at 07:30:31PM +0200, Vincent van Ravesteijn wrote:
> I think that libgit.a should contain all code to be able to carry out
> all functions of git. The stuff in builtin/ is just a command-line
> user interface. Whether or not sequencer should be in builtin depends
> on whether
Antoine Pelisse writes:
> On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano wrote:
>> When any ignore blank option is used, there will be lines that
>> actually has changes (hence should be shown with +/-) but we
>> deliberately ignore their changes (hence, if they ever appear in the
>> hunk, they
On Mon, Jun 10, 2013 at 12:34 PM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> It is not bad behavior. It is bad behavior *in your opinion*,
>
> And in essentially everyone else on this list, it seems.
So? An opinion shared by a billion people is still an opinion, not a
fact. To think oth
On Mon, Jun 10, 2013 at 1:11 PM, Martin von Zweigbergk
wrote:
> On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
> wrote:
>> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
>> wrote:
>>
You need two sides to have an argument.
>>
>>> I disagree. Unless you mean than, whenever a part beh
On Mon, Jun 10, 2013 at 08:36:04PM +0200, Richard Hartmann wrote:
> The example assumes 8-char wide tabs and breaks for people with
> 4-char wide tabs.
If you end up re-rolling, it might be worth saying "Let's just convert
all of the tabs to spaces" in the commit message. I was curious what
your
On Mon, Jun 10, 2013 at 08:36:00PM +0200, Richard Hartmann wrote:
> Spawning a new subprocess for every line printed is inefficient.
> Thus spawn only one instance of `echo`.
Most modern shells have "echo" as a built-in these days, and do not fork
at all to run it. E.g., try "strace sh -c 'echo f
On Mon, Jun 10, 2013 at 12:28:55PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > I think the first thing to do is read the "diff.algorithm" setting in
> > git-add--interactive and pass its value to the underlying diff-index and
> > diff-files commands, but should we also have a comma
On 06/10/2013 04:56 PM, Ramkumar Ramachandra wrote:
A Large Angry SCM wrote:
It is absolutely imperative to keep all our contributors productive,
and maximize output.
Why?
A useful "product" with a maintainable code base are what seems to be more
important to a successful open source effort.
The latest maintenance release Git v1.8.3.1 is now available at the
usual places.
This is primarily to push out fixes to two regressions that seem to
affect many people, namely, the ".gitignore !directory" bug and the
"daemon cannot read from $HOME owned by root" bug.
The release tarballs are fou
On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano wrote:
> When any ignore blank option is used, there will be lines that
> actually has changes (hence should be shown with +/-) but we
> deliberately ignore their changes (hence, if they ever appear in the
> hunk, they do so as context lines prefixed
A Large Angry SCM wrote:
>> It is absolutely imperative to keep all our contributors productive,
>> and maximize output.
>
>
> Why?
>
> A useful "product" with a maintainable code base are what seems to be more
> important to a successful open source effort.
Doesn't a successful open source effort
Matthieu Moy writes:
> Junio C Hamano writes:
>
>>> +{
>>> + if (files_list->nr) {
>>> + struct strbuf err_msg = STRBUF_INIT;
>>> + int i;
>>> + strbuf_addstr(&err_msg, main_msg);
>>> + for (i = 0; i < files_list->nr; i++)
>>> + strbuf_
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
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
SZEDER Gábor writes:
> Anyway. Although the completion script in Fedora's gvfs package might
> be fixed, there are other completion scripts making the same mistake,
> so I'm afraid we should keep the workaround and drop this patch.
> Moreover, we should even consider extending our workaround by
On 06/10/2013 03:45 PM, Ramkumar Ramachandra wrote:
[...]
It is absolutely imperative to keep all our contributors productive,
and maximize output.
Why?
A useful "product" with a maintainable code base are what seems to be
more important to a successful open source effort.
A Large Angry S
On Sun, Jun 09, 2013 at 11:30:01AM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] test: test_output_must_be_empty helper
>
> There are quite a lot places where an output file is expected to be
> empty, and we fail the test when it is not. The output from running
> the test script wit
Hi Junio,
if you want a new patch, just say the word.
Richard
--
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
On Mon, Jun 10, 2013 at 09:07:06PM +0200, Johannes Sixt wrote:
> Am 10.06.2013 19:27, schrieb SZEDER Gábor:
> > My main motivation is that, like in your example, in the bash prompt
> > tests I only have to check a single line of output, but because of
> > debuggability I always did:
> >
> > echo
Felipe Contreras wrote:
> I think that's the only way forward, since the Git project doesn't
> wish to be improved.
>
> Perhaps it's time for me to create a pseudonym, and when you have to
> do that to land clearly good patches, you know something is *REALLY*
> wrong with the project.
I ask only f
Richard Hartmann writes:
> The other hooks use two whitespace for indentation instead of tabs
> to signify code in the example/echo output.
> Follow the same layout in templates/hooks--pre-rebase.sample
>
> Signed-off-by: Richard Hartmann
> ---
> templates/hooks--pre-rebase.sample | 10 +-
Richard Hartmann writes:
> The example assumes 8-char wide tabs and breaks for people with
> 4-char wide tabs.
Even though as far as this project is concerned, a tab stop is every
8 columns, this is for consumption by end-users who use Git, not for
people who want to improve the code in Git (whi
Richard Hartmann writes:
> Now that the there's only one echo being spawned, the message can span
> the full 80 chars.
>
> Signed-off-by: Richard Hartmann
> ---
> templates/hooks--pre-commit.sample |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/templates/hooks
Jonathan Nieder wrote:
> I don't think most bystanders would misunderstand if I let a certain
> person alone instead of responding and saying "You are being
> unproductive. Please stop." But that certain person seems to
> misunderstand, whether I say that or not. So when I lose patience I
> say
Richard Hartmann writes:
> Spawning a new subprocess for every line printed is inefficient.
> Thus spawn only one instance of `echo`.
>
> Signed-off-by: Richard Hartmann
> ---
> templates/hooks--pre-commit.sample | 24
> 1 file changed, 12 insertions(+), 12 deletions(
John Keeping writes:
> I think the first thing to do is read the "diff.algorithm" setting in
> git-add--interactive and pass its value to the underlying diff-index and
> diff-files commands, but should we also have a command line parameter to
> git-add to specify the diff algorithm in interactive
SZEDER Gábor writes:
> With such a helper function this could be reduced to a single line:
>
> test_string_equal "(master)" "$(__git_ps1)"
>
> without loss of functionality or debuggability, because in case of a
> failure it would output something like this (bikesheddable, of
> course):
>
> E
Ramkumar Ramachandra writes:
>> I am not saying that you have to pick one to use for push.default
>> among the remaining ones (i.e. matching, current, what else?). It
>> is very plausible that the triangular workflow wants a different
>> logic to pick what branches are to be updated and how. Pe
Am 10.06.2013 19:27, schrieb SZEDER Gábor:
> My main motivation is that, like in your example, in the bash prompt
> tests I only have to check a single line of output, but because of
> debuggability I always did:
>
> echo "(master)" >expected
> __git_ps1 >actual
> test_cmp expected actual
C
Junio C Hamano wrote:
> 0. You do not take offense, no matter what. If someone attacks
> you irrationally, you do not respond. This is a public mailing
> list, and we are all rational people: the attacker has already
> humiliated herself in public, and everyone can see that.
[...
Matthieu Moy writes:
> Please, don't top-post. Quote the part of the message you're replying
> to, and reply below.
>
> Benoît Person writes:
>
>> Well, I think next step would be to replace all those calls with
>> Git.pm `command`, `command_oneline` and `config``which take an array
>> of argume
On Mon, Jun 10, 2013 at 11:56:33AM -0700, Junio C Hamano wrote:
> > or similar. I didn't change the name, either. It may be silly to call it
> > "commit_queue" still since it is now more general. I simply called mine
> > "queue" (I wanted "pqueue", but that conflicted with globals defined by
> > O
Jeff King writes:
> On Mon, Jun 10, 2013 at 12:21:00AM -0700, Junio C Hamano wrote:
>
>> > It may be worth looking again for other places to use this over
>> > commit_list, but even the caller you are introducing here justifies its
>> > presence.
>>
>> The next candidate is paint-down-to-common,
On Mon, Jun 10, 2013 at 12:39:24AM -0700, Junio C Hamano wrote:
> > I'm not excited about introducing yet another place that parses commit
> > objects (mostly not for correctness, but because we have had
> > inconsistency in how malformed objects are treated). It is at least
> > using split_ident_
Yes, sorry. I find this whole story quite amusing (albeit distracting
and unnecessary), but sorry for adding to the spam. I'll be quiet now.
On Mon, Jun 10, 2013 at 11:33 AM, Martin Langhoff
wrote:
> On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
> wrote:
>> On Mon, Jun 10, 2013 at 9:58
Junio C Hamano wrote:
> I am curious what breaks, though.
t/status-help. Looks seriously unrelated, and I'm breaking my head
over it. Any clues?
--- expected2013-06-10 17:16:42.276356867 +
+++ actual 2013-06-10 17:16:42.279690201 +
@@ -1,4 +1,4 @@
-# HEAD detached at 000106f
+#
Dear all,
attached, you will find a series of small, obvious, and hopefully
uncontroversial patches for the hook templates and the manpage.
They are all tiny, but I still decided to submit distinct patches
to make modification/discussion easier.
Richard Hartmann (6):
templates: Fewer subprocess
The example assumes 8-char wide tabs and breaks for people with
4-char wide tabs.
Signed-off-by: Richard Hartmann
---
templates/hooks--pre-rebase.sample | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/templates/hooks--pre-rebase.sample
b/templates/hooks--p
Signed-off-by: Richard Hartmann
---
templates/hooks--pre-commit.sample |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/templates/hooks--pre-commit.sample
b/templates/hooks--pre-commit.sample
index 7676c6e..a982d99 100755
--- a/templates/hooks--pre-commit.sample
+++ b
Spawning a new subprocess for every line printed is inefficient.
Thus spawn only one instance of `echo`.
Signed-off-by: Richard Hartmann
---
templates/hooks--pre-commit.sample | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/templates/hooks--pre-co
Now that the there's only one echo being spawned, the message can span
the full 80 chars.
Signed-off-by: Richard Hartmann
---
templates/hooks--pre-commit.sample |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/templates/hooks--pre-commit.sample
b/templates/hooks--pre
The other hooks use two whitespace for indentation instead of tabs
to signify code in the example/echo output.
Follow the same layout in templates/hooks--pre-rebase.sample
Signed-off-by: Richard Hartmann
---
templates/hooks--pre-rebase.sample | 10 +-
1 file changed, 5 insertions(+), 5
Signed-off-by: Richard Hartmann
---
Documentation/githooks.txt |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index b9003fe..1276730 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -80,7
On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
wrote:
> On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
> wrote:
>> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
>> wrote:
>>
You need two sides to have an argument.
>>
>>> I disagree. Unless you mean than, whenever a part beh
Ramkumar Ramachandra writes:
> Invoking 'git rebase -i' writes the following line to the reflog at the
> start of the operation:
>
> rebase -i (start)
>
> This is not very useful. Make it more informative like:
>
> rebase -i (start): checkout master
Makes sense to me, at least within the sc
Ramkumar Ramachandra writes:
> GIT_REFLOG_ACTION is an environment variable specifying the reflog
> message to write after an action is completed. Other commands including
> merge, reset, and commit respect it.
>
> This incidentally fixes a bug in t/checkout-last. You can now expect
>
> $ git
Ramkumar Ramachandra writes:
> The following command
>
> $ git checkout -
>
> does not work as expected after a 'git rebase -i'.
>
> Add a failing test documenting this bug.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> t/t2012-checkout-last.sh | 8
> 1 file changed, 8 insertions(+
Junio C Hamano writes:
> test_expect_success '-c status.short=true == status -s' '
> test_config status.showUntrackedFile no &&
That's an option, but having status.showUntrackedFile set in a separate
setup test makes the actual tests shorter. The setup test has no reason
to f
On Mon, Jun 10, 2013 at 12:27:31AM -0700, Junio C Hamano wrote:
> > Around the same time, though, René wrote the linked-list merge sort that
> > powers commit_list_sort_by_date. And topo-sort learned to do O(1)
> > insertions into the unsorted list, and then one O(n log n) sort.
>
> Yes, but that
Jorge Juan Garcia Garcia
writes:
> Some people often run 'git status -b'.
> The config variable status.branch allows to set it by default.
>
> Signed-off-by: Jorge Juan Garcia Garcia
>
> Signed-off-by: Mathieu Lienard--Mayor
> Signed-off-by: Matthieu Moy
> ---
>
> Changes since v2:
> -remov
Jorge Juan Garcia Garcia
writes:
> Some people always run 'git status -s'.
> The configuration variable status.short allows to set it by default.
>
> Signed-off-by: Jorge Juan Garcia Garcia
>
> Signed-off-by: Mathieu Lienard--Mayor
> Signed-off-by: Matthieu Moy
> ---
>
> Changes since v2:
>
On Mon, Jun 10, 2013 at 12:21:00AM -0700, Junio C Hamano wrote:
> > It may be worth looking again for other places to use this over
> > commit_list, but even the caller you are introducing here justifies its
> > presence.
>
> The next candidate is paint-down-to-common, probably.
Yeah, I don't th
On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
wrote:
> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
> wrote:
>
>>> You need two sides to have an argument.
>
>> I disagree. Unless you mean than, whenever a part behaves in a
>> hostile and aggressive way, the other part should just silen
Matthieu Moy wrote:
> https://lkml.org/lkml/2012/4/12/434
> https://lkml.org/lkml/2012/4/15/112
We don't want things taken out of context now, do we? Follow up this
thread [1], if you're interested in that discussion. I did clip out
the quotes you chose on purpose, in the interest of presenting
Matthieu Moy writes:
> y...@ensimag.imag.fr writes:
>
>> To: y...@ensimag.imag.fr
>
> Common mistake, but you're not supposed to answer "y" when you're
> prompted for an email ;-).
Didn't we introduce safety against this in v1.7.12.1 and later? Is
the new release taking more than 9 months to pe
"Robin H. Johnson" writes:
> On Mon, Jun 10, 2013 at 04:04:29PM +0200, Matthieu Moy wrote:
>> Célestin Matte writes:
>>
>> > Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
>> >> 0. You do not take offense, no matter what. If someone attacks you
>> >> irrationally, you do not respond. Th
Junio C Hamano writes:
>> +{
>> +if (files_list->nr) {
>> +struct strbuf err_msg = STRBUF_INIT;
>> +int i;
>> +strbuf_addstr(&err_msg, main_msg);
>> +for (i = 0; i < files_list->nr; i++)
>> +strbuf_addf(&err_msg,
>> +
Felipe Contreras writes:
> It is not bad behavior. It is bad behavior *in your opinion*,
And in essentially everyone else on this list, it seems.
> an opinion that wouldn't be shared by other projects, like the Linux
> kernel.
Googling your name and LKML gives me this in the first page (addres
Please, don't top-post. Quote the part of the message you're replying
to, and reply below.
Benoît Person writes:
> Well, I think next step would be to replace all those calls with
> Git.pm `command`, `command_oneline` and `config``which take an array
> of arguments after the "command". In the pr
On Mon, Jun 10, 2013 at 08:56:58AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Sun, Jun 09, 2013 at 03:41:54PM -0500, Felipe Contreras wrote:
> >> There
> >> will not be a need for test_string_must_be_empty() just like there's
> >> no need for test_string_cmp().
> >
> > Actually,
Mathieu Lienard--Mayor
writes:
> Introduce advice.rmHints to choose whether to display advice or not
> when git rm fails. Defaults to true, in order to preserve current behavior.
>
> As an example, the message:
> error: 'foo.txt' has changes staged in the index
> (use --cached to keep
Le 2013-06-10 18:57, Junio C Hamano a écrit :
Mathieu Liénard--Mayor writes:
Please ignore this, manipulation error while in the git send-email
command line.
Here is what my mailbox looks like (the penultimate one with 252
lines is what I am responding to).
R. [ 146: Mathieu Lienard--May
On Mon, Jun 10, 2013 at 2:48 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> git-rebase.rb | 2056
>> +
>> 1 file changed, 2056 insertions(+)
>> create mode 100755 git-rebase.rb
>
> I suggest putting this in contrib/ and cooki
Well, I think next step would be to replace all those calls with
Git.pm `command`, `command_oneline` and `config``which take an array
of arguments after the "command". In the preview tool we use those but
I don't know if we will find the time to clean that up too in
git-remote-mediawiki :) .
Don't
Mathieu Lienard--Mayor
writes:
> When 'git rm' fails, it now displays a single message
> with the list of files involved, instead of displaying
> a list of messages with one file each.
>
> As an example, the old message:
> error: 'foo.txt' has changes staged in the index
> (use --cach
On Mon, Jun 10, 2013 at 10:56 AM, Junio C Hamano wrote:
> By the way, test_cmp() is a replacement for the "cmp" command and
> that is why it does not have "file" in its name.
That's an irrelevant implementation detail. But if you want to be
driven the the implementation, call it test_zero().
--
On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
wrote:
>> You need two sides to have an argument.
> I disagree. Unless you mean than, whenever a part behaves in a
> hostile and aggressive way, the other part should just silently
> knuckle under.
You are wrong. If a bum in the street starts
Mathieu Liénard--Mayor writes:
> Please ignore this, manipulation error while in the git send-email
> command line.
Here is what my mailbox looks like (the penultimate one with 252
lines is what I am responding to).
R. [ 146: Mathieu Lienard--Mayor ] [PATCH 1/2] rm: better error messa
R.
On Mon, Jun 10, 2013 at 11:53 AM, Felipe Contreras
wrote:
> On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano wrote:
>> E.g.
>> convincing people that it is not worth their time interacting with
>> you, especially when there are better things to do like tending to
>> other topics, and you lose the
1 - 100 of 176 matches
Mail list logo
