* Re: [PATCH] gitk: Update swedish translation.
From: Peter Krefting @ 2008-08-04 18:27 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <237967ef0808031008t641dab2dqd4c74ef7124f6361@mail.gmail.com>
Mikael Magnusson:
> attached
Looks fine. You're too quick, I didn't see the call for translations before
your update was done. :-)
Are you on the Swedish translation mailing list (address in the PO file)? I
did submit my original translations of gitk/git-gui for review there, you
may want to join there for terminology discussions.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Peter Krefting @ 2008-08-04 18:22 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20080804145046.GC27666@spearce.org>
Shawn O. Pearce:
> So translation work is still here, on this mailing list.
The problem is then that it might drown in the noise. And of course the
problem with having to do all the boring tool-bashing yourself :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha
From: Shawn O. Pearce @ 2008-08-04 17:54 UTC (permalink / raw)
To: James Linder; +Cc: git
In-Reply-To: <5dfc0b810808040948x6cd1f29fhaf2bf85a09cfd404@mail.gmail.com>
James Linder <james.h.linder@gmail.com> wrote:
> This summer, New York University held a class called Open Source
> Programming. One of the projects to come out of the class is JavaGit,
> an API providing access to git repositories for Java applications.
> Today the JavaGit team has released version 0.1.0 Alpha of the JavaGit
> API. The announcement is listed below.
This is interesting work. Competition is good, but I think many
of us, especially those involved in egit and jgit, would wonder
why a new project was started instead of contributing to one that
already is established.
> JavaGit is engineered to provide the developer with access to the raw
> git commands through a command API as well as an object API designed
> to represent the .git repository, the working tree and other, familiar
> git concepts. JavaGit uses the git binaries installed on the host
> machine to provide git functionality and has been designed to easily
> accommodate additional methods of access to git repositories.
One of the primary drivers behind why jgit does not call out to C
Git is to remove the need to install Git binaries on the system.
Some of the Eclipse IDE distributions won't bundle a plugin that
depends upon GPL executables, and hence won't bundle an Eclipse
Git plugin like that.
Another is performance. Although jgit is written in Java it can
beat the performance of C Git for certain operations due to its
ability to avoid fork+exec. I've actually had a few times where
writing something in Java against jgit turned out to be easier
and faster than writing it in Perl/Python/Tcl/shell against the C
Git binary, because I was able to avoid the fork+exec overheads.
Although I suspect C Git would have performed a lot better if we
had proper library bindings into say Perl.
I would like to correct one statement in both the JavaGit and
gitclipse FAQ's:
>From http://gitclipse.sourceforge.net/docs/faq.php:
> How is this different from egit/jgit?
>
> Who/What?!
Seriously? egit and jgit is a 2.5 year old project that has a
Google Summer of Code student working on it this summer, and is
seeing 20+ patch clusters at least once a month on this list.
You cannot really claim we aren't visible in the Git community.
> No seriously, we have a lot of respect for the egit/jgit project
> they have done a lot of good work. There are several things that
> differentiate us.
>
> * egit/jgit are being developed together as one project
> whereas our API is developed seperately by a different team
> of developers. This allows our development team to focus our
> development efforts on our plug-in and not get hung up on
> API issues.
They are only in the same repository because they started out that
way for convience when it comes to committing. jgit is completely
seperate from egit and comes with a build process to compile a
stand-alone command line interface based entirely on jgit.
The _only_ reason they haven't been split into two different Git
repositories is because we just haven't wanted to slow down our
development for such a trivial administrative item.
If this really was something that was holding back the adoption
of and contribution to jgit, we'd split it tomorrow, and suffer
the pain of needing to segment development branches.
>From http://javagit.sourceforge.net/faq.php:
> How is JavaGit different from Jgit/Egit?
>
> Who/What?
>
> No. But seriously now. JavaGit was conceived of as a complementary
> project to the GitClipse projct, an Eclipse plugin to provide git
> support. It was a logical choice for us to split the project into
> the user oriented project, Gitclipse, and the developer oriented
> project, JavaGit. Since the projects are separate, the JavaGit
> project is free to concentrate on providing a top-notch library/API
> for use in other applications.
Oddly enough this is how jgit and egit came along. I wanted to
build an Eclipse plugin, but also wanted to make sure that the
majority of the implementation code was not tied to the Eclipse
platform APIs or to the UI so that we could reuse it on other
IDEs (e.g. NetBeans), or on build tools (Maven, Ant, ...), or
for a command line based tool (e.g. jgit's .pgm package).
> Jgit/Egit, on the other hand, appear to be tightly integrated with
> Jgit primarily supporting Egit.
That's not really true. jgit has two major users: egit and its
related jgit.pgm package (which offers a CLI). Its sad that there
are not yet more jgit users. But jgit itself has no dependency on
egit, and is not tightly integrated with it.
I could claim that gitclipse and javagit are tightly integrated
because they are both hosted on SVN on sourceforge.net. That's
about the same level of "tightly integrated" that jgit and egit are.
> Another difference between JavaGit and Jgit/Egit is that the JavaGit
> team wanted to quickly implement access to git repositories. This
> goal lead us to start by forking to git itself to provide git
> functionality. Knowing that this may be a short-term solution,
> we built JavaGit so that we can easily replace the command line
> interface (CLI) functionality with JNI, pure Java, or some other
> implementation in the future. Jgit/Egit only provides a pure Java
> implementation.
Maybe I'm missing something, but I think egit has more features
available in its UI, and all of those are implemented directly
by jgit. We even have a graphical history viewer with renderers
built in both AWT and SWT, and the SWT one is available in Eclipse.
So I'm not sure I follow this argument that JavaGit enabled the
team to produce an Eclipse plugin that offers more features, quicker.
--
Shawn.
^ permalink raw reply
* NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha
From: James Linder @ 2008-08-04 16:48 UTC (permalink / raw)
To: git
Hello Git Developers and Users,
This summer, New York University held a class called Open Source
Programming. One of the projects to come out of the class is JavaGit,
an API providing access to git repositories for Java applications.
Today the JavaGit team has released version 0.1.0 Alpha of the JavaGit
API. The announcement is listed below.
We are looking forward to continuing the project and grow the project
and welcome new volunteers. So if the project sounds interesting,
check it out and let us know what you think.
Regards,
The JavaGit Team
------------------------------------------------------------
JavaGit Releases Version 0.1.0 Alpha - August 4, 2008
The JavaGit team is pleased to announce the release of JavaGit version
0.1.0 alpha, an API providing access to git repositories from Java
programs. The goal of JavaGit is to bring the power of git to the Java
developer as an API that is intuitive for developers new to git and
developers who are veteran git users.
JavaGit is engineered to provide the developer with access to the raw
git commands through a command API as well as an object API designed
to represent the .git repository, the working tree and other, familiar
git concepts. JavaGit uses the git binaries installed on the host
machine to provide git functionality and has been designed to easily
accommodate additional methods of access to git repositories.
JavaGit is released as open source software under the GNU LGPL license.
For additional information on the JavaGit project, please visit:
http://www.javagit.com
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: J.H. @ 2008-08-04 16:26 UTC (permalink / raw)
To: Robert Richter; +Cc: git
In-Reply-To: <20080804101200.GC811@erda.amd.com>
Robert,
Noticed, but while I agree cloneurl is good - I think it kind of defeats
the purpose of what I was originally intending with the 'git' link.
I've gone back in to understand cloneurl better and I genuinely think
this is the wrong approach (or at least not what was originally intended
with the 'git' link as I envisioned it).
The git link was always meant / intended to be a link to acquire the git
repository directly, and be independent of what is actually present in
the cloneurl file, specifically I wanted it to be a (1) git url
(git://<hostname>/<path>) so that it took advantage of git specifically
vs. accidentally giving you something with ssh or http. and (2) was
uniform and did *not* depend on something in the repository as with
large set of repositories, kernel.org, there is no way we can police
this and we explicitly do not want to have a script that automatically
adds this or what not.
I have two other concerns with the patch your proposing
(1) it's on by default, and it seems that there are a number of sites
that don't actually want this functionality, making it a configurable
option would seem prudent in that case
(2) ignoring my comments on why I think using cloneurl for a large site
is bad (after I looked into it), blindly on taking the first option in
the file may lead to the display of unexpected or unintended URLs.
That said, it's probably worth merging the two patches (since I'm
already there with the configuration options, etc) that way people can
get either functionality should they choose.
- John 'Warthog9' Hawley
On Mon, 2008-08-04 at 12:12 +0200, Robert Richter wrote:
> On 03.08.08 13:53:13, J.H. wrote:
> > Working on refactoring the patch so that it can go upstream, one of the
> > things I'm definitely making an assumption about (in my original code)
> > is that the base url will be uniform for the entire project_list (as it
> > is on kernel.org). If that's acceptable I will probably be able to
> > submit something today, if not I will need to muck about and read out
> > the url from .git/cloneurl (which would be a rather hefty performance
> > hit - needing to read that from each repository)
>
> John,
>
> I just sent out a patch that implements this using cloneurl. It seemed
> small and easy to implement and so I just made the change myself.
>
> Thank you anyway.
>
> -Robert
>
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Rogan Dawes @ 2008-08-04 16:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, H. Peter Anvin
In-Reply-To: <20080804155956.GF27666@spearce.org>
Shawn O. Pearce wrote:
> Rogan Dawes <lists@dawes.za.net> wrote:
>> Shawn O. Pearce wrote:
>>> Currently git-http-backend requests no caching for info/refs [...]
>> Fair enough, but what about the quote from RFC2616 that I posted in
>> rebuttal to Dscho?
>>
>>> 13.10 Invalidation After Updates or Deletions
>>>
>>> ...
>>>
>>> Some HTTP methods MUST cause a cache to invalidate an entity. This is
>>> either the entity referred to by the Request-URI, or by the Location
>>> or Content-Location headers (if present). These methods are:
>>>
>>> - PUT
>>> - DELETE
>>> - POST
>> This doesn't seem negotiable to me.
>
> Its not negotiable. POST requires no caching. End of discussion.
Aha. So now I see the objective. I had misunderstood the intention to be
to *allow* caching of POST'ed resources.
>> For those resources that are expected to be cacheable, the request
>> should be made using a GET.
>
> That's exactly what we are doing. Where caching is reasonable we are
> using a GET request. Where caching cannot be performed as the server
> state is changing (e.g. actually updating refs) we are using POST.
> That is entirely within the guidelines of the RFC.
>
> However we are "abusing" POST for "POST /info/refs" to detect a
> Git-aware HTTP server. Sending POST to a static resource should
> always fail.
Right. Either with a "405 Method not supported", or a "404 Not found".
as I discovered.
>>> Because git-http-backend emulates a dumb server there is a command
>>> dispatch table based upon the URL submitted. Thus we already have
>>> the command dispatch behavior implemented in the URL and doing it
>>> in the POST body would only complicate the code further.
>> Not by a huge amount, surely?
>>
>> if (method == "GET") command = ...
>> else if (method == "POST") command = ...
>> dispatch(command);
>
> Well, true, we could do that. But then we have to break the
> command name out of the input stream. In some cases we may just be
> exec'ing another Git process and letting it handle the input stream.
> Shoving the command name into the start of it just makes it that
> much harder to parse out.
Fair enough. I had not thought about other uses for the input stream.
> One of the problems with these RPC-in-HTTP systems is always the
> fact that the true nature of the action isn't visible in the method
> and URL, causing servers and proxies to have to parse the stream to
> implement firewall rules. Or to provide access control. I'm trying
> to reuse as much of the access control support as possible from the
> HTTP server and put as little of it as possible into the backend CGI.
>
> Since the backend CGI is based upon git-receive-pack itself admins
> can use the standard pre-receive/update hook pair to manage branch
> level security in a repository, while gross-level read/write can
> be done in the server.
Works for me!
Thanks for doing all the hard thinking for this feature :-)
Rogan
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-08-04 16:06 UTC (permalink / raw)
To: Tarmigan
Cc: Steffen Prohaska, Avery Pennarun, Eyvind Bernhardsen,
Johannes Schindelin, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <905315640808031154j28778cd6pee75e6b008304941@mail.gmail.com>
On Sun, Aug 03, 2008 at 11:54:34AM -0700, Tarmigan wrote:
> On Sun, Aug 3, 2008 at 10:33 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:
> >>
> >> For all I care, git can consider the files as binary, but by *default*
> >> I should get back the same as I put in.
> >
> > Sorry, but Git is a source control system,
>
> I think this is the heart of the disagreement.
I guess so... Because for me it is very important that most of files I
store are text files. In fact, such operations as diff and merge would
not make much sense for binary files, would they? IOW, Git is a revision
control system, not a versioning file system.
> What I love about git
> is that git trusts me, the user, and it trusts my files.
Sure, git trusts you. You can always turn off some features if you don't
like them; but the issue having the right defaults. autocrlf=true is the
right default if you want to have CRLF in your work directory. And as
long as text heuristic is right (and it works pretty damn good), you get
exactly what you put in it. In very very rare cases where the heuristic
is wrong, it will warn you about that you are not going to have back what
you put. So, you can tell Git explicitly that you want this file stored
as binary. But this situation is very unlikely unless you store in it
something like svndump files, but storying such files in not the main
purpose of Git.
So, I don't think that this CRLF conversion is a real issue, except that
the fact that changing the global autocrlf value should not have changed
autocrlf in already existing repositories. Because autocrlf is not just
a preference, but also determines in what format your files in the working
directory are stored. So, I believe it should be corrected. But even in
this case, you do not really lose anything.
> It doesn't change the encoding of my filenames by default.
And not by default? Currently, does not support encoding filenames
from your local encoding to UTF-8. And that will be a problem at
some point if you store file names in non UTF-8 encoding. But it is
a separate issue connected to i18n support. I don't think it makes
sense to go into it right now as it is completely irrelevant to the
problem we discuss.
What is relevant is that Git *does* change filename representation.
For instance, if you try to add a file with a name 'foo\bar', Git
will actually add 'foo/bar'. You see, on check-in, Git converts the
directory separator from its Windows form ('\') to the format it uses
internally ('/').
So, it is logical to do the same text files, because text files are
sequences of lines separated by line-separator, which is CRLF on
Windows, but its internal representation in Git is LF.
> It doesn't do keyword expansion by default.
Because keyword expansion is almost always meaningless thing to do
in your working directory. It just makes things slower and you do
not win *anything*. Arguably, there are some cases when you may
want some expansion during export your sources to archive, but even
that is very uncommon.
> It doesn't change the case of filenames by default.
Change case? Would it not be a completely insane thing to do? People put
some meaning in what registry of letters when wrote names, why would you
want Git (or any source control system) to mess up with that?
> If git is not willing to change the encoding/case of file*names* by
> default, how is it acceptable to change the *content* of the files
> themselves?
It does not change the content, it changes the EOL marker from its
external to internal representation. It does the same thing as what C
library on Windows does when you read or write files in the text mode.
This should be completely transparent to users as long as autocrlf is
not changed.
Dmitry
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Shawn O. Pearce @ 2008-08-04 15:59 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Junio C Hamano, git, H. Peter Anvin
In-Reply-To: <48972437.5050008@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> wrote:
> Shawn O. Pearce wrote:
>> Currently git-http-backend requests no caching for info/refs [...]
>
> Fair enough, but what about the quote from RFC2616 that I posted in
> rebuttal to Dscho?
>
> > 13.10 Invalidation After Updates or Deletions
> >
> > ...
> >
> > Some HTTP methods MUST cause a cache to invalidate an entity. This is
> > either the entity referred to by the Request-URI, or by the Location
> > or Content-Location headers (if present). These methods are:
> >
> > - PUT
> > - DELETE
> > - POST
>
> This doesn't seem negotiable to me.
Its not negotiable. POST requires no caching. End of discussion.
> For those resources that are expected to be cacheable, the request
> should be made using a GET.
That's exactly what we are doing. Where caching is reasonable we are
using a GET request. Where caching cannot be performed as the server
state is changing (e.g. actually updating refs) we are using POST.
That is entirely within the guidelines of the RFC.
However we are "abusing" POST for "POST /info/refs" to detect a
Git-aware HTTP server. Sending POST to a static resource should
always fail.
>> Because git-http-backend emulates a dumb server there is a command
>> dispatch table based upon the URL submitted. Thus we already have
>> the command dispatch behavior implemented in the URL and doing it
>> in the POST body would only complicate the code further.
>
> Not by a huge amount, surely?
>
> if (method == "GET") command = ...
> else if (method == "POST") command = ...
> dispatch(command);
Well, true, we could do that. But then we have to break the
command name out of the input stream. In some cases we may just be
exec'ing another Git process and letting it handle the input stream.
Shoving the command name into the start of it just makes it that
much harder to parse out.
We already have to handle splitting PATH_TRANSLATED into a pair of
(GIT_DIR, command) so we can handle that for a GET. We might as
well just use that very same code for POST to select the command.
Besides, by placing the command name into the URL server admins can
use regex filters in their configurations to control access. If we
shove the command name into the body of a POST they cannot do this.
I can see sites wanting to offer anonymous smart fetch, but require
password protected smart push on the same repository URL. Slapping
a directive like:
<Location ~ ^/git/.*/receive-pack$>
require valid-user
...
</Location>
Would easily make Apache implement this for us. Most modern HTTP
servers should be able to be configured like this.
One of the problems with these RPC-in-HTTP systems is always the
fact that the true nature of the action isn't visible in the method
and URL, causing servers and proxies to have to parse the stream to
implement firewall rules. Or to provide access control. I'm trying
to reuse as much of the access control support as possible from the
HTTP server and put as little of it as possible into the backend CGI.
Since the backend CGI is based upon git-receive-pack itself admins
can use the standard pre-receive/update hook pair to manage branch
level security in a repository, while gross-level read/write can
be done in the server.
--
Shawn.
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Rogan Dawes @ 2008-08-04 15:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, H. Peter Anvin
In-Reply-To: <20080804144824.GB27666@spearce.org>
Shawn O. Pearce wrote:
> Rogan Dawes <lists@dawes.za.net> wrote:
>> Shawn O. Pearce wrote:
>>> Smart Server Detection
>>> ----------------------
>>>
>>> To detect a smart (Git-aware) server a client sends an
>>> empty POST request to info/refs; [...]
>>>
>>> C: POST /repository.git/info/refs HTTP/1.0
>>> C: Content-Length: 0
>> I don't understand why you would want to keep the commands in the URL
>> when you are doing a POST?
>
> Well, as Dscho pointed out this partly has to do with caching and
> the transparent dumb server functionality. By using the command in
> the URL, and having the command match that of the dumb server file,
> its easier to emulate a dumb server and also to permit caching.
>
> Currently git-http-backend requests no caching for info/refs, but
> I could see us tweaking that to permit several minutes of caching,
> especially on big public sites like kernel.org. Having info/refs
> report stale by 5 minutes is not an issue when writes to there
> already have a lag due to the master-slave mirroring system in use.
Fair enough, but what about the quote from RFC2616 that I posted in
rebuttal to Dscho?
> 13.10 Invalidation After Updates or Deletions
>
> ...
>
> Some HTTP methods MUST cause a cache to invalidate an entity. This is
> either the entity referred to by the Request-URI, or by the Location
> or Content-Location headers (if present). These methods are:
>
> - PUT
> - DELETE
> - POST
This doesn't seem negotiable to me.
For those resources that are expected to be cacheable, the request
should be made using a GET.
> Because git-http-backend emulates a dumb server there is a command
> dispatch table based upon the URL submitted. Thus we already have
> the command dispatch behavior implemented in the URL and doing it
> in the POST body would only complicate the code further.
Not by a huge amount, surely?
if (method == "GET") command = ...
else if (method == "POST") command = ...
dispatch(command);
Rogan
^ permalink raw reply
* Re: [PATCH] correct access right for git-svn-dcommit test
From: Brad King @ 2008-08-04 15:44 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Eric Wong, git
In-Reply-To: <20080804153024.GV7008@dpotapov.dyndns.org>
Dmitry Potapov wrote:
> The tests requires anonymous write access. Therefore, "anon-access =
> write" is added to conf/svnserve.conf. But because it was added to
> the end of the file, it is impossible to guarantee in what section
> it will be located. It turned out that on SVN 1.5, it was placed in
> the wrong section and as result the test failed.
>
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
> ---
> t/t9113-git-svn-dcommit-new-file.sh | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/t/t9113-git-svn-dcommit-new-file.sh b/t/t9113-git-svn-dcommit-new-file.sh
> index 8da8ce5..ae78e33 100755
> --- a/t/t9113-git-svn-dcommit-new-file.sh
> +++ b/t/t9113-git-svn-dcommit-new-file.sh
> @@ -28,6 +28,7 @@ start_svnserve () {
>
> test_expect_success 'start tracking an empty repo' '
> svn mkdir -m "empty dir" "$svnrepo"/empty-dir &&
> + echo "[general]" > "$rawsvnrepo"/conf/svnserve.conf &&
> echo anon-access = write >> "$rawsvnrepo"/conf/svnserve.conf &&
> start_svnserve &&
> git svn init svn://127.0.0.1:$SVNSERVE_PORT &&
I just tried this patch and it does fix the test on my system.
Thanks,
-Brad
^ permalink raw reply
* Re: [StGIT v2 PATCH] Do not mess-up with commit message formatting when sending email
From: Karl Hasselström @ 2008-08-04 15:57 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git, Catalin Marinas
In-Reply-To: <20080804151913.4269.74254.stgit@dawn.rfc1149.net>
Your round-trip time was shorter than mine by a few orders of
magnitude. ;-)
On 2008-08-04 17:19:14 +0200, Samuel Tardieu wrote:
> The long description gets its trailing blanks removed as well as any
> leading empty lines. Leading blanks are left untouched to preserve
> the formatting.
Thanks, much better. Will apply.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] correct access right for git-svn-dcommit test
From: Dmitry Potapov @ 2008-08-04 15:30 UTC (permalink / raw)
To: Eric Wong; +Cc: Brad King, git
In-Reply-To: <20080804151424.GU7008@dpotapov.dyndns.org>
The tests requires anonymous write access. Therefore, "anon-access =
write" is added to conf/svnserve.conf. But because it was added to
the end of the file, it is impossible to guarantee in what section
it will be located. It turned out that on SVN 1.5, it was placed in
the wrong section and as result the test failed.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
t/t9113-git-svn-dcommit-new-file.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t9113-git-svn-dcommit-new-file.sh b/t/t9113-git-svn-dcommit-new-file.sh
index 8da8ce5..ae78e33 100755
--- a/t/t9113-git-svn-dcommit-new-file.sh
+++ b/t/t9113-git-svn-dcommit-new-file.sh
@@ -28,6 +28,7 @@ start_svnserve () {
test_expect_success 'start tracking an empty repo' '
svn mkdir -m "empty dir" "$svnrepo"/empty-dir &&
+ echo "[general]" > "$rawsvnrepo"/conf/svnserve.conf &&
echo anon-access = write >> "$rawsvnrepo"/conf/svnserve.conf &&
start_svnserve &&
git svn init svn://127.0.0.1:$SVNSERVE_PORT &&
--
1.6.0.rc1.74.g1e94
^ permalink raw reply related
* Re: StGit and charsets
From: Jon Smirl @ 2008-08-04 15:21 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20080804153146.GF12232@diana.vm.bytemark.co.uk>
On 8/4/08, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-08-04 10:21:20 -0400, Jon Smirl wrote:
> > I don't work much with international charsets. If someone is using
> > something like Russian or Finish locally, is the metadata in the
> > patch converted to UTF8 before exporting or sending it as mail?
>
>
> I think what happens is that it's assumed to be utf8. No one has
> complained that their non-utf8 locale doesn't work, but my guess is
> that's because those people just haven't tried StGit yet.
This might be worth testing for Asian locales. If Asian locales make
it through ok everything else probably will too.
I don't know enough about Unicode to decode the mangled names, I
suspect they are still in the local charset and haven't been UTF8
converted. Of course the name mangling may be coming from other
tools. There is no way to tell.
This problem happens in other ways in the kernel. There is a file in
the DRM code where two people's names have been inserted in different
charsets. If I set my editor to display one right the other is always
wrong. checkpatch probably needs to make sure that patches are
completely valid UTF8.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [StGIT v2 PATCH] Do not mess-up with commit message formatting when sending email
From: Samuel Tardieu @ 2008-08-04 15:19 UTC (permalink / raw)
To: kha; +Cc: git, Catalin Marinas
In-Reply-To: <20080804141640.GB12232@diana.vm.bytemark.co.uk>
The short description, which will be used as the email subject,
gets its leading and trailing blanks removed.
The long description gets its trailing blanks removed as well
as any leading empty lines. Leading blanks are left untouched
to preserve the formatting.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
stgit/commands/mail.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index a833efc..61e3f3a 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -401,8 +401,8 @@ def __build_message(tmpl, patch, patch_nr, total_nr, msg_id, ref_id, options):
options.edit_patches = True
descr_lines = descr.split('\n')
- short_descr = descr_lines[0].rstrip()
- long_descr = '\n'.join(descr_lines[1:]).lstrip()
+ short_descr = descr_lines[0].strip()
+ long_descr = '\n'.join(l.rstrip() for l in descr_lines[1:]).lstrip('\n')
authname = p.get_authname();
authemail = p.get_authemail();
^ permalink raw reply related
* Re: [RFH] - git-svn auth bug (possibly SVN 1.5.0-related)
From: Dmitry Potapov @ 2008-08-04 15:14 UTC (permalink / raw)
To: Eric Wong; +Cc: Brad King, git
In-Reply-To: <20080804141820.GT7008@dpotapov.dyndns.org>
On Mon, Aug 04, 2008 at 06:18:20PM +0400, Dmitry Potapov wrote:
> Numbers of lines may be different for different versions of libsvn-perl,
> but the effect is exactly the same. Instead of going to the next line
> and completing AUTOLOAD, if you use FS format 3 then you end up in
> croak_on_error(), which uses some uninitialized value in string
> concatenation (which produces an additional warning) and then calls
> croak(). End of the story :(
I think I have figured out that is wrong. It is a bug in initialization
of SVN database. Before, there was only one [general] section in the
conf/svnserve.conf file and the procedure of initialization apparently
copied a template and added the following string to the end of file:
anon-access = write
but now there are two sections: [general] and [sasl]
as result "anon-access = write" is added to the wrong section,
and there is no anonymous access anymore. So, the test fails.
Dmitry
^ permalink raw reply
* Re: StGit and charsets
From: Karl Hasselström @ 2008-08-04 15:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910808040721n6c47908o9d8fabd8f16293c1@mail.gmail.com>
On 2008-08-04 10:21:20 -0400, Jon Smirl wrote:
> Do you have tests in place to handle the names and comments in
> patches being in different charsets?
There are some tests in t1800 and t1900 that use non-ascii names.
Might be others, but a quick grep didn't find them.
> I don't work much with international charsets. If someone is using
> something like Russian or Finish locally, is the metadata in the
> patch converted to UTF8 before exporting or sending it as mail?
I think what happens is that it's assumed to be utf8. No one has
complained that their non-utf8 locale doesn't work, but my guess is
that's because those people just haven't tried StGit yet.
> Comments should be in English, but people's names may need UTF8.
Mine does, for example. I started my StGit career by making sure it
could send out patches that didn't mangle my name. (That's a while
ago, though, so my memory's getting a bit rusty.)
> And what about email addresses, does DNS allow Unicode names now?
I think it's up to each TLD whether they want to allow it. See e.g.
http://en.wikipedia.org/wiki/Internationalized_domain_name
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [git/perl] unusual syntax?
From: David Christensen @ 2008-08-04 15:01 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0808032149p651309a8o773dca5f16923ee1@mail.gmail.com>
> sub _close_hash_and_insert_object {
> my ($self) = @_;
>
> return unless defined($self->{hash_object_pid});
>
> my @vars = map { 'hash_object_' . $_ } qw(pid in out ctx);
>
> command_close_bidi_pipe($self->{@vars});
> delete $self->{@vars};
> }
> $self->{@vars} evaluates to undef. i can't find any mention of using
> arrays to dereference objects in the manual and elsewhere; is this a
> mistake?
This is a hash slice notation, returning an array of hash values
matching the corresponding keys. 5.10 removed some syntax warts in
the case of hash slices; this is more portably expressed as @{$self}
{@vars}; this should work in 5.10 and earlier versions, and so is the
preferred syntax.
Regards,
David
--
David Christensen
End Point Corporation
david@endpoint.com
^ permalink raw reply
* Re: [PATCH] bash completion: Add completion for 'git grep'
From: Shawn O. Pearce @ 2008-08-04 14:53 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1217638593-57321-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> Added completions for all long options specified in the docs
> --cached
> --text --ignore-case --word-regexp --invert-match
> --full-name
> --extended-regexp --basic-regexp --fixed-strings
> --files-with-matches --name-only
> --files-without-match
> --count
> --and --or --not --all-match
>
> Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
This is the "first patch" which has the doubledash test. As you
pointed out, its better because it stops completion of long options
after the --.
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 30d8701..b28ac10 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -796,6 +796,29 @@ _git_gc ()
> COMPREPLY=()
> }
>
> +_git_grep ()
> +{
> + __git_has_doubledash && return
> +
> + local cur="${COMP_WORDS[COMP_CWORD]}"
> + case "$cur" in
> + --*)
> + __gitcomp "
> + --cached
> + --text --ignore-case --word-regexp --invert-match
> + --full-name
> + --extended-regexp --basic-regexp --fixed-strings
> + --files-with-matches --name-only
> + --files-without-match
> + --count
> + --and --or --not --all-match
> + "
> + return
> + ;;
> + esac
> + COMPREPLY=()
> +}
> +
> _git_help ()
> {
> local cur="${COMP_WORDS[COMP_CWORD]}"
> @@ -1486,6 +1509,7 @@ _git ()
> fetch) _git_fetch ;;
> format-patch) _git_format_patch ;;
> gc) _git_gc ;;
> + grep) _git_grep ;;
> help) _git_help ;;
> log) _git_log ;;
> ls-remote) _git_ls_remote ;;
> --
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash completion: Add completion for 'git grep'
From: Shawn O. Pearce @ 2008-08-04 14:52 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1217827608-5143-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> This updated patch removes the __git_has_doublehash line. However, I
> just noticed that d773c631 added __git_has_doublehash to prevent
> completions of long options after --. So, maybe it's not too
> redundant and my first patch might be better.
Heh. I forgot about that. You're right, your first patch is better.
--
Shawn.
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Steve Frécinaux @ 2008-08-04 14:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: sverre, cte, Dmitry Potapov, git
In-Reply-To: <20080731215818.GD24631@spearce.org>
On Thu, Jul 31, 2008 at 11:58 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Especially since that'd mean that integrating it into other languages
>> (by means of wrappers), such as Python or Ruby, becomes a lot easier.
>
> I'm going to be shot for saying this, but both Python and Ruby
> have implementations that run on the JVM. So does Git. Want
> to use Git and Python? Use JGit and Jython. :)
There is also the "stores" branch from pygit [1] that implements pack
and object reading natively in python. Anyway implementing more than
that (ie, packing and such things) natively is clearly harder and
takes more work for less efficiency than making bindings around a
libified git...
[1] http://code.istique.net/?p=pygit.git;a=shortlog;h=refs/heads/stores
Don't mind the 50X error, just refresh... broken server.
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Shawn O. Pearce @ 2008-08-04 14:50 UTC (permalink / raw)
To: Peter Krefting; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0808041215140.4744@ds9.cixit.se>
Peter Krefting <peter@softwolves.pp.se> wrote:
> Shawn O. Pearce:
>
> > > Perhaps you wanted to update git-gui.pot first before sending this request
> > > out?
>
> > Oh. Its updated now, but msgmerge on my system is busted and won't
> > update the po files themselves. *sigh*
>
> In that case I would recommend submitting the translation to
> translationsproject.org, which helps both you and us translators in
> handling all the uninteresting tool-bashing itself. Submit an updated
> POT file when strings are frozen, and download all the updated
> translations before releasing.
This has come up before on the mailing list. We talked about moving
to translationsproject.org but decided against it at that time as
the current pool of translators for Git felt the dictionary involved
was too technical (and too Git specific) for the run-of-the-mill
translators who work through translationsproject.org. At least some
knowledge of Git is required to get a good translation, and we cannot
except all translators to have that.
So translation work is still here, on this mailing list.
--
Shawn.
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Shawn O. Pearce @ 2008-08-04 14:48 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Junio C Hamano, git, H. Peter Anvin
In-Reply-To: <4896D19C.6040704@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> wrote:
> Shawn O. Pearce wrote:
>>
>> Smart Server Detection
>> ----------------------
>>
>> To detect a smart (Git-aware) server a client sends an
>> empty POST request to info/refs; [...]
>>
>> C: POST /repository.git/info/refs HTTP/1.0
>> C: Content-Length: 0
>
> I don't understand why you would want to keep the commands in the URL
> when you are doing a POST?
Well, as Dscho pointed out this partly has to do with caching and
the transparent dumb server functionality. By using the command in
the URL, and having the command match that of the dumb server file,
its easier to emulate a dumb server and also to permit caching.
Currently git-http-backend requests no caching for info/refs, but
I could see us tweaking that to permit several minutes of caching,
especially on big public sites like kernel.org. Having info/refs
report stale by 5 minutes is not an issue when writes to there
already have a lag due to the master-slave mirroring system in use.
Because git-http-backend emulates a dumb server there is a command
dispatch table based upon the URL submitted. Thus we already have
the command dispatch behavior implemented in the URL and doing it
in the POST body would only complicate the code further.
> Also, if everything is done via POST, you don't have to worry about a
> wget-cloned server appearing to be "smart", since no "smarts" will ever
> be returned in response to a GET request (and to the best of my
> knowledge, wget can't mirror using POST).
I think we fixed the wget-cloned server issue by requesting
that clients use POST /info/refs to identify a smart server.
A wget-cloned repository will fail on this, and the client can
fallback to GET /info/refs and assume it must use the object
walker to fetch (or WebDAV to push). A smart server would
respond to the POST /info/refs request correctly and the
client would know its smart.
--
Shawn.
^ permalink raw reply
* [PATCH] [TopGit] Make "tg help cmd" print cmd help
From: Russell Steicke @ 2008-08-04 14:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
"tg help" looked like it needed help, and stuff it needed to know
about was already in README.
Use awk to extract help information from the README file. Store
the help files in $(PREFIX)/share/topgit. "tg help foo" will cat
$(PREFIX)/share/topgit/tg-foo.txt.
This is instead of the previous patch. It fixes a bug where the
help for the last command (update) wasn't terminated properly.
Signed-off-by: Russell Steicke <russellsteicke@gmail.com>
---
.gitignore | 6 ++++++
Makefile | 11 +++++++++--
create-help.sh | 17 +++++++++++++++++
tg.sh | 16 ++++++++++++++--
4 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/.gitignore b/.gitignore
index 53ca141..6f0727f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,8 +1,14 @@
hooks/pre-commit
tg-create
+tg-create.txt
tg-delete
+tg-delete.txt
tg-info
+tg-info.txt
tg-patch
+tg-patch.txt
tg-summary
+tg-summary.txt
tg-update
+tg-update.txt
tg
diff --git a/Makefile b/Makefile
index 3913d66..501df5a 100644
--- a/Makefile
+++ b/Makefile
@@ -2,6 +2,7 @@
PREFIX = $(HOME)
bindir = $(PREFIX)/bin
cmddir = $(PREFIX)/libexec/topgit
+sharedir = $(PREFIX)/share/topgit
hooksdir = $(cmddir)/hooks
@@ -10,18 +11,22 @@ hooks_in = hooks/pre-commit.sh
commands_out = $(patsubst %.sh,%,$(commands_in))
hooks_out = $(patsubst %.sh,%,$(hooks_in))
+help_out = $(patsubst %.sh,%.txt,$(commands_in))
-all:: tg $(commands_out) $(hooks_out)
+all:: tg $(commands_out) $(hooks_out) $(help_out)
tg $(commands_out) $(hooks_out): % : %.sh
@echo "[SED] $@"
@sed -e 's#@cmddir@#$(cmddir)#g;' \
-e 's#@hooksdir@#$(hooksdir)#g' \
-e 's#@bindir@#$(bindir)#g' \
+ -e 's#@sharedir@#$(sharedir)#g' \
$@.sh >$@+ && \
chmod +x $@+ && \
mv $@+ $@
+$(help_out): README create-help.sh
+ ./create-help.sh `echo $@ | sed -e 's/tg-//' -e 's/\.txt//'`
install:: all
install tg "$(bindir)"
@@ -29,6 +34,8 @@ install:: all
install $(commands_out) "$(cmddir)"
install -d -m 755 "$(hooksdir)"
install $(hooks_out) "$(hooksdir)"
+ install -d -m 755 "$(sharedir)"
+ install $(help_out) "$(sharedir)"
clean::
- rm -f tg $(commands_out) $(hooks_out)
+ rm -f tg $(commands_out) $(hooks_out) $(help_out)
diff --git a/create-help.sh b/create-help.sh
new file mode 100755
index 0000000..502b6c3
--- /dev/null
+++ b/create-help.sh
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+# Create the tg-foo.txt files which contain help for the tg-foo command.
+
+if [ $# -ne 1 ] ; then
+ echo "Usage: $0 tgcommand" 1>&2
+ exit 1
+fi
+
+< README awk '
+ BEGIN { incommand = 0; }
+ /^tg '"$1"'$/ { incommand = 1; next; }
+ /^[a-zA-Z]/ { incommand = 0; next; }
+ /^~/ { next; } # Ignore the title underlines.
+ { if (incommand) { print $0; } }
+' > tg-"$1".txt
+
diff --git a/tg.sh b/tg.sh
index e7c42cd..03a392b 100644
--- a/tg.sh
+++ b/tg.sh
@@ -148,6 +148,19 @@ switch_to_base()
git symbolic-ref HEAD "$_base"
}
+# Show the help messages.
+do_help()
+{
+ if [ -z "$1" ] ; then
+ echo "TopGit v0.1 - A different patch queue manager"
+ echo "Usage: tg (create|delete|info|patch|summary|update|help) ..."
+ elif [ -f "@sharedir@/tg-$1.txt" ] ; then
+ cat "@sharedir@/tg-$1.txt"
+ else
+ echo "`basename $0`: no help for $1" 1>&2
+ fi
+}
+
## Initial setup
@@ -171,8 +184,7 @@ shift
case "$cmd" in
help)
- echo "TopGit v0.1 - A different patch queue manager"
- echo "Usage: tg (create|delete|info|patch|summary|update|help) ..."
+ do_help "$1"
exit 1;;
create|delete|info|patch|summary|update)
. "@cmddir@"/tg-$cmd;;
--
tg: (24367cc..) t/help (depends on: master)
--
Russell Steicke
-- Fortune says:
BOFH excuse #144:
Too few computrons available.
^ permalink raw reply related
* Re: [StGit PATCH] Add some tests of refreshing removed files
From: Karl Hasselström @ 2008-08-04 14:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: git, Catalin Marinas
In-Reply-To: <9e4733910808040707u2ef8992eha629ebca9c41730b@mail.gmail.com>
On 2008-08-04 10:07:45 -0400, Jon Smirl wrote:
> I just updated to current git and stg and retested. Tracking a
> remove is working now for me.
Well, that's good.
> Tools were about three months old before updating.
Might have been fixed by 8fe07fa4cef (Handle refresh of changed files
with non-ASCII names) or 466bfe50 (Fix "refresh" failure with moved
files (bug 11661)).
> Not sure what changed. But I definitely couldn't get stgit to do it
> and had to use git commands to generate the patch. I would remove
> the file, refresh and the patch was empty. stg status would show the
> file in D state. As soon as I touched something else and refreshed
> the rm would appear in the patch.
Well, that's exactly what my new test tests for. So at least i got it
right.
> Maybe there is more to the triggering sequence than a simple rm.
> I'll keep a watch out and see if I can figure out how I got into the
> state.
Thanks.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* StGit and charsets
From: Jon Smirl @ 2008-08-04 14:21 UTC (permalink / raw)
To: Git Mailing List, Karl Hasselström
Do you have tests in place to handle the names and comments in patches
being in different charsets? When I was working with the mailmap file
a large source of errors was from mangling names in alternate
charsets. I recall errors in Finnish, Japanese and Chinese names for
sure. I don't know which tools did the charset mangling.
I don't work much with international charsets. If someone is using
something like Russian or Finish locally, is the metadata in the patch
converted to UTF8 before exporting or sending it as mail? Comments
should be in English, but people's names may need UTF8. And what about
email addresses, does DNS allow Unicode names now?
--
Jon Smirl
jonsmirl@gmail.com
^ 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