POSIX like file systems allows to create a file when the user has
write permissions to the directory.
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
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, and
Sudhir Kumar smalikphy at 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
From: Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
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
From: Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
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
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
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
jorge-juan.garcia-gar...@ensimag.imag.fr
Signed-off-by: Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
Signed-off-by: Matthieu Moy
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
jorge-juan.garcia-gar...@ensimag.imag.fr
Signed-off-by: Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
Signed-off-by: Matthieu Moy
On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
johannes.schinde...@gmx.de 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
On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
felipe.contre...@gmail.com 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
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
felipe.contre...@gmail.com 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'
On Fri, Jun 7, 2013 at 9:44 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 3:32 AM, Felipe Contreras
felipe.contre...@gmail.com 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
On Fri, Jun 7, 2013 at 10:29 PM, Ramkumar Ramachandra
artag...@gmail.com 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 @@
On Fri, Jun 7, 2013 at 10:35 PM, Ramkumar Ramachandra
artag...@gmail.com 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
On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
The reviewer pool for code written in a new language _must_
On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi Greg,
On Thu, 6 Jun 2013, Greg Troxel wrote:
As
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
On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This code is only useful for cherry-pick and revert
On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
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 about
On Sat, Jun 8, 2013 at 6:20 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com
On Sat, Jun 8, 2013 at 6:32 AM, René Scharfe
rene.scha...@lsrfire.ath.cx 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
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 tbo...@web.de
---
t/t0070-fundamental.sh | 2 +-
1 file changed, 1 insertion(+), 1
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 tbo...@web.de
---
t/t0070-fundamental.sh | 2 +-
1 file changed, 1 insertion(+), 1
On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com
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 never
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 your
On Sat, Jun 8, 2013 at 7:55 PM, Ramkumar Ramachandra artag...@gmail.com 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
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 state
On Sat, Jun 8, 2013 at 7:07 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen pclo...@gmail.com wrote:
but how many people on this
list understand git design and limits _and_
Am 08.06.2013 14:15, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 6:32 AM, René Scharfe
rene.scha...@lsrfire.ath.cx 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
On Sat, Jun 8, 2013 at 7:34 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
On Sat, Jun 8, 2013 at 8:15 AM, Duy Nguyen pclo...@gmail.com 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
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 celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
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_flags
On Sat, Jun 8, 2013 at 8:19 AM, Ramkumar Ramachandra artag...@gmail.com 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
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, have you
On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
rene.scha...@lsrfire.ath.cx 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
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 this.
On Sat, Jun 8, 2013 at 8:34 AM, Ramkumar Ramachandra artag...@gmail.com 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
On Sat, Jun 8, 2013 at 8:34 PM, Ramkumar Ramachandra artag...@gmail.com 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
On Sat, Jun 8, 2013 at 9:04 AM, Ramkumar Ramachandra artag...@gmail.com 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
On Sat, Jun 8, 2013 at 4:04 PM, Ramkumar Ramachandra artag...@gmail.com 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
On Sat, Jun 8, 2013 at 9:10 AM, Duy Nguyen pclo...@gmail.com 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
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_summary
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 the
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 implementation,
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 its
Am 08.06.2013 16:04, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
rene.scha...@lsrfire.ath.cx 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
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 of
On Sat, Jun 8, 2013 at 10:56 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 08.06.2013 16:04, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 08.06.2013 14:15, schrieb Felipe Contreras:
Why leave it out? If somebody
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 the
On Sat, Jun 8, 2013 at 11:49 AM, Jonathan Nieder jrnie...@gmail.com 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.
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 from what?
Am 08.06.2013 18:53, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 10:56 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 08.06.2013 16:04, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 08.06.2013 14:15, schrieb Felipe
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
On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder jrnie...@gmail.com 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
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 a
On Sat, Jun 8, 2013 at 1:02 PM, Ramkumar Ramachandra artag...@gmail.com 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.
Jeff King p...@peff.net 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
Célestin Matte celestin.ma...@ensimag.fr 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
Ramkumar Ramachandra artag...@gmail.com 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
Célestin Matte celestin.ma...@ensimag.fr 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
Le 08/06/2013 20:41, Matthieu Moy a écrit :
Célestin Matte celestin.ma...@ensimag.fr 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
benoit.per...@ensimag.fr writes:
From: Benoit Person benoit.per...@ensimag.fr
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,
Célestin Matte celestin.ma...@ensimag.fr 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 initials/topic)
--
Matthieu Moy
On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder jrnie...@gmail.com 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
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 log
Le 08/06/2013 02:39, Eric Sunshine a écrit :
On Fri, Jun 7, 2013 at 5:42 PM, Célestin Matte
celestin.ma...@ensimag.fr 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
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 felipe.contre...@gmail.com
---
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
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 from
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 create
On Sat, Jun 8, 2013 at 7:10 PM, Jeff King p...@peff.net 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
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
is
Am 08.06.2013 19:27, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe
rene.scha...@lsrfire.ath.cx 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
On Sat, Jun 8, 2013 at 8:40 PM, Jonathan Nieder jrnie...@gmail.com 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
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 day
On Sat, Jun 8, 2013 at 9:11 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 08.06.2013 19:27, schrieb Felipe Contreras:
On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Let's find and fix those leaks by freeing memory in the right places.
Freeing
On Sat, Jun 8, 2013 at 9:23 PM, Jeff King p...@peff.net 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
On Sat, Jun 08, 2013 at 08:38:56PM +0200, Matthieu Moy wrote:
Célestin Matte celestin.ma...@ensimag.fr 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
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 inactive community
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
do from
Hi Duy,
On Sat, 8 Jun 2013, Duy Nguyen wrote:
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
johannes.schinde...@gmx.de 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
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 jrnie...@gmail.com 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
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
On Sat, Jun 8, 2013 at 4:32 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Le 08/06/2013 02:39, Eric Sunshine a écrit :
On Fri, Jun 7, 2013 at 5:42 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
- strings which don't need interpolation are single-quoted for more clarity
and
slight
On Sat, Jun 8, 2013 at 2:45 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Le 08/06/2013 20:41, Matthieu Moy a écrit :
Célestin Matte celestin.ma...@ensimag.fr writes:
Le 08/06/2013 02:14, Eric Sunshine a écrit :
These two changes are unrelated and could be split into distinct
patches
On Sat, Jun 8, 2013 at 9:35 AM, Célestin Matte
celestin.ma...@ensimag.fr 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
On Sat, Jun 8, 2013 at 10:57 PM, Jeff King p...@peff.net wrote:
On Sat, Jun 08, 2013 at 08:38:56PM +0200, Matthieu Moy wrote:
Célestin Matte celestin.ma...@ensimag.fr writes:
In Perl, '\n' is not a newline, but instead a literal backslash followed
by an
n. As the output of rev-list
This can help with debugging object negotiation or other protocol
issues.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index c760918..72e9045 100644
---
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
On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:
Definitely, yes. Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
is harmful enough to the code to outweigh the (admittedly often
useful) patches.
A
1 - 100 of 103 matches
Mail list logo
