* Re: TortoiseGit
From: Li Frank @ 2008-12-14 9:46 UTC (permalink / raw)
To: Geoffrey Lee, git
In-Reply-To: <83d7aaa40812131828r2eebd309oaf8531b88d4c925c@mail.gmail.com>
Yes!
TSVNcache.exe has not started porting! TSVNCache is used for overlay icon.
TortoiseMerge have not started porting!
I think this release is just a begining.
best regards
Frank Li
2008/12/14 Geoffrey Lee <geoffreyj.lee@gmail.com>:
> Hi Frank,
> I was just about to start a TortoiseGit project until I saw your project
> today. Would you like any help?
> -Geoffrey Lee
^ permalink raw reply
* Re: TortoiseGit
From: Li Frank @ 2008-12-14 9:47 UTC (permalink / raw)
To: Alcides Fonseca, git
In-Reply-To: <8836F27A-CEE2-4D72-B2D1-7A3D19975D4F@alcidesfonseca.com>
You post nothing!
^ permalink raw reply
* Re: is gitosis secure?
From: martin @ 2008-12-14 9:42 UTC (permalink / raw)
Cc: git
In-Reply-To: <alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm>
Dear David.
Why do you trust VPN more than the SSH?
I ask because I have just removed the "first VPN then SSH" solution in
favor for a SSH only solution using Gitosis just to get rid of the VPN
which I believe is less secure than SSH (well until I read you comments
below).
I thought I was doing something right for once but maybe I'm not?
Thanks and best regards
Martin
david@lang.hm wrote:
> this is really a reply to an earlier message that I deleted.
>
> the question was asked 'what would the security people like instead of
> SSH'
>
> as a security person who doesn't like how ssh is used for everything,
> let me list a couple of concerns.
>
> ssh is default allow (it lets you run any commands), you can lock it
> down with effort.
>
> ssh defaults to establishing a tunnel between machines that other
> network traffic can use to bypass your system. yes I know that with
> enough effort and control of both systems you can tunnel over
> anything, the point is that ssh is eager to do this for you (overly
> eager IMHO)
>
> ssh depends primarily on certificates that reside on untrusted
> machines. it can be made to work with tokens or such, but it takes a
> fair bit of effort.
>
> sshd runs as root on just about every system
>
> people trust ssh too much. they tend to think that anything is
> acceptable if it's done over ssh (this isn't a technical issue, but it
> is a social issue)
>
>
> what would I like to see in an ideal world?
>
> something that runs as the git user, does not enable tunneling, and
> only does the data transfer functions needed for a push. it should use
> off-the-shelf libraries for certificate authentication and tie into
> PAM for additional authentication.
>
> the authentication would not be any better than with SSH, but the rest
> would be better. I was very pleased to watch the git-daemon
> development, and the emphisis on it running with minimum privilages
> and provide just the functionality that was needed, and appropriately
> assuming that any connection from the outside is hostile until proven
> otherwise.
>
>
> what would I do with current tools?
>
> I would say that developers working from outside should VPN into the
> company network before doing the push with SSH rather than exposing
> the SSH daemon to the entire Internet.
>
> in the medium term, if the git-over-http gets finished, I would like
> to see a seperate cgi created to allow push as well. http is overused
> as a tunneling protocol, but it's easy to setup a server that can't do
> anything except what you want, so this tunneling is generally not a
> threat to servers (it's a horrible threat to client systems)
>
> David Lang
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-14 11:25 UTC (permalink / raw)
To: martin; +Cc: git
In-Reply-To: <4944D4F7.7050501@siamect.com>
On Sun, 14 Dec 2008, martin wrote:
> Dear David.
> Why do you trust VPN more than the SSH?
> I ask because I have just removed the "first VPN then SSH" solution in favor
> for a SSH only solution using Gitosis just to get rid of the VPN which I
> believe is less secure than SSH (well until I read you comments below).
> I thought I was doing something right for once but maybe I'm not?
> Thanks and best regards
> Martin
in part it's that a VPN is a single point of control for all remote
access.
If you use ssh you end up exposing all the individual machines
1. data leakage of just what machines exist to possibly hostile users.
2. the many machines are configured seperatly, frequently by different
people. this makes it far more likely that sometime some machine will get
misconfigured.
3. people who are focused on providing features have a strong temptation
to cut corners and just test that the feature works and not test that
everything that isn't supposed to work actually doesn't work. as a
result, in many companies there is a deliberate seperation (and tension)
between a group focused on controlling and auditing access and one that is
focused on creating fucntionality and features.
also from a polical/social point of view everyone recognises that if you
grant someone VPN access you are trusting them, but people don't seem to
think the same way with ssh.
David Lang
> david@lang.hm wrote:
>> this is really a reply to an earlier message that I deleted.
>>
>> the question was asked 'what would the security people like instead of SSH'
>>
>> as a security person who doesn't like how ssh is used for everything, let
>> me list a couple of concerns.
>>
>> ssh is default allow (it lets you run any commands), you can lock it down
>> with effort.
>>
>> ssh defaults to establishing a tunnel between machines that other network
>> traffic can use to bypass your system. yes I know that with enough effort
>> and control of both systems you can tunnel over anything, the point is that
>> ssh is eager to do this for you (overly eager IMHO)
>>
>> ssh depends primarily on certificates that reside on untrusted machines. it
>> can be made to work with tokens or such, but it takes a fair bit of effort.
>>
>> sshd runs as root on just about every system
>>
>> people trust ssh too much. they tend to think that anything is acceptable
>> if it's done over ssh (this isn't a technical issue, but it is a social
>> issue)
>>
>>
>> what would I like to see in an ideal world?
>>
>> something that runs as the git user, does not enable tunneling, and only
>> does the data transfer functions needed for a push. it should use
>> off-the-shelf libraries for certificate authentication and tie into PAM for
>> additional authentication.
>>
>> the authentication would not be any better than with SSH, but the rest
>> would be better. I was very pleased to watch the git-daemon development,
>> and the emphisis on it running with minimum privilages and provide just the
>> functionality that was needed, and appropriately assuming that any
>> connection from the outside is hostile until proven otherwise.
>>
>>
>> what would I do with current tools?
>>
>> I would say that developers working from outside should VPN into the
>> company network before doing the push with SSH rather than exposing the SSH
>> daemon to the entire Internet.
>>
>> in the medium term, if the git-over-http gets finished, I would like to see
>> a seperate cgi created to allow push as well. http is overused as a
>> tunneling protocol, but it's easy to setup a server that can't do anything
>> except what you want, so this tunneling is generally not a threat to
>> servers (it's a horrible threat to client systems)
>>
>> David Lang
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Matthieu Moy @ 2008-12-14 10:33 UTC (permalink / raw)
To: David Howells; +Cc: git, linux-kernel
In-Reply-To: <20081212182827.28408.40963.stgit@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> +So, you want to do some Linux kernel development? And you hear there's this
> +piece of software called 'GIT' that you probably ought to be using when dealing
> +with the kernel community?
I'm afraid too many people read this as "Git is only about kernel
hacking, if you're not a kernel hacker, find something else".
(and I think far too many people already think that indeed)
--
Matthieu
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Johannes Schindelin @ 2008-12-14 10:38 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: gitster, git
In-Reply-To: <200812132008.08543.markus.heidelberg@web.de>
Hi,
On Sat, 13 Dec 2008, Markus Heidelberg wrote:
> - __gitcomp "--prune --aggressive"
> + __gitcomp "--aggressive"
git gc --prune is deprecated? That's news to me.
How would you suggest, then, to remove the loose objects you always get
with conflicts in a merge?
Ciao,
Dscho
^ permalink raw reply
* Re: is gitosis secure?
From: Jakub Narebski @ 2008-12-14 10:40 UTC (permalink / raw)
To: david; +Cc: Sitaram Chamarty, git
In-Reply-To: <alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm>
david@lang.hm writes:
> this is really a reply to an earlier message that I deleted.
>
> the question was asked 'what would the security people like instead of
> SSH'
>
> as a security person who doesn't like how ssh is used for everything,
> let me list a couple of concerns.
>
> ssh is default allow (it lets you run any commands), you can lock it
> down with effort.
How is VPN better than that?
> ssh defaults to establishing a tunnel between machines that other
> network traffic can use to bypass your system. yes I know that with
> enough effort and control of both systems you can tunnel over
> anything, the point is that ssh is eager to do this for you (overly
> eager IMHO)
How is VPN better than that?
> ssh depends primarily on certificates that reside on untrusted
> machines. it can be made to work with tokens or such, but it takes a
> fair bit of effort.
There probably VPN differs...
> sshd runs as root on just about every system
And VPN doesn't?
[...]
The idea with using SSH was, I think, that it is easier and better to
use existing solution for authentication and authorization than roll
your own (see the case of CVS pserver, and Subversion svnserve).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Johannes Schindelin @ 2008-12-14 10:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i632mg9.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 14 Dec 2008, Junio C Hamano wrote:
> * mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
> - Add support for a pdf version of the user manual
>
> I do not have a new enough combination of dblatex and asciidoc myself
> but this would help interested people.
I haven't had a look at the patches, but isn't "pdflatex" supposed to be
the common way to get .pdf files from LaTeX sources?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-fast-import possible memory corruption problem
From: YONETANI Tomokazu @ 2008-12-14 10:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vskor2tfw.fsf@gitster.siamese.dyndns.org>
On Sat, Dec 13, 2008 at 09:53:55PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> >> As the `round out' takes place AFTER it found the room in the mem_pool,
> >> there's a small chance of p->next_free being set outside of the chosen
> >> area, up to (sizeof(uintmax_t) - 1) bytes. pool_strdup() is one of the
> >> functions which can trigger the problem, when pool_alloc() finds a room
> >> at the end of a pool entry and the requested length is not multiple of
> >> size(uintmax_t). I believe attached patch addresses this problem.
> >
> > Thanks -- do you mean your reproducible crash does not reproduce with the
> > patch anymore?
> >
> > I think your change to move the "round up" logic up in the codepath makes
> > perfect sense. But your patch seems to conflate totally unrelated change
> > to move memzero from the caller to callee into it, and I do not see the
> > reason why it should be that way. If the caller asked 10 bytes to calloc
> > from the pool, and the underlying pool allocator gives you a 16-byte
> > block, you only have to guarantee that the first 10 bytes are cleared, and
> > can leave the trailing padding 6 bytes at the end untouched.
>
> That is, something like this...
>
> fast-import.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git c/fast-import.c w/fast-import.c
> index 3c035a5..3276d5d 100644
[snip]
Yes, that was what it originally looked like, but after fixing the crash
I encountered another problem, and thought that I had to clear rounded up
area too. It turned out that the second problem has nothing to do with
[the pool allocator, but the data fed to git-fast-import. After fixing
the data, the git-fast-import with above patch finished successfully,
no more crashes.
^ permalink raw reply
* Re: is gitosis secure?
From: Jakub Narebski @ 2008-12-14 10:47 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git, Nix, Thomas Koch
In-Reply-To: <gi1qsl$22p$1@ger.gmane.org>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> On 2008-12-13, Nix <nix@esperi.org.uk> wrote:
> > telnet. I do not jest, this is our sysadmins' stated reasons for not
> > opening the git port and for tweaking their (mandatory) HTTP proxy to
> > block HTTP traffic from git.
>
> Wow -- my sympathies!
>
> But on occasion, when real or imaginary issues prevented me
> from making a live connection, I have used "git bundle" to
> do the job. Not as satisfactory as a real connection, but
> when you have a proper, non-fast-forwarding, repo as the
> "mother ship", git bundle with some custom procmail scripts
> on both sides can work OK enough.
Perhaps one would be interested in adding bundle support to gitweb.
The problem is in the interface, but I think in simplest case gitweb
could present 'bundle' link along snapshot link(s) in the 'heads' view
(showing branches), which link would generate bundle for a given
branch, starting from latest annotated tag. But this is only for
download...
Another solution would be to help with "smart" HTTP protocol,
i.e. git-over-http solution. This would hopefully change signature so
at least for some time it would pas proxy filters. Also only for
download.
BTW. is outgoing SSH transport (from network to outside) blocked as
well?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: is gitosis secure?
From: Jakub Narebski @ 2008-12-14 10:51 UTC (permalink / raw)
To: david; +Cc: martin, git
In-Reply-To: <alpine.DEB.1.10.0812140304320.17688@asgard.lang.hm>
david@lang.hm writes:
> On Sun, 14 Dec 2008, martin wrote:
>
> > Dear David.
> > Why do you trust VPN more than the SSH?
> > I ask because I have just removed the "first VPN then SSH" solution
> > in favor for a SSH only solution using Gitosis just to get rid of
> > the VPN which I believe is less secure than SSH (well until I read
> > you comments below).
> > I thought I was doing something right for once but maybe I'm not?
> > Thanks and best regards
> > Martin
>
> in part it's that a VPN is a single point of control for all remote
> access.
>
> If you use ssh you end up exposing all the individual machines
>
> 1. data leakage of just what machines exist to possibly hostile users.
Errr... what? One of established practices is expose only _one_
machine to outside; you have to SSH to gateway.
> 2. the many machines are configured seperatly, frequently by different
> people. this makes it far more likely that sometime some machine will
> get misconfigured.
See above.
> 3. people who are focused on providing features have a strong
> temptation to cut corners and just test that the feature works and not
> test that everything that isn't supposed to work actually doesn't
> work. as a result, in many companies there is a deliberate seperation
> (and tension) between a group focused on controlling and auditing
> access and one that is focused on creating fucntionality and features.
And that differs from VPN in what way?
> also from a polical/social point of view everyone recognises that if
> you grant someone VPN access you are trusting them, but people don't
> seem to think the same way with ssh.
Errr... what? I think everybody knows that unrestricted SSH access
(without limiting done by shell used) means that you trust user.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: is gitosis secure?
From: martin @ 2008-12-14 11:02 UTC (permalink / raw)
Cc: git
In-Reply-To: <alpine.DEB.1.10.0812140304320.17688@asgard.lang.hm>
david@lang.hm wrote:
> On Sun, 14 Dec 2008, martin wrote:
>
>> Dear David.
>> Why do you trust VPN more than the SSH?
>> I ask because I have just removed the "first VPN then SSH" solution
>> in favor for a SSH only solution using Gitosis just to get rid of the
>> VPN which I believe is less secure than SSH (well until I read you
>> comments below).
>> I thought I was doing something right for once but maybe I'm not?
>> Thanks and best regards
>> Martin
>
> in part it's that a VPN is a single point of control for all remote
> access.
>
> If you use ssh you end up exposing all the individual machines
>
> 1. data leakage of just what machines exist to possibly hostile users.
>
> 2. the many machines are configured seperatly, frequently by different
> people. this makes it far more likely that sometime some machine will
> get misconfigured.
>
> 3. people who are focused on providing features have a strong
> temptation to cut corners and just test that the feature works and not
> test that everything that isn't supposed to work actually doesn't
> work. as a result, in many companies there is a deliberate seperation
> (and tension) between a group focused on controlling and auditing
> access and one that is focused on creating fucntionality and features.
>
> also from a polical/social point of view everyone recognises that if
> you grant someone VPN access you are trusting them, but people don't
> seem to think the same way with ssh.
>
> David Lang
>
I opened port 22 in the firewall to just those hosts that I need to
reach, which is one in this case...the rest of the machines I cannot reach.
I did a brief port scan and the thing is silent... so I don't think I
reveal any of the other hosts... but I should not say is it's secure
with your measures...
Your point two I don't understand... If you are in charge of the
firewall you also know what machines you let people reach. If these
machines are numerous then I think there is a management problem
somewhere else...
Point 3 is correct but I fail to see how this is less of a problem with
VPN than SSH.
Thanks and Best regards
Martin
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Jakub Narebski @ 2008-12-14 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i632mg9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ----------------------------------------------------------------
> [New Topics]
>
> * jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
> - gitweb: cache $parent_commit info in git_blame()
> - gitweb: A bit of code cleanup in git_blame()
> - gitweb: Move 'lineno' id from link to row element in git_blame
>
> I've briefly looked at the resurrection of Ajaxy blame that comes on top
> of this series and it looked promising.
AJAXy blame in my opinion is not yet ready. Close, but not yet.
At minimal I'd have to remove or separate the 'time to generate'
patch.
I wonder if it should made into 1.6.1 for the performance improvements
in 'blame' view...
> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
> - gitweb: Optional grouping of projects by category
> - gitweb: Split git_project_list_body in two functions
> - gitweb: Modularized git_get_project_description to be more generic
It shapes nicely, and I think with one more commit on top (or with
extending topmost commit) we can have categories sorted in given
order, and not hardcoded to always be in alphabetic order.
> ----------------------------------------------------------------
> [Post 1.6.1 items]
>
> * gb/gitweb-patch (Sat Dec 6 16:02:35 2008 +0100) 3 commits
> - gitweb: link to patch(es) view from commit and log views
> - gitweb: add patches view
> - gitweb: add patch view
>
> Updated series. Reviews and Acks?
I'll try to find time to review (and most probably Ack) later today.
> ----------------------------------------------------------------
> [Graduated to "master"]
>
> * jn/gitweb-utf8 (Mon Dec 1 19:01:42 2008 +0100) 1 commit
> + gitweb: Fix handling of non-ASCII characters in inserted HTML
> files.
>
> A bugfix.
What about
+ gitweb: Fix bug in insert_file() subroutine
Isn't it in the same topic branch?
I am very sorry for buginess of this patch series...
[...]
> ----------------------------------------------------------------
> [On Hold]
>
> * jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
> - git-am --forge: add Signed-off-by: line for the author
> - git-am: clean-up Signed-off-by: lines
> - stripspace: add --log-clean option to clean up signed-off-by:
> lines
> - stripspace: use parse_options()
> - Add "git am -s" test
> - git-am: refactor code to add signed-off-by line for the committer
What happened to this series to be so stale^Wstalled?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Jeff King @ 2008-12-14 11:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <alpine.DEB.1.00.0812141137350.2014@eeepc-johanness>
On Sun, Dec 14, 2008 at 11:38:17AM +0100, Johannes Schindelin wrote:
> > - __gitcomp "--prune --aggressive"
> > + __gitcomp "--aggressive"
> git gc --prune is deprecated? That's news to me.
Check out 9e7d501 (builtin-gc.c: deprecate --prune, it now really has no
effect, 2008-05-09).
Which annoyingly has no discussion about _why_ it no longer has an
effect. But I suspect it has something to do with 25ee973 (gc: call
"prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
-Peff
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Johannes Schindelin @ 2008-12-14 11:17 UTC (permalink / raw)
To: Jeff King; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <20081214111213.GA6499@coredump.intra.peff.net>
Hi,
On Sun, 14 Dec 2008, Jeff King wrote:
> On Sun, Dec 14, 2008 at 11:38:17AM +0100, Johannes Schindelin wrote:
>
> > > - __gitcomp "--prune --aggressive"
> > > + __gitcomp "--aggressive"
> > git gc --prune is deprecated? That's news to me.
>
> Check out 9e7d501 (builtin-gc.c: deprecate --prune, it now really has no
> effect, 2008-05-09).
>
> Which annoyingly has no discussion about _why_ it no longer has an
> effect. But I suspect it has something to do with 25ee973 (gc: call
> "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
Oops.
But I thought that git gc --prune does expire _all_ dangling loose
objects _now_, not with --expire 2.weeks.ago.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Jeff King @ 2008-12-14 11:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0812141142300.2014@eeepc-johanness>
On Sun, Dec 14, 2008 at 11:44:23AM +0100, Johannes Schindelin wrote:
> > * mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
> > - Add support for a pdf version of the user manual
> >
> > I do not have a new enough combination of dblatex and asciidoc myself
> > but this would help interested people.
>
> I haven't had a look at the patches, but isn't "pdflatex" supposed to be
> the common way to get .pdf files from LaTeX sources?
But we don't have latex sources; we have docbook sources. Hence dblatex
(which does the conversion to PDF internally, so it is a bit of a
misnomer).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Jakub Narebski @ 2008-12-14 11:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0812141142300.2014@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 14 Dec 2008, Junio C Hamano wrote:
>
> > * mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
> > - Add support for a pdf version of the user manual
> >
> > I do not have a new enough combination of dblatex and asciidoc myself
> > but this would help interested people.
>
> I haven't had a look at the patches, but isn't "pdflatex" supposed to be
> the common way to get .pdf files from LaTeX sources?
The problem is that AsciiDoc, from what I understand, by itself
generates only XML-ish formats, namely HTML, XHTML and DocBook, and
the rest of formats are generated in postprocessing step by extra
tools from DocBook format:
* manpages require xmlto
* info requires docbook2X and makeinfo
* PDF requires dblatex (db = DocBook), or FOP and xmlto
So the answer is that AsciiDoc does not generate LaTeX, so pdflatex
would be not enough.
By the way, from the AsciiDoc page:
NOTE: Owning to to other commitments, Benjamin is unable to maintain
this backend. I don't have the expertise or time to take this
on consequently the LaTeX backend has not been tested or
updated since AsciiDoc version 8.2.7 and is currently
unsupported.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Jeff King @ 2008-12-14 11:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <alpine.DEB.1.00.0812141216120.2014@eeepc-johanness>
On Sun, Dec 14, 2008 at 12:17:07PM +0100, Johannes Schindelin wrote:
> > Which annoyingly has no discussion about _why_ it no longer has an
> > effect. But I suspect it has something to do with 25ee973 (gc: call
> > "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
>
> Oops.
>
> But I thought that git gc --prune does expire _all_ dangling loose
> objects _now_, not with --expire 2.weeks.ago.
Nope, see 25ee973. You explicitly wrote:
Note that this new behaviour makes "--prune" be a no-op.
That being said, I think that is perhaps a reasonable thing for --prune
to do (and I don't think there is any conflict with the name, because
that is what it _used_ to do before becoming a no-op). But nobody has
actually implemented it.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Johannes Schindelin @ 2008-12-14 11:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20081214111548.GB6499@coredump.intra.peff.net>
Hi,
On Sun, 14 Dec 2008, Jeff King wrote:
> On Sun, Dec 14, 2008 at 11:44:23AM +0100, Johannes Schindelin wrote:
>
> > > * mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
> > > - Add support for a pdf version of the user manual
> > >
> > > I do not have a new enough combination of dblatex and asciidoc myself
> > > but this would help interested people.
> >
> > I haven't had a look at the patches, but isn't "pdflatex" supposed to be
> > the common way to get .pdf files from LaTeX sources?
>
> But we don't have latex sources; we have docbook sources. Hence dblatex
> (which does the conversion to PDF internally, so it is a bit of a
> misnomer).
Indeed, I was fooled.
Thanks for the clarification,
Dscho
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Jakub Narebski @ 2008-12-14 11:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <alpine.DEB.1.00.0812141137350.2014@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 13 Dec 2008, Markus Heidelberg wrote:
>
> > - __gitcomp "--prune --aggressive"
> > + __gitcomp "--aggressive"
>
> git gc --prune is deprecated? That's news to me.
More like "git gc --prune" is no-op now.
> How would you suggest, then, to remove the loose objects you always get
> with conflicts in a merge?
"git gc" does pruning of loose objects, but protected by grace period
for loose objects with gc.pruneexpire
You always have (admittedly lowe level) git-prune.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Let git remote accept up as alias to update
From: Jeff King @ 2008-12-14 11:25 UTC (permalink / raw)
To: Alexey Zaytsev; +Cc: git
In-Reply-To: <20081213181704.20126.4200.stgit@zaytsev.su>
On Sat, Dec 13, 2008 at 09:18:56PM +0300, Alexey Zaytsev wrote:
> Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
> ---
>
> Don't know why, but I keep typing remote up instead of
> remote update. As update is probably by far the most
> used remote action, can we please have this alias?
Hmm. The usual answer for requests like this is "make your own alias".
But usually they are for primary command aliases (e.g., "co" for
"checkout"), and this is a sub-command. So you are actually stuck doing:
git config alias.rup "remote update"
which is maybe better (even less typing) but is not exactly what you
asked for.
I think even nicer than an explicit "up" alias would be to accept any
prefix as long as it was unique. However, I think a scheme like that
would only make sense if it was used fairly universally, and the current
code is not amenable to doing it for regular commands (it doesn't
actually have a complete list of commands -- it just tries to exec what
you tell it). However, it could be refactored to do so.
-Peff
^ permalink raw reply
* Re: is gitosis secure?
From: Sitaram Chamarty @ 2008-12-14 11:42 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.10.0812140304320.17688@asgard.lang.hm>
On 2008-12-14, david@lang.hm <david@lang.hm> wrote:
> On Sun, 14 Dec 2008, martin wrote:
>> Why do you trust VPN more than the SSH?
> in part it's that a VPN is a single point of control for all remote
> access.
>
> If you use ssh you end up exposing all the individual machines
Need not be true. None of my internal servers aer even
accessible from the outside world; they're all in RFC1918
space and there's only one gateway. This *is* my single
point of control.
I can setup different port numbers to forward to different
internal servers (ssh, http, whatever I wish); that may
sound like a form of "exposing" but in reality it's a lot
*more* restrictive than setting up a VPN and granting access
to it.
I actually don't like VPNs; they imply that you're "inside"
the network in some way, and I hate blurring that
distinction. If I'm outside, I want to be acutely aware of
it, and the fact that I can't even ping one of the inside
hosts or see what's on it, or do anything other than what is
specifically allowed by the gateway, is one way of ensuring
this.
^ permalink raw reply
* Re: TortoiseGit
From: Alcides Fonseca @ 2008-12-14 12:26 UTC (permalink / raw)
To: Li Frank; +Cc: git
In-Reply-To: <1976ea660812140147o40e014cbn46d920781db029a1@mail.gmail.com>
Em 2008/12/14, às 09:47, Li Frank escreveu:
> You post nothing!
I'm used to send a first email to subscribe to some mailing list. I'm
sorry for that.
I wanted to suggest you to have your main git repo in github.com, that
is like a social network of opensource projects. It's also free, and
it will give the project more exposition, that may mean more
contributors.
Just a suggestion ;)
Alcides Fonseca
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Li Frank @ 2008-12-14 12:27 UTC (permalink / raw)
To: Tim Visher, git
In-Reply-To: <c115fd3c0812130621p5df742ffs98d69cd922ebc972@mail.gmail.com>
Thank you for interesting this project. This release is very early stage.
Weclome contribute anything, including coding, testing, document and so on.
2008/12/13 Tim Visher <tim.visher@gmail.com>:
> On Sat, Dec 13, 2008 at 3:33 AM, 李智 <lznuaa@gmail.com> wrote:
>
>> TortoiseGit is porting from TortoiseSVN.
>
> Thanks so much for this!
>
> My team and I were just talking about how the biggest barrier to entry
> at this point for _some_ of us has been the lack of a great tool like
> Tortoise for Git. My opinion was that someone would soon write it.
> And lo-and-behold, here it is!
>
> I'll look forward to watching this progress, and continue happily
> using my cli version the same.
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://burningones.com/
> http://five.sentenc.es/ - Spend less time on e-mail
>
^ permalink raw reply
* Followup: management of OO files - warning about "rezip" approach
From: Sergio Callegari @ 2008-12-14 13:08 UTC (permalink / raw)
To: git
Hi, some times ago, i considered ways to achieve a smarter management of
openoffice files with git.
The thread started at:
http://article.gmane.org/gmane.comp.version-control.git/95951
There, a "rezip" script was proposed to store OO files uncompressed into git
repos, so that the compression and delta machinery of git could operate at its
best with them.
Appartently, the script rose some interest. In the following days I received
quite a few corrections/enhancements proposals for which all the posters I thank.
Also I was asked to upload the script and instructions relative to its adoption
together with .gitattributes to the git wiki.
This I didn't do (I do not know if someone else might have done it) because I
first wanted to be absolutely sure that the script would cause no problems to
anybody.
Unfortunately, I now see that there is an issue, so I am sending a warning.
The problem stems from the fact that ODF files, due to the zip compression also
might store pieces of info that are completely irrelevant. For instance zip
stores ownership of member files. This is why in the rezip script I initially
started to unzip files with -X.
Now, this seems to be looking for trouble when repos are passed from one user to
another one.
When we uncompress and ODF file for storing we should probably scrap away the
member ownership info alltogether. Note that this is not equivalent to not using
-X. Not using -X would mean "changing" member owernership when an ODF file is
passed from one user to another one. Using -X seemed to me the correct thing to
do as it allowed to leave untouched the member ownership. However, -X fails
when user A has no permission to create files as user B.
I found out about this issue by having accounts on many hosts, where my
alphanumeric user ID maps to different numeric IDs.
I will look better at this as soon as I have time. So far, please just be
careful. My guess is that we should not use -X on "unzip" but use it on "zip".
E.g. patch the rezip script so that
PROFILE_UNZIP_ODF_UNCOMPRESS='-b -qq'
PROFILE_ZIP_ODF_UNCOMPRESS='-q -r -D -0 -X'
PROFILE_UNZIP_ODF_COMPRESS='-b -qq'
PROFILE_ZIP_ODF_COMPRESS='-q -r -D -6 -X'
Sergio
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox