Am 08.06.2013 08:51, schrieb Torsten Bögershausen:
> Filesystems like VFAT or NTFS allow to create files regardless of
> the write permissions of the directory.
>
> Therefore "mktemp to unwritable directory" in t0700 will always fail on
> Windows using NTFS.
> This TC has been disabled for MINGW,
Sudhir Kumar gmail.com> writes:
>
> Hey Git Experts,
>
> I need your advice. I have lot of png/jpg images in my codebase (which
> is currently under git) which causes the repo size to be very heavy.
> We have migrated these images to a storage server using git exile
> technique. This has been w
From: Mathieu Liénard--Mayor
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 --cached to keep
From: Mathieu Liénard--Mayor
Similarly to advice.*, advice.rmHints has been added
to the config variables. By default, it is set to false, in order to
keep the messages the same as before. When set to true, advice
are no longer included in the error messages.
As an example, the message:
The major drawback of using perl `constant` is the fact that they do
not interpolate like variables in most of the contexts (those who
automatically quotes barewords). Like said on Perl Monks here [1], you
have to do some "tricks" depending on the context in which you're
using the constant and that
Fredrik Gustafsson wrote:
> I've looked into this a bit.
Thanks for investigating.
[...]
> Why don't we always print names quoted? IMHO the choose of line
> termination should not do anything else than alter the line termination.
>
> However, an other solution would be to use git ls-files -z in
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
---
Documentation/config.txt |3 +++
builtin/commit.c |6 ++
t/t7
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
---
Documentation/config.txt |3 +++
builtin/commit.c |9 +
On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:
> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
> wrote:
>> Hi Greg,
>>
>> On Thu, 6 Jun 2013, Greg Troxel wrote:
>>
>>> As one of the people who helps maintain git packages in pkgsrc, my
>>> initial reaction is negative to adding a ruby de
On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
> wrote:
>>> The reviewer pool for code written in a new language _must_ be
>>> seeded by some from the current set of reviewers whose judgement
>>> I/we can trust.
>>
>> By that standard nothing
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
> wrote:
>> This code is only useful for cherry-pick and revert built-ins, nothing
>> else, so let's make it a builtin object, but make sure 'git-sequencer'
>> is not generated.
>
> As you can see
On Fri, Jun 7, 2013 at 9:44 PM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 3:32 AM, Felipe Contreras
> wrote:
>> Let's show the output so it's clear why it failed.
>
> I think you can always look into trash-directory.t3400 and figure why.
> But if you show this, I think you should use test_cmp to
On Fri, Jun 7, 2013 at 10:29 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh
>> index a5e69f3..ff370a3 100755
>> --- a/t/t3420-rebase-autostash.sh
>> +++ b/t/t3420-rebase-autostash.sh
>> @@ -71,8 +71,7 @@ testrebas
On Fri, Jun 7, 2013 at 10:35 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> sequencer.c => builtin/sequencer.c | 160
>> +---
>> sequencer.h => builtin/sequencer.h | 4 -
>
> Why exactly? The plan was to unify continuation semantics, and get
> all
On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras
wrote:
> On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:
>> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
>> wrote:
The reviewer pool for code written in a new language _must_ be
seeded by some from the current set of reviewers whos
On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
wrote:
> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:
>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
>> wrote:
>>> Hi Greg,
>>>
>>> On Thu, 6 Jun 2013, Greg Troxel wrote:
>>>
As one of the people who helps maintain git packages
Am 08.06.2013 00:29, schrieb Felipe Contreras:
We are not freeing 'istate->cache' properly.
We can't rely on 'initialized' to keep track of the 'istate->cache',
because it doesn't really mean it's initialized. So assume it always has
data, and free it before overwriting it.
That sounds a bit b
On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
wrote:
> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
>> wrote:
>>> This code is only useful for cherry-pick and revert built-ins, nothing
>>> else, so let's make it a builtin object, but ma
On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
> wrote:
>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:
>>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
>>> wrote:
Hi Greg,
On Thu, 6 Jun 2013, Greg Troxel wrote:
>
On Sat, Jun 08, 2013 at 02:18:36AM -0700, Jonathan Nieder wrote:
> The whole point of "-z" is that by using a terminator that is guaranteed
> not to appear in filenames, it avoids the need to quote filenames.
> Otherwise at least \n would need to be quoted.
Thanks, now I understand why.
>
> How
On Sat, Jun 8, 2013 at 6:20 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras
> wrote:
>> On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:
>>> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
>>> wrote:
> The reviewer pool for code written in a new language _must_ be
On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
wrote:
> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:
>> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
>> wrote:
>>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
wrote:
On Sat, Jun 8, 2013 at 6:32 AM, René Scharfe
wrote:
> Am 08.06.2013 00:29, schrieb Felipe Contreras:
>
>> We are not freeing 'istate->cache' properly.
>>
>> We can't rely on 'initialized' to keep track of the 'istate->cache',
>> because it doesn't really mean it's initialized. So assume it always
Use the SANITY prerequisite when testing if a temp file can
be created in a read only directory.
Skip the test under CYGWIN, or skip it under Unix/Linux when
it is run as root.
Signed-off-by: Torsten Bögershausen
---
t/t0070-fundamental.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
Use the SANITY prerequisite when testing if a temp file can
be created in a read only directory.
Skip the test under CYGWIN, or skip it under Unix/Linux when
it is run as root.
Signed-off-by: Torsten Bögershausen
---
t/t0070-fundamental.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
> wrote:
>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
>>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
>>> wrote:
This code is only useful for cherry-pick and revert built-ins,
On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
wrote:
> On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:
>> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
>> wrote:
>>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
wrote:
Duy Nguyen wrote:
>> until libgit.a == libgit2. Done.
>
> Read up about the introduction of libgit2, why it was created in the
> first place instead of moving a few files around renaming libgit.a to
> libgit2.a. Unless you have a different definition of "==" than I do.
As far as I know, there was
Le 08/06/2013 05:23, Jeff King a écrit :
> What does this series apply on top of? The existing version in "master"
> does not have "use Readonly" in it at all. The first version of your
> series introduced that line, but here it is shown as an existing line.
> Did you miss a commit when putting you
On Sat, Jun 8, 2013 at 7:55 PM, Ramkumar Ramachandra wrote:
> Duy Nguyen wrote:
>>> until libgit.a == libgit2. Done.
>>
>> Read up about the introduction of libgit2, why it was created in the
>> first place instead of moving a few files around renaming libgit.a to
>> libgit2.a. Unless you have a d
Felipe Contreras wrote:
> Yes you do. The rest of the tests expect that the previous rebase has
> been aborted.
>
> In fact, all the tests depend on the previous test finishing
> correctly, which is not the way tests should be written.
How else am I supposed to write them? If there is a stale sta
On Sat, Jun 8, 2013 at 7:07 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
> wrote:
>> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:
>>> but how many people on this
>>> list understand git design and limits _and_ ruby's good enough to spot
>>> the bugs?
>>
>> Now y
Am 08.06.2013 14:15, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 6:32 AM, René Scharfe
wrote:
diff --git a/read-cache.c b/read-cache.c
index 5e30746..a1dd04d 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1451,6 +1451,7 @@ int read_index_from(struct index_state *istate,
const char *path)
On Sat, Jun 8, 2013 at 7:34 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
> wrote:
>> On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:
>>> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
>>> wrote:
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
> On Sat
On Sat, Jun 8, 2013 at 8:15 AM, Duy Nguyen wrote:
> So instead of redoing it again, I think it's better that you help
> libgit2 guys improve it to the extend that git commands can be easily
> reimplemented. Then bring up the discussion about using libgit2 in C
> Git again.
There's no reason not
Duy Nguyen wrote:
> I _think_ the reason is because git was never written as a reusable
> library in mind from the beginning.
We cannot reverse-engineer intents, but I tend to agree with this. My
question is: so what? Is it impossible to do now?
> So global states and die() exist.
> Worse, "run
In Perl, '\n' is not a newline, but instead a literal backslash followed by an
"n". As the output of "rev-list --first-parent" is line-oriented, what we want
here is a newline.
Signed-off-by: Célestin Matte
Signed-off-by: Matthieu Moy
---
contrib/mw-to-git/git-remote-mediawiki.perl |2 +-
1
Mathieu Lienard--Mayor wrote:
> @@ -170,30 +175,47 @@ static int check_local_mod(unsigned char *head, int
> index_only)
> * "intent to add" entry.
> */
> if (local_changes && staged_changes) {
> - if (!index_only || !(ce->ce_f
On Sat, Jun 8, 2013 at 8:19 AM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>> Doing 'rm -rf $dotest' is even worst than 'git rebase --abort',
>> because it relies on the implementation of 'git rebase', which might
>> need to remove more files than $dotest.
>
> Huh? Tests aren't allowe
Mathieu Lienard--Mayor wrote:
> As an example, the message:
> error: 'foo.txt' has changes staged in the index
> (use --cached to keep the file, or -f to force removal)
>
> would look like, with advice.rmHints=true:
> error: 'foo.txt' has changes staged in the index
Um, hav
On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
wrote:
> Am 08.06.2013 14:15, schrieb Felipe Contreras:
>> Why leave it out? If somebody makes the mistake of doing the above
>> sequence, would you prefer that we leak?
>
> Leaking is better than silently cleaning up after a buggy caller because it
>
Felipe Contreras wrote:
>> Ofcourse they're implementation details. Even in this very test, I
>> check $dotest/autostash plenty of times.
>
> The more the test relies on implementation details, the worst.
I'm not convinced about this.
>> Then show me how to do it correctly.
>
> Something like th
On Sat, Jun 8, 2013 at 8:34 AM, Ramkumar Ramachandra wrote:
> Duy Nguyen wrote:
>> I _think_ the reason is because git was never written as a reusable
>> library in mind from the beginning.
>
> We cannot reverse-engineer intents, but I tend to agree with this. My
> question is: so what? Is it im
On Sat, Jun 8, 2013 at 8:34 PM, Ramkumar Ramachandra wrote:
> I'm not saying that we can convert libgit.a into something that's
> usable as a long-running process by production servers tomorrow. All
> I'm saying is that it might be possible to get ruby (and possibly
> other languages) to call int
On Sat, Jun 8, 2013 at 9:04 AM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>>> Ofcourse they're implementation details. Even in this very test, I
>>> check $dotest/autostash plenty of times.
>>
>> The more the test relies on implementation details, the worst.
>
> I'm not convinced abou
On Sat, Jun 8, 2013 at 4:04 PM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>>> Ofcourse they're implementation details. Even in this very test, I
>>> check $dotest/autostash plenty of times.
>>
>> The more the test relies on implementation details, the worst.
>
> I'm not convinced abou
On Sat, Jun 8, 2013 at 9:10 AM, Duy Nguyen wrote:
> Do we want to
> freeze libgit.a API so that scripts will not be audited and changed
> unncessarily?
No. Until we ship libgit.so the API remains internal, and free to change.
> I still think that binding new languages to a clean library
> like
Jorge Juan Garcia Garcia wrote:
> Some people always run 'git status -s'.
> The configuration variable status.short allows to set it by default.
Good feature.
> @@ -1112,6 +1112,15 @@ static int git_status_config(const char *k, const char
> *v, void *cb)
> s->submodule_su
Junio C Hamano wrote:
> * mm/color-auto-default (2013-05-15) 2 commits
> - make color.ui default to 'auto'
> - config: refactor management of color.ui's default value
>
> Flip the default for color.ui to 'auto', which is what many
> tutorials recommend new users to do. The updated code claims
Antoine Pelisse wrote:
>>> The more the test relies on implementation details, the worst.
>>
>> I'm not convinced about this.
>
> My understanding of these tests is that they make sure new/better
> implementations don't break the user experience/defined behavior. If
> the test relies on the impleme
Le 08/06/2013 02:14, Eric Sunshine a écrit :
> These two changes are unrelated and could be split into distinct
> patches (IMHO, though others may disagree).
Two distinct patches or two distinct commits?
I assumed it was two distinct commits, but thinking about it, removing a
library could have it
Am 08.06.2013 16:04, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
wrote:
Am 08.06.2013 14:15, schrieb Felipe Contreras:
Why leave it out? If somebody makes the mistake of doing the above
sequence, would you prefer that we leak?
Leaking is better than silently clea
Duy Nguyen wrote:
> libgit.a is just a way of grouping a bunch of objects together, not a
> real library and not meant to be. If you aim something more organized,
> please show at least a roadmap what to move where.
Exactly. There are some rough plans I would like to help with in the
direction o
On Sat, Jun 8, 2013 at 10:56 AM, René Scharfe
wrote:
> Am 08.06.2013 16:04, schrieb Felipe Contreras:
>
>> On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
>> wrote:
>>>
>>> Am 08.06.2013 14:15, schrieb Felipe Contreras:
>>
>>
Why leave it out? If somebody makes the mistake of doing the above
>>
Ramkumar Ramachandra wrote:
> How else am I supposed to write them? If there is a stale state from
> the previous test, there isn't too much I can do. Or should I be
> cleaning up state at the beginning of each test, instead of at the
> end?
That's one strategy. "test_when_finished" to restore
On Sat, Jun 8, 2013 at 11:49 AM, Jonathan Nieder wrote:
> Duy Nguyen wrote:
>
>> libgit.a is just a way of grouping a bunch of objects together, not a
>> real library and not meant to be. If you aim something more organized,
>> please show at least a roadmap what to move where.
>
> Exactly. There
On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote:
> > There are a lot of static variables in builtin/ (and outside too),
> > which make it non-entrant, or at least not safe.
>
> So?
>
> > fork provides a process space isolation, some depend on that.
>
> Process space isolation f
Am 08.06.2013 18:53, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 10:56 AM, René Scharfe
wrote:
Am 08.06.2013 16:04, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
wrote:
Am 08.06.2013 14:15, schrieb Felipe Contreras:
Why leave it out? If somebody makes the
On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe
wrote:
> Let's find and fix those leaks by freeing memory in the right places.
> Freeing memory just in case in places where we can show that no leak is
> triggered by our test suite doesn't help.
It helps; it prevents leaks. The real culprit is the
On Sat, Jun 08, 2013 at 03:01:03PM +0200, Célestin Perdu wrote:
> Oh yes, part of this commit went into the previous one, which was not
> formated as an email when I did my git-format-patch. I should check my
> patches more carefully before sending them. Sorry for this.
No problem. It is easy to
There's no libgit, and there will never be, every object file in Git is
the same, and there's wish to organize them in any way; they are *all*
for the 'git' binary and its builtin commands.
So let's shatter any hopes of ever having a library, and be clear about
it; both the top-level objects (./*.
Felipe Contreras wrote:
> This has nothing to do with better strategy, it has everything to do
> with gut feelings and tradition. Not reasons.
I try to help you, and you insult me. I don't think this is worth it.
If I were managing this list, I would ban mails from you, since this
discussion st
On Sat, Jun 8, 2013 at 12:15 PM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote:
>
>> > There are a lot of static variables in builtin/ (and outside too),
>> > which make it non-entrant, or at least not safe.
>>
>> So?
>>
>> > fork provides a process space isol
On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> This has nothing to do with better strategy, it has everything to do
>> with gut feelings and tradition. Not reasons.
>
> I try to help you, and you insult me. I don't think this is worth it.
I didn't direct t
Felipe Contreras wrote:
> There's no libgit, and there will never be, every object file in Git is
> the same, and there's wish to organize them in any way; they are *all*
> for the 'git' binary and its builtin commands.
Nice joke patch to illustrate your point ;)
On a more serious note, please be
On Sat, Jun 8, 2013 at 1:02 PM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>> There's no libgit, and there will never be, every object file in Git is
>> the same, and there's wish to organize them in any way; they are *all*
>> for the 'git' binary and its builtin commands.
>
> Nice joke
Jeff King writes:
> Thanks both for the explanation. I don't see us using that to our
> advantage anywhere in the patch. So I think this is purely a style
> issue, which to me indicates that the extra dependency is not worth it,
> and the patch should be dropped.
Same here: I'd rather keep the
Célestin Matte writes:
> In Perl, '\n' is not a newline, but instead a literal backslash followed by an
> "n". As the output of "rev-list --first-parent" is line-oriented, what we want
> here is a newline.
This is right, but the code actually worked the way it was. I'm not
sure, but my understan
Ramkumar Ramachandra writes:
> Yes, please merge. The commit message looks good as well: it doesn't
> say anything about waiting for 2.0.
The commit message doesn't, but the doc does. I'll resend without the
2.0 mention.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from
Célestin Matte writes:
> Le 08/06/2013 02:14, Eric Sunshine a écrit :
>> These two changes are unrelated and could be split into distinct
>> patches (IMHO, though others may disagree).
>
> Two distinct patches or two distinct commits?
That's the same. You write commits locally, send them as patc
Le 08/06/2013 20:41, Matthieu Moy a écrit :
> Célestin Matte writes:
>
>> Le 08/06/2013 02:14, Eric Sunshine a écrit :
>>> These two changes are unrelated and could be split into distinct
>>> patches (IMHO, though others may disagree).
>>
>> Two distinct patches or two distinct commits?
>
> That
benoit.per...@ensimag.fr writes:
> From: Benoit Person
>
> The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
> preview content without pushing would be a nice thing to have.
>
> This commit is a first attempt to achieve it. It adds a new git command,
> named `git mw`. T
Célestin Matte writes:
> Oh, I thought a part of a patch was called a commit.
1 patch = 1 commit
1 patch series = several commits sent together. Will normally end-up in
a branch in Junio's repo (named with /)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe f
On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder wrote:
> If I were managing this list, I would ban mails from you, since this
> discussion style does more harm than good.
There is a nice motto around: "Talk is cheap. Show me the code."
Just the past three months I've probably done more work th
Le 08/06/2013 20:38, Matthieu Moy a écrit :> This is right, but the code
actually worked the way it was. I'm not
> sure, but my understanding is that '\n' is the string "backslash
> followed by n", but interpreted as a regexp, it is a newline.
>
> The new code looks better than the old one, but the
Le 08/06/2013 02:39, Eric Sunshine a écrit :
> On Fri, Jun 7, 2013 at 5:42 PM, Célestin Matte
> wrote:
>> - strings which don't need interpolation are single-quoted for more clarity
>> and
>> slight gain of performance
>> - interpolation is preferred over concatenation in many cases, for more
>>
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for "break-rewrites".
When this option is used, git-diff will not create hunks that simply
adds or removes empty lines, but will still show
There's no need to list again the prerequisites.
Signed-off-by: Felipe Contreras
---
Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 03524d0..fda98d6 100644
--- a/Makefile
+++ b/Makefile
@@ -2067,13 +2067,13 @@ $(REMOTE_CURL_PRIMARY):
On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote:
> > These are problems that can be solved. But there is a lot of work
> > involved in finding these subtle bugs and coming up with fixes. I think
> > you would be better off working on an implementation of git that was
> > designed
On Fri, Jun 07, 2013 at 12:12:52PM +0200, Erik Faye-Lund wrote:
> > Yeah, if it were mingw_raise responsible for this, I would suggest using
> > the POSIX shell "128+sig" instead. We could potentially check for
> > SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if
> > that would
On Sat, Jun 8, 2013 at 7:10 PM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote:
>
>> > These are problems that can be solved. But there is a lot of work
>> > involved in finding these subtle bugs and coming up with fixes. I think
>> > you would be better off wo
Felipe Contreras wrote:
> Just the past three months I've probably done more work than anybody
> else[1], and you would ban me because you don't like my words?
Definitely, yes. Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
i
Am 08.06.2013 19:27, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe
wrote:
Let's find and fix those leaks by freeing memory in the right places.
Freeing memory just in case in places where we can show that no leak is
triggered by our test suite doesn't help.
It helps
On Sat, Jun 8, 2013 at 8:40 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> Just the past three months I've probably done more work than anybody
>> else[1], and you would ban me because you don't like my words?
>
> Definitely, yes. Even if you look at the impact on code alone and
> don'
On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote:
> > No, I didn't say that at all.
>
> Then you truly think libgit2 will ever reach the point where it can
> replace libgit.a?
I don't know. It may. Or something like it may. It is certainly not
ready to do so yet, but perhaps one
On Sat, Jun 8, 2013 at 9:11 PM, René Scharfe
wrote:
> Am 08.06.2013 19:27, schrieb Felipe Contreras:
>
>> On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe
>> wrote:
>>
>>> Let's find and fix those leaks by freeing memory in the right places.
>>> Freeing memory just in case in places where we can sho
On Sat, Jun 8, 2013 at 9:23 PM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote:
>
>> > No, I didn't say that at all.
>>
>> Then you truly think libgit2 will ever reach the point where it can
>> replace libgit.a?
>
> I don't know. It may. Or something like it ma
On Sat, Jun 08, 2013 at 08:38:56PM +0200, Matthieu Moy wrote:
> Célestin Matte writes:
>
> > In Perl, '\n' is not a newline, but instead a literal backslash followed by
> > an
> > "n". As the output of "rev-list --first-parent" is line-oriented, what we
> > want
> > here is a newline.
>
> Thi
Hi Ram,
On Sat, 8 Jun 2013, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> >> Also we heard from no regular/high-value reviewers that they feel
> >> comfortable reviewing additions in Ruby.
> >
> > Correction; *current* regular/high-value reviewers.
>
> Correct. The opinions of inactiv
Hi Ram,
On Sat, 8 Jun 2013, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> > While at it, why not re-evaluate the whole msysgit approach? I bet we
> > don't need a whole separate project just to create a Windows
> > installer. I've written Windows installers before, it's very easy to
> >
Hi Duy,
On Sat, 8 Jun 2013, Duy Nguyen wrote:
> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
> wrote:
> > Hi Greg,
> >
> > On Thu, 6 Jun 2013, Greg Troxel wrote:
> >
> >> As one of the people who helps maintain git packages in pkgsrc, my
> >> initial reaction is negative to adding a ruby
Felipe Contreras wrote:
> A collegial work environment is overrated, and proof of that the Linux
> kernel, where honest and straight talk is the bread and butter of the
> mailing list.
An aside, since it doesn't bear too much on the topic at hand:
For what it's worth, in my experience the people
On Sat, Jun 8, 2013 at 10:21 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> A collegial work environment is overrated, and proof of that the Linux
>> kernel, where honest and straight talk is the bread and butter of the
>> mailing list.
>
> An aside, since it doesn't bear too much on th
On Sat, Jun 08, 2013 at 09:20:54AM -0500, Felipe Contreras wrote:
> Let the code speak. Show me a script in any language that does
> something useful using libgit2, doing the equivalent to at least a
> couple of 'git foo' commands.
Sorry that I cannot show you the source code, but you may interes
On Sat, Jun 8, 2013 at 4:32 PM, Célestin Matte
wrote:
> Le 08/06/2013 02:39, Eric Sunshine a écrit :
>> On Fri, Jun 7, 2013 at 5:42 PM, Célestin Matte
>> wrote:
>>> - strings which don't need interpolation are single-quoted for more clarity
>>> and
>>> slight gain of performance
>>> - interpolat
On Sat, Jun 8, 2013 at 2:45 PM, Célestin Matte
wrote:
> Le 08/06/2013 20:41, Matthieu Moy a écrit :
>> Célestin Matte writes:
>>
>>> Le 08/06/2013 02:14, Eric Sunshine a écrit :
These two changes are unrelated and could be split into distinct
patches (IMHO, though others may disagree).
On Sat, Jun 8, 2013 at 9:35 AM, Célestin Matte
wrote:
> In Perl, '\n' is not a newline, but instead a literal backslash followed by an
> "n". As the output of "rev-list --first-parent" is line-oriented, what we want
> here is a newline.
>
> Signed-off-by: Célestin Matte
> Signed-off-by: Matthieu
On Sat, Jun 8, 2013 at 10:57 PM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 08:38:56PM +0200, Matthieu Moy wrote:
>
>> Célestin Matte writes:
>>
>> > In Perl, '\n' is not a newline, but instead a literal backslash followed
>> > by an
>> > "n". As the output of "rev-list --first-parent" is line-o
"This can help with debugging object negotiation or other protocol
issues."
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index c760918..72e9045 100644
--- a/Documentation/git.t
5f44324 (core: log offset pack data accesses happened - 2011-07-06)
provides a way to observe pack access patterns via a config
switch. Setting an environment variable looks more obvious than a
config var, especially when you just need to _observe_, and more
inline with other tracing knobs we have.
1 - 100 of 152 matches
Mail list logo
