On Wed, Jan 11, 2012 at 5:30 PM, jaalto wrote:
> On 2012-01-11 16:37, Sitaram Chamarty wrote:
> | Please check if 'test -t 0' is sufficient to test this and let me know.
>
> Under Emacs M-x shell:
>
> $ test -t 0 ; echo $?
> 0
And I know under a nor
On Wed, Jan 11, 2012 at 3:39 PM, jaalto wrote:
> Using EDITOR is standard thing. But this is not related to discussion
> where program makes assumptions about being run under controlling
> terminal.
That's the first time you mentioned "controlling terminal", i.e., more
generic situation than ema
On Wed, Jan 11, 2012 at 2:36 PM, jaalto wrote:
> The current code makes assumptions about environment that are not
> necessarily true.
Please just $EDITOR to whatever you want; vi is not the default; it's
the fallback if $EDITOR is not set.
I didn't invent $EDITOR; it's apparently some sort o
On Wed, Jan 11, 2012 at 1:59 PM, jaalto wrote:
> On 2012-01-11 03:31, Sitaram Chamarty wrote:
> | On Wed, Jan 11, 2012 at 12:12 AM, Jari Aalto wrote:
> | > retitle 653968 [PATCH] gitolite: gl-setup doesn't warn it opens another
> editor (Emacs M-x shell)
> | > forward
However, I realise now that the "-q" was not documented. Sorry about
that; the following documentation changes have now been pushed to both
github and googlecode sites:
https://github.com/sitaramc/gitolite/commit/c15ceeb3eb37666435499d3d7dcb144fbaa0990d
(And although I believe an instruction to
On Wed, Jan 11, 2012 at 12:12 AM, Jari Aalto wrote:
> retitle 653968 [PATCH] gitolite: gl-setup doesn't warn it opens another
> editor (Emacs M-x shell)
> forwarded 653968 Sitaram Chamarty
> thanks
>
> Sitaram, could you apply this patch to fix Debian bug:
>
> h
quit
(I believe that lets the BTS system not react to this email but just record it)
On Sat, Jan 7, 2012 at 7:52 AM, Sitaram Chamarty wrote:
> I will do that (tag it v2.2.1) and push this weekend.
fixed, tested, and pushed.
Until this makes it into your systems, the workaround is to del
Rhonda,
This should be considered my fault, in that v2.2 had a bug in
gl-setup, (wouldn't deal well with blank lines in
~/.ssh/authorized_keys), I fixed it a few commits later, but -- and
this is the part that is my fault -- did not tag it so maintainers
could get it.
I will do that (tag it v2.2.
On Sat, Mar 27, 2010 at 02:34:01PM +0100, Gerfried Fuchs wrote:
> retitle 550817 RFP: gitolite -- standalone, souped-up version of gitosis
> thanks
>
> I don't want to be considered to be the blocking bit here so I rather
> turn this into an RFP. There are various reasons why I didn't provide a
>
On Wed, Feb 10, 2010 at 5:20 PM, Sitaram Chamarty wrote:
> Hi Rhonda, Martin (and any others),
>
> Could you please take a look at the new "dps" branch of gitolite on
> github when you get a chance? The latest commit is
> http://github.com
Hi Rhonda, Martin (and any others),
Could you please take a look at the new "dps" branch of gitolite on
github when you get a chance? The latest commit is
http://github.com/sitaramc/gitolite/commit/1ecdd4618e58c03dd7aea39bab34f3244d0135f7
and it's basically my attempt to make it easier for packag
On Thu, Feb 04, 2010 at 08:38:49AM +1300, martin f krafft wrote:
> If the user ran easy-install, then the source files are likely to
> live on a separate machine, outside of our control. The user may not
> be aware of that fact (at least not consciously), and might not know
> that s/he is expected
itories.
Gitolite goes further than gitosis. Its primary target is corporate
environments where the ability to restrict who can push to what branch
is also important. Over the past few weeks it has grown a bit beyond
that primary reason, and acquired several other neat features described
in
13 matches
Mail list logo
