Jeff King 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 majord...@vger.ke
On Mon, Nov 19, 2012 at 04:48:22PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> Exact renames are the obvious one, but they are not handled here.
> >
> > That is half true. Before this change, we will find the same number
> > of needles and this function would have said "no diff
On Wed, Nov 21, 2012 at 11:53:04AM -0800, Junio C Hamano wrote:
> Jeff King 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.
>
> Soun
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
Jeff King 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
;-)
--
To unsu
jeff wrote:
> 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. Si
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 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
>> t
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 s
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
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 "exp
On Tue, Nov 20, 2012 at 11:08:43AM -0800, Junio C Hamano wrote:
> > Thanks. It had a few minor flaws (like a memory leak). I fixed those,
> > updated the tests, and split it out into a few more readable commits. In
> > the process, I managed to uncover and fix a few other memory leaks in
> > the a
On Wed, Nov 21, 2012 at 10:11 AM, Junio C Hamano 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
> i
> 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
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', whi
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
Felipe Contreras writes:
> On Sun, Nov 11, 2012 at 2:59 PM, Felipe Contreras
> 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 mostly sensible.
I'll send out comments on ind
Felipe Contreras 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 git-remote-testpy and tried to
Felipe Contreras 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 have any hope (nor
need) to
Felipe Contreras 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
> ---
> git-remote-testgit| 18 +
>
Felipe Contreras 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.
You mention why you _t
Felipe Contreras 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 old behaviour was an in
Max Horn 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 objec
Max Horn 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
> easy
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 git
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 remote.de
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 ma
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.
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
30 matches
Mail list logo
