Matthieu Moy matthieu@grenoble-inp.fr writes:
Please, don't top-post. Quote the part of the message you're replying
to, and reply below.
Benoît Person benoit.per...@ensimag.fr writes:
Well, I think next step would be to replace all those calls with
Git.pm `command`, `command_oneline`
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.
[...]
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
Chained by
Ramkumar Ramachandra artag...@gmail.com 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
SZEDER Gábor sze...@ira.uka.de 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):
John Keeping j...@keeping.me.uk 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
Richard Hartmann richih.mailingl...@gmail.com writes:
Spawning a new subprocess for every line printed is inefficient.
Thus spawn only one instance of `echo`.
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
templates/hooks--pre-commit.sample | 24
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 so,
Richard Hartmann richih.mailingl...@gmail.com writes:
Now that the there's only one echo being spawned, the message can span
the full 80 chars.
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
templates/hooks--pre-commit.sample |6 ++
1 file changed, 2
Richard Hartmann richih.mailingl...@gmail.com 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
Richard Hartmann richih.mailingl...@gmail.com 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 richih.mailingl...@gmail.com
---
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 for
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 (master)
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 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 with -i
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
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 (with a
On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano gits...@pobox.com 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
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 found
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.
On Mon, Jun 10, 2013 at 12:28:55PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
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 foo'
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 1:11 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
You need two sides to have an argument.
On Mon, Jun 10, 2013 at 12:34 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Antoine Pelisse apeli...@gmail.com writes:
On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano gits...@pobox.com 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
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 the
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 j...@keeping.me.uk writes:
I think the first thing to do is read the diff.algorithm setting in
git-add--interactive and pass its value to the
On Mon, Jun 10, 2013 at 3:07 PM, Ramkumar Ramachandra
artag...@gmail.com 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
On Mon, Jun 10, 2013 at 9:52 PM, Junio C Hamano gits...@pobox.com 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
On Mon, Jun 10, 2013 at 4:45 PM, Jeff King p...@peff.net 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
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
allowed diff
On Mon, Jun 10, 2013 at 04:52:57PM -0500, Felipe Contreras wrote:
On Mon, Jun 10, 2013 at 4:45 PM, Jeff King p...@peff.net 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
On Mon, Jun 10, 2013 at 5:06 PM, Jeff King p...@peff.net 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 p...@peff.net wrote:
That is what libgit.a _is_ now. I do not mean to imply any additional
judgement on what it
On Sun, Jun 9, 2013 at 3:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sun, Jun 9, 2013 at 2:24 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Same as before, but:
Also, remove the patches from Martin von Zweigbergk, because
apparently some people have trouble
Richard Hartmann richih.mailingl...@gmail.com writes:
On Mon, Jun 10, 2013 at 9:52 PM, Junio C Hamano gits...@pobox.com 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
On Tue, Jun 11, 2013 at 12:57 AM, Junio C Hamano gits...@pobox.com 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
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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 with
On Mon, Jun 10, 2013 at 5:55 PM, Phil Hord phil.h...@gmail.com wrote:
On Sun, Jun 9, 2013 at 3:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sun, Jun 9, 2013 at 2:24 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Same as before, but:
Also, remove the patches from
On Mon, Jun 10, 2013 at 6:41 PM, Junio C Hamano gits...@pobox.com 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
Felipe Contreras felipe.contre...@gmail.com 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
Отправлено с iPhone
On Mon, Jun 10, 2013 at 7:43 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jun 10, 2013 at 5:55 PM, Phil Hord phil.h...@gmail.com wrote:
On Sun, Jun 9, 2013 at 3:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sun, Jun 9, 2013 at 2:24 PM, Felipe Contreras
Отправлено с iPhone пл
On Mon, Jun 10, 2013 at 8:09 PM, Phil Hord phil.h...@gmail.com wrote:
On Mon, Jun 10, 2013 at 7:43 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jun 10, 2013 at 5:55 PM, Phil Hord phil.h...@gmail.com wrote:
On Sun, Jun 9, 2013 at 3:37 PM, Felipe Contreras
On Mon, Jun 10, 2013 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
On Mon, Jun 10, 2013 at 8:53 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com 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
On Sun, Jun 9, 2013 at 9:40 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t3425-rebase-topology-merges.sh | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git
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 Mon, Jun 10, 2013 at 11:37 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Sun, Jun 9, 2013 at 9:40 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t3425-rebase-topology-merges.sh | 15 ++-
1
On Mon, Jun 10, 2013 at 12:42 PM, Junio C Hamano gits...@pobox.com wrote:
Robin H. Johnson robb...@gentoo.org writes:
On Mon, Jun 10, 2013 at 04:04:29PM +0200, Matthieu Moy wrote:
Célestin Matte celestin.ma...@ensimag.fr writes:
Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
0. You
On Mon, Jun 10, 2013 at 8:28 AM, Ramkumar Ramachandra
artag...@gmail.com 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
101 - 153 of 153 matches
Mail list logo