* Re: Not going beyond symbolic links
From: Linus Torvalds @ 2008-08-05 2:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Petr Baudis, Shawn O. Pearce
In-Reply-To: <alpine.DEB.1.00.0808050356480.9611@pacific.mpi-cbg.de.mpi-cbg.de>
On Tue, 5 Aug 2008, Johannes Schindelin wrote:
>
> I vividly remember being quite pissed by Git replacing a symbolic link in
> my working directory with a directory, and instead of updating the files
> which were technically outside of the repository, Git populated that newly
> created directory.
Well, that can cut both ways. For example, I vividly remember a time in
the distant past when harddisks were tiny, and I didn't have insanely
high-end hardware, and I was building the X server, but had to split
things up over two partitions because each individual partition was
too full.
IOW, sometimes you may _want_ to use symlinks that way, even within one
project - with a symlink allowing you to move parts of it around
"transparently".
Of course, these days under Linux we can just use bind mounts, so the use
of symlinks to stitch together two or more different trees is fairly
old-fashioned, but is still the only option on some systems or if you
don't have root.
(These days harddisks are also generally so big that it never happens. But
on my EeePC laptop, I still end up with two filesystems, 4GB and 8GB
each. So it's not inconceivable to be in that kind of situation even
today).
Linus
^ permalink raw reply
* [JGIT PATCH 1/1] Remove dead cacheTree related code from GitProjectData
From: Shawn O. Pearce @ 2008-08-05 2:22 UTC (permalink / raw)
To: Robin Rosenberg, Marek Zawirski; +Cc: git
We have long since purged the idea of the cache tree from egit, so we
do not need this commented out block of code anymore.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/egit/core/project/GitProjectData.java | 35 --------------------
1 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/project/GitProjectData.java b/org.spearce.egit.core/src/org/spearce/egit/core/project/GitProjectData.java
index f092669..8754bd1 100644
--- a/org.spearce.egit.core/src/org/spearce/egit/core/project/GitProjectData.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/project/GitProjectData.java
@@ -415,31 +415,6 @@ public class GitProjectData {
} else if (s == null) {
return true;
}
-
-// final Tree cacheTree = m.getCacheTree();
-// if (cacheTree != null) {
-// try {
-// synchronized (cacheTree) {
-// final TreeEntry e;
-// if (res.getType() == IResource.FILE)
-// e = cacheTree.findBlobMember(s);
-// else
-// e = cacheTree.findTreeMember(s);
-// if (e instanceof FileTreeEntry) {
-// trace("modified " + r + " -> "
-// + e.getFullName());
-// e.setModified();
-// affectedMappings.add(m);
-// }
-// }
-// } catch (IOException ioe) {
-// throw Activator
-// .error(
-// CoreText.GitProjectData_lazyResolveFailed,
-// ioe);
-// }
-// return true;
-// }
}
return false;
}
@@ -451,16 +426,6 @@ public class GitProjectData {
detachFromWorkspace();
Activator.logError(CoreText.GitProjectData_notifyChangedFailed, ce);
}
-
-// try {
-// final Iterator i = affectedMappings.iterator();
-// while (i.hasNext()) {
-// ((RepositoryMapping) i.next()).recomputeMerge();
-// }
-// } catch (IOException ioe) {
-// Activator
-// .logError(CoreText.GitProjectData_notifyChangedFailed, ioe);
-// }
}
private File propertyFile() {
--
1.6.0.rc1.250.g9b5e2
^ permalink raw reply related
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: H. Peter Anvin @ 2008-08-05 2:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Rogan Dawes, Junio C Hamano, git
In-Reply-To: <20080805015717.GB383@spearce.org>
Shawn O. Pearce wrote:
>
> I guess we need to ask client implementations to honor a redirect
> on the first request and reuse that new base URL for all subsequent
> requests that are part of the same "operation". Then server farms
> can issue a redirect to a server-specific hostname if a client
> comes in with a round-robin DNS hostname, thus ensuring that for
> this current operation there isn't skew.
>
Either that, or you can pass a "chase URL" in the payload of the
request... it's more or less the same concept.
-hpa
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Shawn O. Pearce @ 2008-08-05 1:57 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Rogan Dawes, Junio C Hamano, git
In-Reply-To: <4897AE53.4030107@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> wrote:
> Shawn O. Pearce wrote:
>>
>> I think it is a really good idea. Then clients don't have to worry
>> about which HTTP URL is the "correct" one for them to be using.
>
> Not arguing that URL compatibility isn't a good thing, but there are
> other ways to accomplish it, too. After detecting either a smart or
> dumb server, we can use a redirect to point them to a different URL, as
> appropriate.
I'm not sure this is necessary.
Of course it all comes down to "how does an admin map Git repositories
into the URL space of the server"?
I thought it would be simple if the admin was able to map
repositories using a ScriptAlias and allow the server to perform
path info translation to give us the filesystem location of the
repository. Then we don't have to configure our own map of the
available Git repositories.
Once you do that though you now have the URL space associated with
that repository served by a CGI. For older clients we need to
either serve them the file, or issue a redirect to serve the file.
The redirect is messy because we need some configuration to explain
where the files are available in the server's URL space.
Or you go the other way, and have newer git+http clients try to
find the git aware server by a redirect. Again we have to explain
where that git aware server is in the URL space of the server.
*sigh*
> Furthermore, in the case of round-robin sites like kernel.org, this is
> actually *mandatory* in the case of a stateful server (we need a
> redirect to a server-specific URL), and highly recommended in the case
> of a stateless server (because of potential skew.)
Well, the git+http protocol will hold all state in the client, making
each RPC a stateless RPC operation. The only issue is then dealing with
skew in a server farm.
I guess we need to ask client implementations to honor a redirect
on the first request and reuse that new base URL for all subsequent
requests that are part of the same "operation". Then server farms
can issue a redirect to a server-specific hostname if a client
comes in with a round-robin DNS hostname, thus ensuring that for
this current operation there isn't skew.
--
Shawn.
^ permalink raw reply
* Re: Not going beyond symbolic links
From: Johannes Schindelin @ 2008-08-05 1:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, Petr Baudis, Shawn O. Pearce
In-Reply-To: <alpine.LFD.1.10.0808041839130.3299@nehalem.linux-foundation.org>
Hi,
On Mon, 4 Aug 2008, Linus Torvalds wrote:
> On Mon, 4 Aug 2008, Junio C Hamano wrote:
> > >
> > > The rewritten 'has_symlink_leading_path()' should do ok, but it
> > > migth still be a huge performance downside to check all the paths
> > > for things like "git add -u".
> >
> > Not yet.
> >
> > I think this is a necessary "correctness" thing to do regardless of
> > the performance impact, and adding the logic to stop at submodule
> > boundary (aka gitlinks) should come before optimization.
>
> Well, "performance" is a feature too, and it's not correct to say that
> "X should be fixed before optimization". If "X" slows things down, the
> question should be whether it really needs fixing..
>
> Yes, we find symlinks when we do _new_ files, but is it really so bad to
> assume that existing directories that we have already added to the index
> are stable? It can easily be seen as a feature too that you can force git
> to ignore the symlink and see it as a real directory.
Actually, whatever you want, it needs fixing.
I vividly remember being quite pissed by Git replacing a symbolic link in
my working directory with a directory, and instead of updating the files
which were technically outside of the repository, Git populated that newly
created directory.
However, please note that Junio's patch affects git-add, AFAIR, not
git-update-index.
Ciao,
Dscho
^ permalink raw reply
* Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha
From: Shawn O. Pearce @ 2008-08-05 1:46 UTC (permalink / raw)
To: Pieter de Bie
Cc: Petr Baudis, Johannes Schindelin, James Linder, Git Mailinglist,
Junio C Hamano
In-Reply-To: <59095A70-09C1-4898-976F-18C0C157B7EF@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> wrote:
> On 5 aug 2008, at 03:20, Shawn O. Pearce wrote:
>
>> Someone recently ported git-blame into JGit, and it looks like they
>> did a good job, but it was a straight C->Java port. Since JGit
>> is licensed under the BSD and builtin-blame.c is under the GPL we
>> couldn't accept it as-is. That side project produced a lot more
>> results than anything else of late, but the GPL virual clause kicked
>> in and prevented direct inclusion.
>
> Have you asked the author of git-blame (Junio?) if he'd be willing to
> relicence it to the JGit licences?
We started talking about it off-list actually. I haven't heard
back from Junio yet but I think he was hinting that he is open to
the idea.
--
Shawn.
^ permalink raw reply
* Re: Not going beyond symbolic links
From: Linus Torvalds @ 2008-08-05 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <7v8wvc2seh.fsf@gitster.siamese.dyndns.org>
On Mon, 4 Aug 2008, Junio C Hamano wrote:
> >
> > The rewritten 'has_symlink_leading_path()' should do ok, but it migth
> > still be a huge performance downside to check all the paths for things
> > like "git add -u".
>
> Not yet.
>
> I think this is a necessary "correctness" thing to do regardless of the
> performance impact, and adding the logic to stop at submodule boundary
> (aka gitlinks) should come before optimization.
Well, "performance" is a feature too, and it's not correct to say that "X
should be fixed before optimization". If "X" slows things down, the
question should be whether it really needs fixing..
Yes, we find symlinks when we do _new_ files, but is it really so bad to
assume that existing directories that we have already added to the index
are stable? It can easily be seen as a feature too that you can force git
to ignore the symlink and see it as a real directory.
So that's why it would be interesting to hear about the performance
impact. Because this is definitely not a black-and-white "one behavior is
wrong and one behavior is right".
Linus
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: H. Peter Anvin @ 2008-08-05 1:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Rogan Dawes, Junio C Hamano, git
In-Reply-To: <20080805012459.GC32543@spearce.org>
Shawn O. Pearce wrote:
>
>> I'm not sure if "emulating a dumb server" is desirable at all; it seems
>> like it would at least in part defeat the purpose of minimizing the
>> transaction count and otherwise be as much of a "smart" server as the
>> medium permits.
>
> I think it is a really good idea. Then clients don't have to worry
> about which HTTP URL is the "correct" one for them to be using.
> End users will just magically get the smart git+http variant if
> both sides support it and they need to use HTTP due to firewalls.
> Clients will fall back onto the dumb protocol if the server doesn't
> support smart clones. Older clients (pre git+http) will still be
> able to talk to a smart server, just slower. This is nice for the
> end user. No thinking is required.
>
> Never ask a human to do what a machine can do in less time.
>
> I think its just 1 extra HTTP hit per fetch/push done against
> a dumb server. On a smart server that first hit will also give
> us what we need to begin the conversation (the info/refs data).
> On a dumb server its a wasted hit, but a dumb server is already
> doing to suck. One extra HTTP request against a dumb server is a
> drop in the bucket. Its also a pretty small request (an empty POST).
>
Not arguing that URL compatibility isn't a good thing, but there are
other ways to accomplish it, too. After detecting either a smart or
dumb server, we can use a redirect to point them to a different URL, as
appropriate.
Furthermore, in the case of round-robin sites like kernel.org, this is
actually *mandatory* in the case of a stateful server (we need a
redirect to a server-specific URL), and highly recommended in the case
of a stateless server (because of potential skew.)
-hpa
^ permalink raw reply
* Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha
From: Pieter de Bie @ 2008-08-05 1:32 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Johannes Schindelin, James Linder, Git Mailinglist,
Junio C Hamano
In-Reply-To: <20080805012007.GB32543@spearce.org>
On 5 aug 2008, at 03:20, Shawn O. Pearce wrote:
> Someone recently ported git-blame into JGit, and it looks like they
> did a good job, but it was a straight C->Java port. Since JGit
> is licensed under the BSD and builtin-blame.c is under the GPL we
> couldn't accept it as-is. That side project produced a lot more
> results than anything else of late, but the GPL virual clause kicked
> in and prevented direct inclusion.
Have you asked the author of git-blame (Junio?) if he'd be willing to
relicence it to the JGit licences?
- Pieter
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Shawn O. Pearce @ 2008-08-05 1:24 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Rogan Dawes, Junio C Hamano, git
In-Reply-To: <4897A6E4.3070508@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> wrote:
> Shawn O. Pearce wrote:
>>
>> Currently git-http-backend requests no caching for info/refs [...]
>
> Let's put it this way: we're not seeing a huge amount of load from git
> protocol requests, and I'm going to assume "git+http" protocol to be
> used only by sites behind braindamaged firewalls (everyone else would
> use git protocol), so I'm not really all that worried about it.
Agreed. There's another application I want git+http for, but that
may never materialize. Or maybe it will someday. I just have to
adopt a wait and see approach there.
> I'm not sure if "emulating a dumb server" is desirable at all; it seems
> like it would at least in part defeat the purpose of minimizing the
> transaction count and otherwise be as much of a "smart" server as the
> medium permits.
I think it is a really good idea. Then clients don't have to worry
about which HTTP URL is the "correct" one for them to be using.
End users will just magically get the smart git+http variant if
both sides support it and they need to use HTTP due to firewalls.
Clients will fall back onto the dumb protocol if the server doesn't
support smart clones. Older clients (pre git+http) will still be
able to talk to a smart server, just slower. This is nice for the
end user. No thinking is required.
Never ask a human to do what a machine can do in less time.
I think its just 1 extra HTTP hit per fetch/push done against
a dumb server. On a smart server that first hit will also give
us what we need to begin the conversation (the info/refs data).
On a dumb server its a wasted hit, but a dumb server is already
doing to suck. One extra HTTP request against a dumb server is a
drop in the bucket. Its also a pretty small request (an empty POST).
--
Shawn.
^ permalink raw reply
* Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha
From: Shawn O. Pearce @ 2008-08-05 1:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, James Linder, git
In-Reply-To: <20080805011051.GC32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Aug 05, 2008 at 01:36:15AM +0200, Johannes Schindelin wrote:
> > And I absolutely share the puzzlement of Shawn why anybody would try to do
> > their own thing in Java, instead of contributing to jgit.
> >
> > Especially the fact that "JavaGit" seems to repeat the all-to-obvious
> > error of Eclipse: to make a platform-independent library that depends on
> > platform dependent components.
>
> [Totally naive question coming with no knowledge of actual size of
> current JGit's feature set:]
>
> Wouldn't it make sense to have an ability to fall back on Git calls for
> functionality that is not implemented natively yet? If you then don't
> have Git available, you just don't get the functionality. What's the
> catch?
Someone else asked to do this in JGit before (it was privately
off-list to Robin and myself). Both of our responses were that we
were not that interested in having such dependencies in the main
JGit tree at this time, but that JGit is BSD and nothing would stop
them from forking our tree and trying it out. If there really was
value there we would have to consider merging it back.
Nothing came of it as far as I know.
Someone recently ported git-blame into JGit, and it looks like they
did a good job, but it was a straight C->Java port. Since JGit
is licensed under the BSD and builtin-blame.c is under the GPL we
couldn't accept it as-is. That side project produced a lot more
results than anything else of late, but the GPL virual clause kicked
in and prevented direct inclusion.
--
Shawn.
^ permalink raw reply
* Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha
From: Petr Baudis @ 2008-08-05 1:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, James Linder, git
In-Reply-To: <alpine.DEB.1.00.0808050127510.9611@pacific.mpi-cbg.de.mpi-cbg.de>
On Tue, Aug 05, 2008 at 01:36:15AM +0200, Johannes Schindelin wrote:
> And I absolutely share the puzzlement of Shawn why anybody would try to do
> their own thing in Java, instead of contributing to jgit.
>
> Especially the fact that "JavaGit" seems to repeat the all-to-obvious
> error of Eclipse: to make a platform-independent library that depends on
> platform dependent components.
[Totally naive question coming with no knowledge of actual size of
current JGit's feature set:]
Wouldn't it make sense to have an ability to fall back on Git calls for
functionality that is not implemented natively yet? If you then don't
have Git available, you just don't get the functionality. What's the
catch?
It seems to me that JavaGit's goal is "features, quick!" where JGit's
goal is "functionality, thoroughly". Both goals seem legitimate to me,
but I'm also not sure why didn't JavaGit just extend JGit's missing bits
with native Git calls and instead opted for reimplementation from the
ground up.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: H. Peter Anvin @ 2008-08-05 1:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Rogan Dawes, Junio C Hamano, git
In-Reply-To: <20080804144824.GB27666@spearce.org>
Shawn O. Pearce wrote:
>
> 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.
>
Let's put it this way: we're not seeing a huge amount of load from git
protocol requests, and I'm going to assume "git+http" protocol to be
used only by sites behind braindamaged firewalls (everyone else would
use git protocol), so I'm not really all that worried about it.
I'm not sure if "emulating a dumb server" is desirable at all; it seems
like it would at least in part defeat the purpose of minimizing the
transaction count and otherwise be as much of a "smart" server as the
medium permits.
-hpa
^ permalink raw reply
* Re: Not going beyond symbolic links
From: Junio C Hamano @ 2008-08-05 0:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Petr Baudis, Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <alpine.LFD.1.10.0808041719380.3299@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 4 Aug 2008, Junio C Hamano wrote:
>>
>> I started to revisit this issue and patched "git update-index --add"
>> and "git add" so far. Patches follow.
>
> Patches look good to me, but did you check the performance impact?
>
> The rewritten 'has_symlink_leading_path()' should do ok, but it migth
> still be a huge performance downside to check all the paths for things
> like "git add -u".
Not yet.
I think this is a necessary "correctness" thing to do regardless of the
performance impact, and adding the logic to stop at submodule boundary
(aka gitlinks) should come before optimization.
^ permalink raw reply
* Re: Not going beyond symbolic links
From: Linus Torvalds @ 2008-08-05 0:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <7vej5543v5.fsf_-_@gitster.siamese.dyndns.org>
On Mon, 4 Aug 2008, Junio C Hamano wrote:
>
> I started to revisit this issue and patched "git update-index --add"
> and "git add" so far. Patches follow.
Patches look good to me, but did you check the performance impact?
The rewritten 'has_symlink_leading_path()' should do ok, but it migth
still be a huge performance downside to check all the paths for things
like "git add -u".
I didn't test, though.
Linus
^ permalink raw reply
* Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha
From: A Large Angry SCM @ 2008-08-05 0:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, James Linder, git
In-Reply-To: <alpine.DEB.1.00.0808050127510.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 4 Aug 2008, Shawn O. Pearce wrote:
>
>> James Linder <james.h.linder@gmail.com> wrote:
>>
>>> Jgit/Egit, on the other hand, appear to be tightly integrated with
>>> Jgit primarily supporting Egit.
>> That's not really true.
>
> I started using jgit in a project that is not yet totally public. It is
> awesome. (I mean jgit is awesome, even if my project does make me happy,
> too.)
>
> And I absolutely share the puzzlement of Shawn why anybody would try to do
> their own thing in Java, instead of contributing to jgit.
>
> Especially the fact that "JavaGit" seems to repeat the all-to-obvious
> error of Eclipse: to make a platform-independent library that depends on
> platform dependent components.
>
> I find that kind of thinking so strange, to the point that I am really
> amazed enough to want to analyze the brain of the people inventing such
> things.
>
> But hey, maybe there is a deeper point in it that escapes me.
You mean like "Why is a project with the goal of bringing the power of
git to Java developers hosted in svn instead of git"?
^ permalink raw reply
* Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha
From: Johannes Schindelin @ 2008-08-04 23:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: James Linder, git
In-Reply-To: <20080804175403.GG27666@spearce.org>
Hi,
On Mon, 4 Aug 2008, Shawn O. Pearce wrote:
> James Linder <james.h.linder@gmail.com> wrote:
>
> > Jgit/Egit, on the other hand, appear to be tightly integrated with
> > Jgit primarily supporting Egit.
>
> That's not really true.
I started using jgit in a project that is not yet totally public. It is
awesome. (I mean jgit is awesome, even if my project does make me happy,
too.)
And I absolutely share the puzzlement of Shawn why anybody would try to do
their own thing in Java, instead of contributing to jgit.
Especially the fact that "JavaGit" seems to repeat the all-to-obvious
error of Eclipse: to make a platform-independent library that depends on
platform dependent components.
I find that kind of thinking so strange, to the point that I am really
amazed enough to want to analyze the brain of the people inventing such
things.
But hey, maybe there is a deeper point in it that escapes me.
Ciao,
Dscho
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Petr Baudis @ 2008-08-04 20:10 UTC (permalink / raw)
To: J.H.; +Cc: Robert Richter, git
In-Reply-To: <1217867214.32240.61.camel@localhost.localdomain>
Hi,
On Mon, Aug 04, 2008 at 09:26:54AM -0700, J.H. wrote:
> 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.
we could grep the cloneurl.
The thing is, some sites like repo.or.cz don't use per-project
cloneurl but do specify pull URLs by @git_base_url_list and this is
introducing unnecessary redundancy.
> 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.
Then why do you allow cloneurl in the repositories at all, if you
think the links won't be trustworthy? What is the fundamental difference
between what you show on the project list page and the URLs in the
project summary page?
> 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
I actually plan to remove the 'log' link from the project list; I
really wonder about the practicality of the 'git' link... but if there
were any widely used browser integrations (like firing up git-gui when
clicking on a git:// link), I *would* definitely see it more useful than
the 'log' link and add it to repo.or.cz. But I have never heard about
anyone actually doing this (but I think it might make a lot of sense;
thinking about it, I might try to patch msysgit to do this on Windows,
this would be nifty for my current dayjob project :).
> 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.
Configuration options are expensive on human users. Please let's not
add more too carelessly.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* [PATCH v2] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Johannes Sixt @ 2008-08-04 20:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <20080804200049.GA29485@spearce.org>
The new execdir has is two levels below the root directory, while
the old execdir 'bin' was only one level below. This commit
adapts the discovery of oguilib that uses relative paths
accordingly. We determine whether we have the extra level in the same
way in which the Makefile defines sharedir, i.e. whether the last
directory part is 'git-core'.
Inspired-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Zitat von "Shawn O. Pearce" <spearce@spearce.org>:
> Johannes Sixt <johannes.sixt@telecom.at> wrote:
> > + if {[lindex [file split $oguilib] end] eq {git-core}} {
>
> Isn't that what [file tail] does?
Yes, it is. I missed it in the myriad of file's options. Here's the updated
version of the patch.
-- Hannes
| 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
--git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index fd3875a..60f376d 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -52,7 +52,11 @@ catch {rename send {}} ; # What an evil concept...
set oguilib {@@GITGUI_LIBDIR@@}
set oguirel {@@GITGUI_RELATIVE@@}
if {$oguirel eq {1}} {
- set oguilib [file dirname [file dirname [file normalize $argv0]]]
+ set oguilib [file dirname [file normalize $argv0]]
+ if {[file tail $oguilib] eq {git-core}} {
+ set oguilib [file dirname $oguilib]
+ }
+ set oguilib [file dirname $oguilib]
set oguilib [file join $oguilib share git-gui lib]
set oguimsg [file join $oguilib msgs]
} elseif {[string match @@* $oguirel]} {
--
1.6.0.rc1.958.gb3893
^ permalink raw reply related
* Re: [PATCH] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Shawn O. Pearce @ 2008-08-04 20:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <1217879912.48975f6809e10@webmail.nextra.at>
Johannes Sixt <johannes.sixt@telecom.at> wrote:
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index fd3875a..fa08d49 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -52,7 +52,11 @@ catch {rename send {}} ; # What an evil concept...
> set oguilib {@@GITGUI_LIBDIR@@}
> set oguirel {@@GITGUI_RELATIVE@@}
> if {$oguirel eq {1}} {
> - set oguilib [file dirname [file dirname [file normalize $argv0]]]
> + set oguilib [file dirname [file normalize $argv0]]
> + if {[lindex [file split $oguilib] end] eq {git-core}} {
> + set oguilib [file dirname $oguilib]
Isn't that what [file tail] does?
if {[file tail $oguilib] eq {git-core}} {
But otherwise this looks good to me. I'll apply it later tonight,
unless you agree that file tail is better here.
--
Shawn.
^ permalink raw reply
* [PATCH] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Johannes Sixt @ 2008-08-04 19:58 UTC (permalink / raw)
To: Steffen Prohaska, Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <58FBF585-377C-40A7-818E-6B47F8FD2EB8@zib.de>
The new execdir has is two levels below the root directory, while
the old execdir 'bin' was only one level below. This commit
adapts the discovery of oguilib that uses relative paths
accordingly. We determine whether we have the extra level in the same
way in which the Makefile defines sharedir, i.e. whether the last
directory part is 'git-core'.
Inspired-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Zitat von Steffen Prohaska <prohaska@zib.de>:
>
> On Aug 3, 2008, at 11:35 AM, Johannes Sixt wrote:
> > I run git-gui effectivly with
> >
> > wish $prefix/libexec/git-core/git-gui
> >
> > (and I have $PATH set up to contain $bindir, but not $gitexecdir),
> > and this
> > needs the original hunk with the three [file dirname ... ], because
> > $argv0
> > points to $prefix/libexec/git-core/git-gui.
>
> The original hunk fixes the discovery of oguilib, i.e.
> from $prefix/libexec/git-core/git-gui to $prefix/share/git-gui/lib
>
> I didn't recognize that the the 'three [file dinames ...]' have
> not been applied because I had this change already in 4msysgit
> (and still have). Apologies for not checking this more carefully.
>
>
> > I thought I understood what's going on, but I don't anymore.
> >
> > Mybe the relative discovery of oguilib must be conditional on the
> > "git-core"
> > part as well, just like you discover sharedir?
>
> Hmm... you are right. If we want to maintain compatibility
> with *both* directory layouts, obviously all computations
> that depend on the layout need to be conditional on it.
Here is a patch that does just this.
-- Hannes
| 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
--git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index fd3875a..fa08d49 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -52,7 +52,11 @@ catch {rename send {}} ; # What an evil concept...
set oguilib {@@GITGUI_LIBDIR@@}
set oguirel {@@GITGUI_RELATIVE@@}
if {$oguirel eq {1}} {
- set oguilib [file dirname [file dirname [file normalize $argv0]]]
+ set oguilib [file dirname [file normalize $argv0]]
+ if {[lindex [file split $oguilib] end] eq {git-core}} {
+ set oguilib [file dirname $oguilib]
+ }
+ set oguilib [file dirname $oguilib]
set oguilib [file join $oguilib share git-gui lib]
set oguimsg [file join $oguilib msgs]
} elseif {[string match @@* $oguirel]} {
--
1.6.0.rc1.958.gce1ed
^ permalink raw reply related
* Re: email address handling
From: Karl Hasselström @ 2008-08-04 20:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Theodore Tso, Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.10.0808011543500.6819@nehalem.linux-foundation.org>
On 2008-08-01 15:49:43 -0700, Linus Torvalds wrote:
> Try to guess what something like
>
> =?ISO-8859-15?Q?Linus_T=F6rnqvist?= <torvalds@linux-foundation.org>
>
> is supposed to be.
Very readable to me. Because every so often some piece of software
reminds me that the ö in my name is 0xf6 in latin1/9 ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] gitk: Update swedish translation.
From: Mikael Magnusson @ 2008-08-04 19:13 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0808042024360.14216@perkele.intern.softwolves.pp.se>
2008/8/4 Peter Krefting <peter@softwolves.pp.se>:
> Mikael Magnusson:
>
>> attached
>
> Looks fine. You're too quick, I didn't see the call for translations before
> your update was done. :-)
I cheated a bit and did the gitk translation at the same time as the git-gui
translation :).
> 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.
I'm not, and if there was something that I was really unsure about, I'd
probably just leave it for you :).
--
Mikael Magnusson
PS Har du ändrat efternamn? Det står Karlsson i sv.po men Krefting i eposten.
Inte för att det är viktigt, är bara nyfiken :). DS
^ permalink raw reply
* Re: German translation of git man pages
From: Stephan Beyer @ 2008-08-04 18:43 UTC (permalink / raw)
To: Fabio Scotoni; +Cc: git
In-Reply-To: <alpine.LNX.1.10.0808031924490.13351@hydra.esse.ch>
Hi,
Fabio Scotoni wrote:
> Hello,
>
> I ran into another problem: Should i write something like "translated by
> Fabio Scotoni <fabio@esse.ch>" in the Author-Part of the man pages, or
> just translate it without any note (It wouldn't be a problem for me)?
I do not see a reason why this could be forbidden ;-)
I think this is your decision.
If you write "translated by ...", people see that you are the original
author and then it could happen that you get patches for that.
If translated manual pages get included into git (I really don't know),
then it may be useful if you write "translated by Fabio Scotoni
<fabio@esse.ch> and the Git list <git@vger.kernel.org>"
(or "... and the git-list <git@vger.kernel.org>", as it can be found
for the authorship in the Documentation/ files.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* 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
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