* Re: TortoiseGit
From: Junio C Hamano @ 2008-12-15 1:29 UTC (permalink / raw)
To: Li Frank; +Cc: Tim Visher, git
In-Reply-To: <1976ea660812141712w196540caue9525ddbae8192f3@mail.gmail.com>
"Li Frank" <lznuaa@gmail.com> writes:
> What's better github compared with repos.or.cz.
People just wanted to have it on some publicly accessible site.
repo.or.cz should be just fine, I think.
^ permalink raw reply
* Re: Possibly-spurious 'not uptodate. Cannot merge'
From: Junio C Hamano @ 2008-12-15 1:27 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <gi4adq$cr1$1@ger.gmane.org>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> On 2008-12-14, Nix <nix@esperi.org.uk> wrote:
>> In this situation, 'git diff' reports no changes at all, but 'git reset
>> --hard' gets the tree back into a state where merging succeeds, as does
>> 'git update-index --refresh'.
>
> Wasn't there some situation in which merely running 'git
> status' would have a similar effect? I seem to recall
> reading that somewhere but now I can't find any mention of
> it in 'git help status'.
It would, but this is a pure bug in the re-implementation of git-merge
that was introduced soon after v1.5.6. The users shouldn't be required to
run refresh to work this around.
^ permalink raw reply
* Re: TortoiseGit: missing CloneDlg.htm
From: Li Frank @ 2008-12-15 1:17 UTC (permalink / raw)
To: Jamie Border, git
In-Reply-To: <8666c7870812140955t7da5461avc17562b8aa17dbaf@mail.gmail.com>
Okay, I will check it.
Clone have not completed.
2008/12/15 Jamie Border <jborder@gmail.com>:
> Hey Frank!
>
> Nice work, but I think you might have left src\Tortoise\CloneDlg.htm
> out of the repo...
>
> TortoiseProcENG.rc line 2348 (IDR_HTML_CLONEDLG)
>
> master @ 3b2f3b4...
>
> Keep up the good work!
>
> Jamie
>
> --
>
> Jamie Border <jborder@gmail.com>
>
^ permalink raw reply
* Re: TortoiseGit
From: Li Frank @ 2008-12-15 1:12 UTC (permalink / raw)
To: Tim Visher, git
In-Reply-To: <c115fd3c0812140900k69b07101k7ce16002727c8268@mail.gmail.com>
What's better github compared with repos.or.cz.
2008/12/15 Tim Visher <tim.visher@gmail.com>:
> On Sun, Dec 14, 2008 at 7:26 AM, Alcides Fonseca <me@alcidesfonseca.com> wrote:
>
>> have your main git repo in github.com
>
> +1
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://burningones.com/
> http://five.sentenc.es/ - Spend less time on e-mail
>
^ permalink raw reply
* Re: TortoiseGit
From: Li Frank @ 2008-12-15 1:11 UTC (permalink / raw)
To: Geoffrey Lee; +Cc: git
In-Reply-To: <83d7aaa40812141412j20ae6b5l356d70a45d1d480b@mail.gmail.com>
TortoiseGit is base on TortoiseSVN 14459.
I will push 14459 TSVNCache code to repository tonight.
So you can have a base.
2008/12/15 Geoffrey Lee <geoffreyj.lee@gmail.com>:
> Ok, I'll start taking a look at TSVNCache.
> -Geoffrey Lee
>
> On Sun, Dec 14, 2008 at 1:46 AM, Li Frank <lznuaa@gmail.com> wrote:
>>
>> Yes!
>> TSVNcache.exe has not started porting! TSVNCache is used for overlay icon.
>> TortoiseMerge have not started porting!
>>
>> I think this release is just a begining.
>>
>> best regards
>> Frank Li
>>
>> 2008/12/14 Geoffrey Lee <geoffreyj.lee@gmail.com>:
>> > Hi Frank,
>> > I was just about to start a TortoiseGit project until I saw your project
>> > today. Would you like any help?
>> > -Geoffrey Lee
>
>
^ permalink raw reply
* Re: Possibly-spurious 'not uptodate. Cannot merge'
From: Sitaram Chamarty @ 2008-12-15 1:03 UTC (permalink / raw)
To: git
In-Reply-To: <874p16puuq.fsf@hades.wkstn.nix>
On 2008-12-14, Nix <nix@esperi.org.uk> wrote:
> In this situation, 'git diff' reports no changes at all, but 'git reset
> --hard' gets the tree back into a state where merging succeeds, as does
> 'git update-index --refresh'.
Wasn't there some situation in which merely running 'git
status' would have a similar effect? I seem to recall
reading that somewhere but now I can't find any mention of
it in 'git help status'.
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-15 1:03 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20081215004651.GA16205@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Wed, Dec 10, 2008 at 09:12:59PM +0100, Clemens Buchacher wrote:
>> If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge
>> will result in a "CONFLICT (delete/modify)". If the (now untracked) file
>> already exists and was not added to the index, it is overwritten with the
>> conflict resolution contents.
>
> The following patch fixes the problem described above, but it also breaks
> t6023-merge-rename-nocruft.sh, which tries to merge "A" renamed to "B" in
> HEAD and "A" modified in MERGE_HEAD, while ignoring an untracked file "A" in
> the working tree. If we want to be able to do this, we have to handle the
> other case after rename detection.
If the breakage is in merge-recursive but not in merge-resolve, my gut
feeling is that we should not be touching unpack-trees at all. With luck
I may be able to find some time to take a look at this myself but right
now we are entertaining a guest, so....
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Clemens Buchacher @ 2008-12-15 0:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20081210201259.GA12928@localhost>
On Wed, Dec 10, 2008 at 09:12:59PM +0100, Clemens Buchacher wrote:
> If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge
> will result in a "CONFLICT (delete/modify)". If the (now untracked) file
> already exists and was not added to the index, it is overwritten with the
> conflict resolution contents.
The following patch fixes the problem described above, but it also breaks
t6023-merge-rename-nocruft.sh, which tries to merge "A" renamed to "B" in
HEAD and "A" modified in MERGE_HEAD, while ignoring an untracked file "A" in
the working tree. If we want to be able to do this, we have to handle the
other case after rename detection.
---
unpack-trees.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 54f301d..de5b616 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -859,6 +859,9 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
if (index) {
if (verify_uptodate(index, o))
return -1;
+ } else if (remote && !remote_match) {
+ if (verify_absent(remote, "overwritten", o))
+ return -1;
}
o->nontrivial_merge = 1;
--
1.6.1.rc2
^ permalink raw reply related
* Re: [PATCH] Get rid of the last remnants of GIT_CONFIG_LOCAL
From: Junio C Hamano @ 2008-12-15 0:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812142310210.25197@racer>
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: Describe git-gui Tools menu configuration options.
From: Junio C Hamano @ 2008-12-15 0:43 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <200812142244.32438.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> writes:
> Now git gui has a customizable Tools menu, so this adds
> information about variables that are used to configure it.
I'll apply this as-is to include in -rc3; git-gui users please proofread
and send in any updates/fixes if necessary.
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 1:29 UTC (permalink / raw)
To: Nix; +Cc: Jakub Narebski, Sitaram Chamarty, git, Thomas Koch
In-Reply-To: <87prju5m6s.fsf@hades.wkstn.nix>
On Mon, 15 Dec 2008, Nix wrote:
> On 14 Dec 2008, Jakub Narebski spake thusly:
>> BTW. is outgoing SSH transport (from network to outside) blocked as
>> well?
>
> *No* ports are open. All they have is a (non-transparent) buggy HTTP
> proxy. These guys really don't get the Internet, despite their sales
> literature banging on endlessly about it.
>
> Looks like a lot of git-bundling is in my future.
no ports being open and a non-transparent HTTP proxy doesn't tell me that
they don't get the Internet. They could get the Internet just fine and be
suitably paranoid about it. Controlling outbound traffic is actually a
good thing in the current era of botnets (it prevents any of the machines
in that company from participating in a botnet if they can't reach the
command system)
the fact that the proxy is buggy could be an issue (I'm curious about what
types of bugs you are running into, what you see as a bug may not be)
if there is a business reason for the developers on that network to be
accessing resources on the Internet there should be a way to request that
the appropriate ports get opened. if the answer from the security folks is
'no' you should ask them why not and what could be done to get the job
done.
it may be that they don't want to provide access out from a bunch of
desktops. If that is the case it may be appropriate to build a box to put
into the DMZ that pulls from the upstream and then the inside desktops
pull from this gateway system.
the saying goes "don't attribute to malice what can be explained by
incompetence", but along the same lines in the security field, don't
attribute to incompetence what can be explained by people doing their jobs
that are ignorant of the requirements. they may also be operating under
constraints that you don't know about.
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 1:20 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <gi2rej$1mn$1@ger.gmane.org>
On Sun, 14 Dec 2008, Sitaram Chamarty wrote:
> On 2008-12-14, david@lang.hm <david@lang.hm> wrote:
>> On Sun, 14 Dec 2008, martin wrote:
>>> Why do you trust VPN more than the SSH?
>> in part it's that a VPN is a single point of control for all remote
>> access.
>>
>> If you use ssh you end up exposing all the individual machines
>
> Need not be true. None of my internal servers aer even
> accessible from the outside world; they're all in RFC1918
> space and there's only one gateway. This *is* my single
> point of control.
>
> I can setup different port numbers to forward to different
> internal servers (ssh, http, whatever I wish); that may
> sound like a form of "exposing" but in reality it's a lot
> *more* restrictive than setting up a VPN and granting access
> to it.
if you setup multiple inbound redirects for SSH (be they different IP
addresses or different ports), then you have the exact same situation as
those machines being accessed directly.
> I actually don't like VPNs; they imply that you're "inside"
> the network in some way, and I hate blurring that
> distinction. If I'm outside, I want to be acutely aware of
> it, and the fact that I can't even ping one of the inside
> hosts or see what's on it, or do anything other than what is
> specifically allowed by the gateway, is one way of ensuring
> this.
this is the mindset about SSH that I don't like. I see allowing SSH in as
blurring that distinction.
With a VPN you aren't blurring it, you _are_ letting the person into your
network. it's not appropriate to do this for everyone, but in the initial
post the desire was to have trusted company employees working remotely
push data to the repository. In that scenerio a VPN makes sense. If you
were doing a distributed opensource project it would probably not make
sense to allow contributers that you only know via e-mail to VPN into a
network to do their push (it can be agued that they shouldn't be doing a
push at all, but that's a workflow discussion ;-)
many people who would never allow a person to VPN into a network seem to
have no problem with that same person useing SSH to login to a machine on
that same network (and usually without trying to setup a limited shell).
In my opinion SSH and VPN access are both in the same category.
In both cases you can limit what the person you are granting access can
do. with a VPN you would use a firewall to control what they can access
after connecting to the VPN, with SSH you have to have the server they are
connecting to configured to limit what they can do.
VPNs tend to have better tools for auditing access and doing strong
authentication other than certificates (even certificate plus password is
better than just certificate). cerificates are good and useful, but they
aren't always enough by themselves.
there have been a number of breeches over the last few years that have
resulted from one client machine with SSH being comprimized and the
credentials then used to hop to other machines, gather other credentials
to then use to comprimize other machines, etc. while I am sure that there
have also been networks comprimized via VPN, I haven't heard of any
daisy-chain type attacks involving VPN access.
SSH is a monoculture. there is essentially only one implementation that is
used (although there are patches to it in some cases), and while it is
pretty good, any problems with it give you no options. with VPNs there are
many implementations, if any one has a problem it's possible to replace it
(painful to change out clients, but possible)
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: Nix @ 2008-12-15 0:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Sitaram Chamarty, git, Thomas Koch
In-Reply-To: <m3zlizdofy.fsf@localhost.localdomain>
On 14 Dec 2008, Jakub Narebski spake thusly:
> BTW. is outgoing SSH transport (from network to outside) blocked as
> well?
*No* ports are open. All they have is a (non-transparent) buggy HTTP
proxy. These guys really don't get the Internet, despite their sales
literature banging on endlessly about it.
Looks like a lot of git-bundling is in my future.
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 1:00 UTC (permalink / raw)
To: martin; +Cc: git
In-Reply-To: <4944E7E1.2030907@siamect.com>
On Sun, 14 Dec 2008, martin wrote:
> 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...
two things here
1. if you are running multiple different applications that all want to be
exposed via port 22 (like git for 'git push') then you may need to expose
numerous machines. tools that use SSH don't tend to have the ability to
use a gateway box before they start executing commands, they assume that
you will SSH directly into the destination box.
2. many people take the attitude that SSH is secure, period, end of
statement. so they think that every machine should be able to be contacted
via SSH, and you can then use SSH to do any other functionality on any
machine that you can dream up. a small minority of people try to minimize
what boxes are exposed directly (you are one of them), but most don't
David Lang
^ permalink raw reply
* Re: [PATCH try 2] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Jakub Narebski @ 2008-12-14 23:58 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git, Giuseppe Bilotta
In-Reply-To: <200812150020.53370.jnareb@gmail.com>
On Mon, 15 Dec 2008, Jakub Narebski wrote:
> On Sun, 14 Dec 2008, Matt McCutchen wrote:
>> On Sat, 2008-12-13 at 13:47 -0800, Jakub Narebski wrote:
>>>> @@ -845,7 +850,12 @@ sub href (%) {
>>>> $href =~ s,/$,,;
>>>>
>>>> # Then add the project name, if present
>>>> - $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
>>>> + my $proj_href = undef;
>>>> + if (defined $params{'project'}) {
>>>> + $href .= "/".esc_url($params{'project'});
>>>> + # Save for trailing-slash check below.
>>>> + $proj_href = $href;
>>>> + }
>>>> delete $params{'project'};
>>>>
>>>> # since we destructively absorb parameters, we keep this
>>>> @@ -903,6 +913,10 @@ sub href (%) {
>>>> $href .= $known_snapshot_formats{$fmt}{'suffix'};
>>>> delete $params{'snapshot_format'};
>>>> }
>>>> +
>>>> + # If requested in the configuration, add a trailing slash to a URL that
>>>> + # has nothing appended after the project path.
>>>> + $href .= '/' if ($use_pathinfo[1] && defined $proj_href && $href eq $proj_href);
>>>> }
>>>
>>> The check _feels_ inefficient. I think (but feel free to disagree) that
>>> it would be better to use something like $project_pathinfo, set it
>>> when adding project as pathinfo, and unset if we add anything else as
>>> pathinfo.
>>
>> I considered doing that, but I decided that not having to litter the
>> preceding code with manipulation of $project_pathinfo outweighed
>> whatever negligible performance difference there might be.
>
> On the other hand, with having boolean variable named for example
> $trailing_slash or $add_trailing_slash, you can set it to appropriate
> value by default (should project list URL: http://example.com/ have
> trailing slash), and at [almost] each 'delete $params{<param>}' either
> set it to true, or set it to false. This way it would be easy to
> extend to have trailing slash also for example for OPML link
> http://example.com/opml/ or not have it and use http://example.com/opml
>
> I think it is not only more efficient, but is also more flexible.
> Admittedly it is also more complicated...
On the other hand you don't need such flexibility, so perhaps simpler
code (or at least less changes) outweights this issue...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH try 2] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Jakub Narebski @ 2008-12-14 23:55 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Giuseppe Bilotta, git
In-Reply-To: <200812150039.58797.jnareb@gmail.com>
Jakub Narebski wrote:
> On Sun, 14 Dec 2008, Matt McCutchen wrote:
> > I was thinking of proposing the addition of some info about my setup,
> > including the rewrite rules, to the documentation. Maybe we could do
> > that after dealing with the patches.
>
> Do you plan updating "Webserver configuration" section in
> gitweb/README?
>
> BTW. could you please check if the $my_uri and $my_link need to be set
> in gitweb config for your configuration, or did some of Giuseppe's
> path_info improvements took care of that, and it is no longer needed?
It would be I think good idea to describe there _and_ in the commit
message why would you prefer for gitweb path_info links to be generated
with trailing slash; how it looks resolution for URL with and without
trailing slash.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 0:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: martin, git
In-Reply-To: <m3vdtndo9b.fsf@localhost.localdomain>
On Sun, 14 Dec 2008, Jakub Narebski wrote:
> 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.
that works for sysadmin access to a box, it doesn't work for git push
(unless that box also happens to be your git repository). multiply by a
few dozen different applications that all take the attitude 'just us SSH
and you are secure' and you end up with a bunch of machines that _have_ to
be exposed via SSH.
>> 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?
the VPN is typically (but not always) run by the group who is focused on
controlling and auditing access.
>> 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.
you would be surprised.
I'm not saying that SSH is bad for all uses by any means. I'm responding
to the people who seemd to be thinking that anyone who didn't like the
'use SSH' option are luddites and just don't know what they are doing.
different networks can have different stances and all be right (for their
environment)
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 0:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Sitaram Chamarty, git
In-Reply-To: <m34p17f3bh.fsf@localhost.localdomain>
On Sun, 14 Dec 2008, Jakub Narebski wrote:
> 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?
you aren't having the VPN software running commands passed to it by the
outside world.
> [...]
>
> 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).
I'm not saying that it's good to roll your own from scratch, you need to
use libraries that have been examined and validated, but SSH is a swiss
army knife, it's designed to do lots of things, and when you are exposing
things to the outside world you want them to be as limited as possible to
limit the damage that they can do.
David Lang
^ permalink raw reply
* Re: [PATCH try 2] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Jakub Narebski @ 2008-12-14 23:39 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Giuseppe Bilotta, git
In-Reply-To: <1229217235.3360.13.camel@mattlaptop2.local>
On Sun, 14 Dec 2008, Matt McCutchen wrote:
> On Sat, 2008-12-13 at 23:23 +0100, Giuseppe Bilotta wrote:
>> On Sat, Dec 13, 2008 at 10:47 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> Matt McCutchen <matt@mattmccutchen.net> writes:
>>>
>>>> My Web site uses pathinfo mode and some rewrite magic to show the gitweb
>>>> interface at the URL of the real repository directory (which users also
>>>> pull from). In this case, it's desirable to end generated links to the
>>>> project in a trailing slash so the Web server doesn't have to redirect
>>>> the client to add the slash. This patch adds a second element to the
>>>> "pathinfo" feature configuration to control the trailing slash.
>>>>
>>>> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
[...]
>>>
>>> Errr... I see that it adds trailing slash only for project-only
>>> path_info links, but the commit message was not entirely clear for me.
>>
>> If indeed the additional / is only asked for in summary view, I think
>> there's no need for a feature toggle, we can always put it there. If
>> not, I'm really curious about seeing the rewrite rules (they might
>> also be worth adding to the gitweb documentation as examples of 'power
>> usage').
>
> The trailing slash is used only when the URL refers to a project with no
> appended parameters (i.e., summary view), because the URL refers to the
> real git dir on disk (hence, pulling from the same URL) and it plays
> nicer with the Web server configuration to have the trailing slash.
It would be nice to have in commit message that we want to have
trailing slash in the cases where URL can correspond to filesystem
path.
But there are two cases:
* http://example.com/ corresponding to $projectroot on filesystem,
and giving projects_list in gitweb
* http://example.com/project.git/ corresponding to project.git dir
on filesystem, and giving project summary view in gitweb.
> I was wary about changing the default behavior, but if you and Jakub
> both think it's OK, that's great.
Now I'm not so sure... but I guess the performance cost would be
negligible, and I'm not sure if it would be worth slight complication
in the code (and configuration).
> I was thinking of proposing the addition of some info about my setup,
> including the rewrite rules, to the documentation. Maybe we could do
> that after dealing with the patches.
Do you plan updating "Webserver configuration" section in
gitweb/README?
BTW. could you please check if the $my_uri and $my_link need to be set
in gitweb config for your configuration, or did some of Giuseppe's
path_info improvements took care of that, and it is no longer needed?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Added EXIT STATUS section in git-status documentation
From: Junio C Hamano @ 2008-12-14 23:29 UTC (permalink / raw)
To: nadim khemir; +Cc: git list
In-Reply-To: <200812150012.14071.nadim@khemir.net>
nadim khemir <nadim@khemir.net> writes:
> +EXIT STATUS
> +-----------
> +The command exits with status 0 if there is a different between the index
> +and HEAD. IE, running `git commit`, with the same arguments as your
> +'git status' command, would create a new commit.
> +
Wording: s/different/difference/
But more importantly, even if there is no difference between the index and
HEAD, "git status -a" would say "Ok, you will commit something" if you
have modifications to (or removals of) tracked paths. The description in
the original you removed was Ok only because it does not talk anything
about giving parameters to "git status", but now you are mentioning that
case as well, you would need to adjust the description.
^ permalink raw reply
* Re: [PATCH try 2] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Jakub Narebski @ 2008-12-14 23:20 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git, Giuseppe Bilotta
In-Reply-To: <1229219030.3360.44.camel@mattlaptop2.local>
On Sun, 14 Dec 2008, Matt McCutchen wrote:
> On Sat, 2008-12-13 at 13:47 -0800, Jakub Narebski wrote:
> >
> > Errr... I see that it adds trailing slash only for project-only
> > path_info links, but the commit message was not entirely clear for me.
>
> I will clarify the message.
It would be nice (e.g. to have example URL with trailing slash ensured).
[...]
> > > @@ -829,8 +834,8 @@ sub href (%) {
> > > }
> > > }
> > >
> > > - my $use_pathinfo = gitweb_check_feature('pathinfo');
> > > - if ($use_pathinfo) {
> > > + my @use_pathinfo = gitweb_get_feature('pathinfo');
> >
> > Why not name those variables for better readability?
> >
> > + my ($use_pathinfo, $trailing_slash) = gitweb_get_feature('pathinfo');
>
> I'll do that.
Note that you wouldn't need that if you decide that it makes sense
(and doesn't have disadvantages) to *always* add trailing slash to
the end of path_info for some kinds of gitweb links.
> > > + if ($use_pathinfo[0]) {
> > > # try to put as many parameters as possible in PATH_INFO:
> > > # - project name
> > > # - action
> > > @@ -845,7 +850,12 @@ sub href (%) {
> > > $href =~ s,/$,,;
> > >
> > > # Then add the project name, if present
> > > - $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> > > + my $proj_href = undef;
> > > + if (defined $params{'project'}) {
> > > + $href .= "/".esc_url($params{'project'});
> > > + # Save for trailing-slash check below.
> > > + $proj_href = $href;
> > > + }
> > > delete $params{'project'};
> > >
> > > # since we destructively absorb parameters, we keep this
> > > @@ -903,6 +913,10 @@ sub href (%) {
> > > $href .= $known_snapshot_formats{$fmt}{'suffix'};
> > > delete $params{'snapshot_format'};
> > > }
> > > +
> > > + # If requested in the configuration, add a trailing slash to a URL that
> > > + # has nothing appended after the project path.
> > > + $href .= '/' if ($use_pathinfo[1] && defined $proj_href && $href eq $proj_href);
> > > }
> >
> > The check _feels_ inefficient. I think (but feel free to disagree) that
> > it would be better to use something like $project_pathinfo, set it
> > when adding project as pathinfo, and unset if we add anything else as
> > pathinfo.
>
> I considered doing that, but I decided that not having to litter the
> preceding code with manipulation of $project_pathinfo outweighed
> whatever negligible performance difference there might be.
On the other hand, with having boolean variable named for example
$trailing_slash or $add_trailing_slash, you can set it to appropriate
value by default (should project list URL: http://example.com/ have
trailing slash), and at [almost] each 'delete $params{<param>}' either
set it to true, or set it to false. This way it would be easy to
extend to have trailing slash also for example for OPML link
http://example.com/opml/ or not have it and use http://example.com/opml
I think it is not only more efficient, but is also more flexible.
Admittedly it is also more complicated...
> > > + if ($use_pathinfo[0]) {
> > > $action .= "/".esc_url($project);
> > > + # Add a trailing slash if requested in the configuration.
> > > + $action .= '/' if ($use_pathinfo[1]);
> >
> > Hmmm... let me check something... you rely on the fact that $project
> > doesn't end with slash, while I think (but please check it) that it
> > can end with slash if it is provided by CGI query.
>
> You are right; in fact, this is already a problem for the strict_export
> check. Gitweb should probably strip trailing slashes when it reads the
> "p" parameter. I will submit a separate patch for that.
That would be nice. TIA.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Possibly-spurious 'not uptodate. Cannot merge'
From: Nix @ 2008-12-14 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwse21rh6.fsf@gitster.siamese.dyndns.org>
On 14 Dec 2008, Junio C. Hamano said:
> Ancient git, whose "git merge" was a scripted command, refreshed the index
> before starting, but it lost that when the command was rewritten in C soon
> after v1.5.6 by 1c7b76b (Build in merge, 2008-07-07), and nobody noticed
> it until 76c3fb1 (Merge branch 'mv/merge-refresh', 2008-10-09). In other
> words, the tip of 'master' (and upcoming 1.6.1) already has the fix.
Excellent! I do love this precognitive bugfixing thing.
(It's not as if the update-index workaround is terribly onerous, but
it's annoying and not something a git newbie might think of.)
^ permalink raw reply
* git-svn and "svn move" of an entire project
From: Jukka Zitting @ 2008-12-14 23:14 UTC (permalink / raw)
To: git
Hi,
I'm hosting git-svn mirrors of many Apache projects [1] and every now
and then I need to deal with cases where an entire project (trunk,
tags, branches, everything) is moved from one location to another
within the svn server. For example in revision 723328 [2] the Apache
Abdera project was moved from incubator/abdera to just abdera.
At [3] I found instructions on how to cope with such situations when
git-svn is used to follow only the svn trunk of a project. Based on
that I came up with the bash script below that allows me to update a
full (init -s) git-svn mirror to point to a new location in svn.
The script seems to work fine but I'm wondering if there's an easier
way to achieve this (and if there are any obvious mistakes in my
script). One alternative is of course to recreate the full git-svn
mirror, but that risks breaking the git history if someone has
meanwhile modified a commit message in svn or changed an author name.
Ideally I'd just run "git svn init" again with the new location and
let git-svn take care of the rest. Unfortunately that doesn't seem to
work and I'm not familiar enough with git-svn internals to know where
to start implementing something like this.
[1] http://jukka.zitting.name/git/
[2] http://svn.apache.org/viewvc?view=rev&revision=723328
[3] http://duncan.mac-vicar.com/blog/archives/282
BR,
Jukka Zitting
----
#!/bin/bash
# Location of the authors file
AUTHORS=/home/jukka/git/authors.txt
# Example:
# move-svn-project.sh /var/git/abdera.git 723328 incubator/abdera abdera
DIR=$1
REV=$2
OLD=$3
NEW=$4
# Set GIT_DIR so all git commands know which repo to use
export GIT_DIR=$DIR
# This function is the main workhorse of this script.
# It takes an existing git-svn branch and updates it
# to point to the first corresponding post-move revision
# in svn. If the branch no longer exists in svn, it is
# removed from here as well.
map() {
REF=$1
URL=$2
echo "Mapping $REF to $URL"
# Keep a backup copy of the original git-svn metadata
cp "$GIT_DIR/svn/.metadata" "$GIT_DIR/svn/.metadata.bak"
# Set up a temporary git-svn remote for just this subtree
git svn init -R tmp -i tmp-git-svn-map-branch "$URL"
# Get the first post-move version of this subtree and modify the branch
git svn fetch -r "$REV" --authors-file "$AUTHORS" tmp
if git rev-parse --verify --quiet refs/remotes/tmp-git-svn-map-branch; then
git update-ref "$REF" refs/remotes/tmp-git-svn-map-branch
else
git update-ref -d "$REF"
fi
# Remove all the temporary git-svn settings
git update-ref -d refs/remotes/tmp-git-svn-map-branch
git config --remove-section svn-remote.tmp
rm -rf $GIT_DIR/svn/tmp-git-svn-map-branch
mv $GIT_DIR/svn/.metadata.bak $GIT_DIR/svn/.metadata
}
# Map all git-svn branches to corresponding new URLs
BASE=$(git config svn-remote.svn.url)
git for-each-ref refs/remotes | cut -d / -f 3- | while read REF; do
case "$REF" in
*@*)
echo "Skipping $REF"
;;
trunk)
map "refs/remotes/trunk" "$BASE/$NEW/trunk"
;;
tags/*)
map "refs/remotes/$REF" "$BASE/$NEW/$REF"
;;
*)
map "refs/remotes/$REF" "$BASE/$NEW/branches/$REF"
;;
esac
done
# Update git-svn configuration to point to the new URLs
for NAME in fetch branches tags; do
VALUE="$(git config svn-remote.svn.$NAME)"
git config "svn-remote.svn.$NAME" "${VALUE/#$OLD/$NEW}"
done
# Clean the old git-svn directory, it'll be regenerated on next update
rm -r "$GIT_DIR/svn"
^ permalink raw reply
* [PATCH] Added EXIT STATUS section in git-status documentation
From: nadim khemir @ 2008-12-14 23:12 UTC (permalink / raw)
To: git list
>From d6438d2f245cf36e5824c5d408c3100a01aae7ad Mon Sep 17 00:00:00 2001
Signed-off-by: nadim khemir <nadim@khemir.net>
---
Documentation/git-status.txt | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 84f60f3..e49ae2a 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -24,10 +24,6 @@ The command takes the same set of options as 'git-commit'; it
shows what would be committed if the same options are given to
'git-commit'.
-If there is no path that is different between the index file and
-the current HEAD commit (i.e., there is nothing to commit by running
-`git commit`), the command exits with non-zero status.
-
OUTPUT
------
@@ -57,6 +53,12 @@ to -1 or an unlimited number), the submodule summary will be enabled and a
summary of commits for modified submodules will be shown (see --summary-limit
option of linkgit:git-submodule[1]).
+EXIT STATUS
+-----------
+The command exits with status 0 if there is a different between the index
+and HEAD. IE, running `git commit`, with the same arguments as your
+'git status' command, would create a new commit.
+
SEE ALSO
--------
linkgit:gitignore[5]
--
1.6.1.rc2.20.gde0d
^ permalink raw reply related
* [PATCH] git-gui: Get rid of the last remnants of GIT_CONFIG_LOCAL
From: Johannes Schindelin @ 2008-12-14 22:12 UTC (permalink / raw)
To: git, spearce
In-Reply-To: <alpine.DEB.1.00.0812142310210.25197@racer>
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
You might want to hold off on that, as git-gui is supposed to be
less tightly coupled to git.git than, say, git-svn.
The commit removing support for GIT_CONFIG_LOCAL is from Mon Jun
30 03:37:47 2008 -0400...
git-gui.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 8a4b42d..bab66bd 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3315,7 +3315,6 @@ by %s:
{^GIT_PAGER$} -
{^GIT_TRACE$} -
{^GIT_CONFIG$} -
- {^GIT_CONFIG_LOCAL$} -
{^GIT_(AUTHOR|COMMITTER)_DATE$} {
append msg " - $name\n"
incr ignored_env
--
1.6.0.4.1189.g8876f
^ permalink raw reply related
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