* 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: 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: [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: [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: 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: 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: 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: 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: [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: 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: 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: [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: [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: 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: 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: 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: 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
* What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Junio C Hamano @ 2008-12-14 8:24 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
As we have already passed -rc2, things queued in 'next' let alone 'pu' are
unlikely to be merged to 'master' by the end of year unless otherwise
noted.
----------------------------------------------------------------
[New Topics]
* wp/add-p-goto (Thu Dec 4 10:22:40 2008 +0000) 2 commits
+ Add 'g' command to go to a hunk
+ Add subroutine to display one-line summary of hunks
* 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.
* 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.
* np/auto-thread (Sat Dec 13 15:06:40 2008 -0500) 2 commits
+ pack-objects: don't use too many threads with few objects
+ autodetect number of CPUs by default when using threads
* 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
----------------------------------------------------------------
[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?
* lt/reset-merge (Wed Dec 3 18:00:12 2008 -0800) 2 commits
+ Document "git-reset --merge"
+ Add 'merge' mode to 'git reset'
With updated documents.
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
. In add --patch, Handle K,k,J,j slightly more gracefully.
. Add / command in add --patch
. git-add -i/-p: Change prompt separater from slash to comma
I am still holding onto this earlier topic to add '/' subcommand to allow
finding a hunk with given text, but I'd rather not merge/rebase it on top
of wp/add-p-goto series myself. Waiting for a reroll.
* cb/mergetool (Fri Dec 12 21:48:41 2008 +0000) 4 commits
- mergetool: Don't keep temporary merge files unless told to
- mergetool: Add prompt to continue after failing to merge a file
- Add -y/--no-prompt option to mergetool
- Fix some tab/space inconsistencies in git-mergetool.sh
Updated series. Waiting for comments from the original author (Ted) and
other interested parties.
----------------------------------------------------------------
[Graduated to "master"]
* jc/rm-i-t-a (Fri Nov 28 19:56:34 2008 -0800) 5 commits
+ git add --intent-to-add: do not let an empty blob be committed by
accident
+ git add --intent-to-add: fix removal of cached emptiness
+ builtin-rm.c: explain and clarify the "local change" logic
+ Merge branch 'nd/narrow' (early part) into jc/add-i-t-a
+ Extend index to save more flags
As intent-to-add index entry is a new feature for 1.6.1, it probably is a
good idea to merge this to 'master'. Nitpicks and bugfixes are very much
appreciated.
* 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.
----------------------------------------------------------------
[Will merge to "master" soon]
What are you looking for? We are in -rc ;-)
----------------------------------------------------------------
[On Hold]
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
Rebased to 'master', that introduced NO_PTHREADS.
* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
- bisect: add "--no-replace" option to bisect without using replace
refs
- rev-list: make it possible to disable replacing using "--no-
bisect-replace"
- bisect: use "--bisect-replace" options when checking merge bases
- merge-base: add "--bisect-replace" option to use fixed up revs
- commit: add "bisect_replace_all" prototype to "commit.h"
- rev-list: add "--bisect-replace" to list revisions with fixed up
history
- Documentation: add "git bisect replace" documentation
- bisect: add test cases for "git bisect replace"
- bisect: add "git bisect replace" subcommand
I really hate the idea of introducing a potentially much more useful
replacement of the existing graft mechanism and tie it very tightly to
bisect, making it unusable from outside.
(1) I do not think "bisect replace" workflow is a practical and usable
one;
(2) The underlying mechanism to express "this object replaces that other
object" is much easier to work with than what the graft does which is
"the parents of this commit are these", and idea to use the normal
ref to point at them means this can potentially be used for
transferring the graft information across repositories, which the
current graft mechanism cannot do.
(3) Because I like the aspect (2) of this series so much, it deeply
disappoints and troubles me that this is implemented minimally near
the surface, and that it is controlled by the "bisect" Porcelain
alone, by explicitly passing command line arguments.
I think a mechanism like this should be added to replace grafts, but it
should always be enabled for normal revision traversal operation, while
always disabled for object enumeration and transfer operation (iow, fsck,
fetch and push should use the real ancestry information recorded in the
underlying objects, while rev-list, log, etc. should always use the
replaced objects). I have a suspicion that even cat-file could honor it.
* nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
- wt-status: show sparse checkout info
- Introduce default sparse patterns (core.defaultsparse)
- checkout: add new options to support sparse checkout
- clone: support sparse checkout with --sparse-checkout option
- unpack_trees(): add support for sparse checkout
- unpack_trees(): keep track of unmerged entries
- Introduce "sparse patterns"
- Merge branch 'master' into nd/narrow
+ t2104: touch portability fix
+ grep: skip files outside sparse checkout area
+ checkout_entry(): CE_NO_CHECKOUT on checked out entries.
+ Prevent diff machinery from examining worktree outside sparse
checkout
+ ls-files: Add tests for --sparse and friends
+ update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
+ update-index: refactor mark_valid() in preparation for new options
+ ls-files: add options to support sparse checkout
+ Introduce CE_NO_CHECKOUT bit
Kicked back to 'on hold' until 1.6.1 final by popular demand; will be
dropped from 'next' (see recent discussion on the interaction between the
checkout area and commands such as "grep").
* jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits
- clone: test the new HEAD detection logic
- Merge commit 'HEAD@{2}' into HEAD
- upload-pack: send the HEAD information
- clone: find the current branch more explicitly
- connect.c::read_extra_info(): find where HEAD points at
- connect.c::read_extra_info(): prepare to receive more than server
capabilities
- get_remote_heads(): refactor code to read "server capabilities"
This is no way meant for 1.6.1, let alone next, yet.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
* 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
^ permalink raw reply
* What's in git.git (Dec 2008, #02; Sun, 14)
From: Junio C Hamano @ 2008-12-14 8:24 UTC (permalink / raw)
To: git
There are a handful fixes since 1.6.1-rc2 on 'master' and I am hoping that
we can do -rc3 later today, and declare the 1.6.1 final on the 20th or
so.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Brandon Casey (11):
t7700: demonstrate mishandling of objects in packs with a .keep file
packed_git: convert pack_local flag into a bitfield and add pack_keep
pack-objects: new option --honor-pack-keep
repack: don't repack local objects in packs with .keep file
repack: do not fall back to incremental repacking with [-a|-A]
builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
t7700: demonstrate mishandling of loose objects in an alternate ODB
sha1_file.c: split has_loose_object() into local and non-local
counterparts
pack-objects: extend --local to mean ignore non-local loose objects too
t7700: test that 'repack -a' packs alternate packed objects
repack: only unpack-unreachable if we are deleting redundant packs
Davide Libenzi (1):
xdiff: give up scanning similar lines early
Deskin Miller (1):
git-svn: Make following parents atomic
Jakub Narebski (1):
gitweb: Make project specific override for 'grep' feature work
Jeff King (2):
commit: Fix stripping of patch in verbose mode.
tag: delete TAG_EDITMSG only on successful tag
Jim Meyering (1):
git-config.txt: fix a typo
Johannes Sixt (1):
compat/mingw.c: Teach mingw_rename() to replace read-only files
Junio C Hamano (2):
GIT 1.6.0.5
work around Python warnings from AsciiDoc
Linus Torvalds (1):
fsck: reduce stack footprint
Matt McCutchen (1):
"git diff <tree>{3,}": do not reverse order of arguments
Miklos Vajna (1):
http.c: use 'git_config_string' to get 'curl_http_proxy'
Nicolas Pitre (1):
make sure packs to be replaced are closed beforehand
Thomas Rast (1):
fetch-pack: Avoid memcpy() with src==dst
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (3):
Make some of fwrite/fclose/write/close failures visible
Make chdir failures visible
Report symlink failures in merge-recursive
Alexander Potashev (2):
Fix typos in documentation
Fix typo in comment in builtin-add.c
Alexey Borzenkov (1):
Define linkgit macro in [macros] section
Brandon Casey (1):
git-branch: display sha1 on branch deletion
Deskin Miller (1):
git-svn: Make branch use correct svn-remote
Jakub Narebski (2):
gitweb: Fix handling of non-ASCII characters in inserted HTML files
gitweb: Fix bug in insert_file() subroutine
Jeff King (6):
add stage to gitignore
reorder ALLOW_TEXTCONV option setting
diff: allow turning on textconv explicitly for plumbing
diff: fix handling of binary rewrite diffs
diff: respect textconv in rewrite diffs
rebase: improve error messages about dirty state
Junio C Hamano (16):
builtin-rm.c: explain and clarify the "local change" logic
git add --intent-to-add: fix removal of cached emptiness
git add --intent-to-add: do not let an empty blob be committed by
accident
Install git-stage in exec-path
git-am --whitespace: do not lose the command line option
git-am: propagate -C<n>, -p<n> options as well
git-am: propagate --3way options as well
Test that git-am does not lose -C/-p/--whitespace options
git-am: rename apply_opt_extra file to apply-opt
Update draft release notes to 1.6.1
Update draft release notes for 1.6.1
Revert "git-stash: use git rev-parse -q"
Point "stale" 1.6.0.5 documentation from the main git documentation page
builtin-checkout.c: check error return from read_cache()
read-cache.c: typofix in comment
Fix t4031
Markus Heidelberg (1):
builtin-commit: remove unused message variable
Miklos Vajna (5):
filter-branch: use git rev-parse -q
lost-found: use git rev-parse -q
pull: use git rev-parse -q
rebase: use git rev-parse -q
submodule: use git rev-parse -q
Nguyễn Thái Ngọc Duy (1):
Extend index to save more flags
Ralf Wildenhues (1):
Improve language in git-merge.txt and related docs
Tor Arvid Lund (2):
git-p4: Fix bug in p4Where method.
git-p4: Fix regression in p4Where method.
^ permalink raw reply
* Re: [PATCH] git-fast-import possible memory corruption problem
From: Junio C Hamano @ 2008-12-14 5:53 UTC (permalink / raw)
To: YONETANI Tomokazu; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vd4fv4e3u.fsf@gitster.siamese.dyndns.org>
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
--- c/fast-import.c
+++ w/fast-import.c
@@ -554,6 +554,10 @@ static void *pool_alloc(size_t len)
struct mem_pool *p;
void *r;
+ /* round up to a 'uintmax_t' alignment */
+ if (len & (sizeof(uintmax_t) - 1))
+ len += sizeof(uintmax_t) - (len & (sizeof(uintmax_t) - 1));
+
for (p = mem_pool; p; p = p->next_pool)
if ((p->end - p->next_free >= len))
break;
@@ -572,9 +576,6 @@ static void *pool_alloc(size_t len)
}
r = p->next_free;
- /* round out to a 'uintmax_t' alignment */
- if (len & (sizeof(uintmax_t) - 1))
- len += sizeof(uintmax_t) - (len & (sizeof(uintmax_t) - 1));
p->next_free += len;
return r;
}
^ permalink raw reply related
* Re: is gitosis secure?
From: david @ 2008-12-14 5:40 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <gi1qsl$22p$1@ger.gmane.org>
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
^ permalink raw reply
* Re: [PATCH v3] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Junio C Hamano @ 2008-12-14 3:54 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: git, jnareb, ae, j.sixt
In-Reply-To: <1229201231-12586-1-git-send-email-marcel@oak.homeunix.org>
"Marcel M. Cary" <marcel@oak.homeunix.org> writes:
> I also removed the "pwd -P" from the unit test.
Hmm, really...?
>> > +# Prove that the remote end really is a repo, and other commands
>> > +# work fine in this context.
>> > +#
>> > +test_debug "
>> > + test_expect_success 'pushing from symlinked subdir' '
>> > +
>> > + git push
>> > + '
>> > +"
>>
>> Why should this be hidden inside test_debug?
>
> I'm not particularly trying to test "git push" or "git pull" in general
> here. That's also why the other "git pull" was in a test_debug. I
> thought it was really only useful to someone trying to understand the
> contents of the test file. There are other files that cover push and
> pull. Do you think these test cases should run all the time here?
I'd say so. Your supporting argument could be "See, push works just fine
with this layout, but pull doesn't because it is a shell script that can
be fooled, and this change is to fix the inconsistencies between them."
Having these test enabled would be a good way to do so. Then it becomes
irrelevant if "jump into the middle of a directory hierarchy sideways via
symlink" is worth supporting or not ;-)
But whether it is inside test_debug or not, the test should check not just
the exit status from 'git push' but also check what happened to the
receiving repository at least to make sure it is pushing to the location
you are expecting it to.
> diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
> new file mode 100755
> index 0000000..05854b4
> --- /dev/null
> +++ b/t/t2300-cd-to-toplevel.sh
> @@ -0,0 +1,37 @@
> +#!/bin/sh
> +
> +test_description='cd_to_toplevel'
> +
> +. ./test-lib.sh
> +
> +test_cd_to_toplevel () {
> + test_expect_success "$2" '
> + (
> + cd '"'$1'"' &&
> + . git-sh-setup &&
> + cd_to_toplevel &&
> + [ "$(pwd -P)" = "$TOPLEVEL" ]
> + )
> + '
> +}
The quoting of $1 here is a bit tricky, but I think it is good enough for
directory names used in tests that use this function.
^ permalink raw reply
* Re: [PATCH] git-fast-import possible memory corruption problem
From: Junio C Hamano @ 2008-12-14 3:42 UTC (permalink / raw)
To: YONETANI Tomokazu; +Cc: git
In-Reply-To: <20081214020822.GB4121@les.ath.cx>
YONETANI Tomokazu <qhwt+git@les.ath.cx> writes:
> While trying to convert NetBSD CVS repository to Git, I've been
> experiencing 100% reproducible crash of git-fast-import. After
> poking here and there and I noticed a dubious code fragment in
> pool_alloc():
> :
>
> r = p->next_free;
> /* round out to a 'uintmax_t' alignment */
> if (len & (sizeof(uintmax_t) - 1))
> len += sizeof(uintmax_t) - (len & (sizeof(uintmax_t) - 1));
> p->next_free += len;
> return r;
>
> 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.
^ permalink raw reply
* Sending a threaded patch series with Evolution
From: Matt McCutchen @ 2008-12-14 2:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3hc57g28b.fsf@localhost.localdomain>
On Sat, 2008-12-13 at 14:05 -0800, Jakub Narebski wrote:
> By the way, your message [PATCH 2/2] should be threaded, i.e. be
> response to [PATCH 1/2] (or to cover letter [PATCH 0/2]), to not
> mistake it with other [PATCH 2/2] patches.
I'm using Evolution 2.24 as my mail client, and I have a wrapper script
"git draft-patch" that runs "git format-patch" and loads the patches
into my Evolution Drafts folder so I can look them over in the composer
and add non-commit-message text below the "---" if I wish before
sending. I did pass --thread, but the composer changed the Message-Id,
breaking the threading.
I'll try to get this right in the future. I can see two approaches to
doing so:
1. Check over / edit the patches in a text editor before loading them
into Drafts, and then send them by moving them directly to Outbox
(without using the composer) so that the Message-Id won't change.
2. Send the first patch, then manually edit the Message-Id Evolution
assigned it into the second patch, etc.
Neither of these approaches is particularly nice. Does anyone have a
better idea?
--
Matt
^ permalink raw reply
* Re: is gitosis secure?
From: Sitaram Chamarty @ 2008-12-14 2:26 UTC (permalink / raw)
To: git
In-Reply-To: <87hc58hwmi.fsf@hades.wkstn.nix>
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.
To do that with a public repo you'd have to mirror that on a
home machine and let your restricted environment work
against that.
> Do not underestimate the stupidity and hideboundedness of undertrained
> system administrators, for it is vast.
These same administrators also underestimate (i) the number
of well connected home machines and (ii) the idea that on
his own machine, everyone is root.
Most of these blocks are "default allow", and your home IP
is not on that list and they don't have the smarts to figure
out that you're getting around their blocks :-) Add dynamic
IP and a dyndns hostname (and dyndns has a hundred or so 2nd
level domains to choose your 3rd level hostname from!) and
clueless admins don't stand a chance.
[sorry this is so badly off-topic...]
^ 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