On Tue, Nov 20, 2012 at 09:46:47PM -0500, Paul Fox wrote:
junio c hamano wrote:
Here is a list of stalled topics I am having trouble deciding what
to do (the default is to dismiss them around feature freeze).
...
* pf/editor-ignore-sigint (2012-11-11) 5 commits
Avoid confusing
Pls find attached details of a business proposer and reply through the
stated email leemasamoto1...@worker.com Regards, Lee Masamoto
-
O usuario e integralmente responsavel por todo conteudo enviado
de sua conta de e-mail.
Pls find attached details of a business proposer and reply through the
stated email leemasamoto1...@worker.com Regards, Lee Masamoto
-
O usuario e integralmente responsavel por todo conteudo enviado
de sua conta de e-mail.
Am 21.11.2012 01:13, schrieb Lisandro Damián Nicanor Pérez Meyer:
Well, two ideas come to my mind:
- detect when using git flow (.git/config contains [gitflow some_branch]
entries).
Shouldn't it be part of the gitflow package then?
- Show swim-lane-like graphs, including branches that may
On 12-11-20 07:05 PM, Junio C Hamano wrote:
Here is a list of stalled topics I am having trouble deciding what
to do (the default is to dismiss them around feature freeze).
[ snip ]
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect
On Wed 21 Nov 2012 11:52:05 Holger Hellmuth (IKS) escribió:
Am 21.11.2012 01:13, schrieb Lisandro Damián Nicanor Pérez Meyer:
Well, two ideas come to my mind:
- detect when using git flow (.git/config contains [gitflow
some_branch] entries).
Shouldn't it be part of the gitflow package
Max Horn m...@quendi.de writes:
Aha, now I understand what this patch is about. So I would suggest this
alternate commit message:
remote-testgit: make it explicit clear that we use the 'done' feature
Previously we relied on passing '--use-done-feature ' to git fast-export,
which is
Max Horn m...@quendi.de writes:
On 11.11.2012, at 14:59, Felipe Contreras wrote:
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the
Felipe Contreras felipe.contre...@gmail.com writes:
They have been marked as UNINTERESTING for a reason, lets respect that.
...
The current behavior is most certainly not what we want. After this
patch, nothing gets exported, because nothing was selected (everything
is UNINTERESTING).
The
Felipe Contreras felipe.contre...@gmail.com writes:
It's way simpler. It exerceises the same features of remote helpers.
It's easy to read and understand. It doesn't depend on python.
It does _not_ exercise the python remote helper framework; there's
another tool and another test for that.
Felipe Contreras felipe.contre...@gmail.com writes:
Unfortunately they do not work.
As far as I can tell, more features simply mean one, no? Perhaps
remote-testgit: exercise non-default refspec feature
or something.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Felipe Contreras felipe.contre...@gmail.com writes:
This only makes sense for the python remote helpers framework.
A better explanation is sorely needed for this. If the test were
feeding python snippet to be sourced by python remote helper to be
tested, the new remote-testgit.bash would not
Felipe Contreras felipe.contre...@gmail.com writes:
We don't need a bare 'server' and an intermediary 'public'. The repos
can talk to each other directly; that's what we want to exercise.
The previous patch to remove the test (the one that covered a case
where a bug was fixed in an older
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Nov 11, 2012 at 2:59 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Since these are having some problems getting in, let me point out
which I think are important, and which not.
I finished reading the series, and found them
In particular, gcc issues an 'gzip_size' might be used uninitialized
warning (-Wuninitialized). However, this warning is a false positive,
since the 'gzip_size' variable would not, in fact, be used uninitialized.
In order to suppress the warning, we simply initialise the variable to
zero in it's
Hi Junio,
I noticed that the pu branch has two tests with number t0007, viz:
$ cd t
$ make test-lint-duplicates
duplicate test numbers: t0007
make: *** [test-lint-duplicates] Error 1
$
In particular, t/t0007-git-var.sh is added by branch 'jk/send-email-\
sender-prompt',
The threaded index-pack code did not fail for
me on cygwin at all during development, including tests, but failed
immediately I installed v1.7.11. On real repositories, it failed
intermittently. On some repos it always failed, on some it never
failed and on some others it would sometimes
On Wed, Nov 21, 2012 at 10:11 AM, Junio C Hamano gits...@pobox.com wrote:
I'd state it like this, but I may have guessed what Felipe intended
incorrectly.
remote-testgit: advertise done feature and write done ourselves
Instead of letting fast-export advertise the feature and ending
On Tue, Nov 20, 2012 at 02:21:40PM -0800, Junio C Hamano wrote:
Good catch. I think the return in the existing code suffers from the
same problem: it will bail on non-word characters in the $mi part, but
that part should allow arbitrary characters.
I am tired of keeping the expecting
On Wed, Nov 21, 2012 at 10:27:50AM +0100, Krzysztof Mazur wrote:
* pf/editor-ignore-sigint (2012-11-11) 5 commits
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the
On Wed, Nov 21, 2012 at 07:08:51PM +, Ramsay Jones wrote:
In particular, gcc issues an 'gzip_size' might be used uninitialized
warning (-Wuninitialized). However, this warning is a false positive,
since the 'gzip_size' variable would not, in fact, be used uninitialized.
In order to
Jeff King p...@peff.net writes:
The way for the Porcelain scripts to mimick the internal last one
wins has been to grab values out of --get-all and do the last one
wins themselves, and I agree that a mode that frees them from
having to worry about it is a good *addition*. I would even say
On Tue, Nov 20, 2012 at 09:08:36PM -0800, Junio C Hamano wrote:
With such a one-sided discussion, I've been having a hard time
convincing myself if Felipe's effort is making the interface better,
or just breaking it even more for existing remote helpers, only to
fit his world model better.
Jeff King p...@peff.net writes:
[1] Given the core-dumping behavior of SIGQUIT, I suspect it is not
nearly as widely used as SIGINT, but it sounds more like the
principle of least surprise to treat them the same.
Sounds sensible. I wonder what happens when the editor is suspended
;-)
On Wed, Nov 21, 2012 at 11:46:33AM -0800, Junio C Hamano wrote:
The problem is that scripts currently using --get are broken by
duplicate entries in include files, whereas internal git handles them
just fine. Introducing a new switch means that everybody also has to
start using it.
On Wed, Nov 21, 2012 at 11:53:04AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[1] Given the core-dumping behavior of SIGQUIT, I suspect it is not
nearly as widely used as SIGINT, but it sounds more like the
principle of least surprise to treat them the same.
Jeff King p...@peff.net writes:
So what do we want to do?
Nothing. We'd just let it graduate along with other topics, and
deal with a case where somebody screams, which is unlikely to happen
;-).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
27 matches
Mail list logo
