* 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
* [PATCH] Get rid of the last remnants of GIT_CONFIG_LOCAL
From: Johannes Schindelin @ 2008-12-14 22:10 UTC (permalink / raw)
To: git, gitster
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>
---
config.c | 5 +----
git-svn.perl | 3 +--
t/t5400-send-pack.sh | 2 +-
t/test-lib.sh | 1 -
4 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/config.c b/config.c
index 8bd6106..8ff2b4b 100644
--- a/config.c
+++ b/config.c
@@ -640,10 +640,7 @@ int git_config(config_fn_t fn, void *data)
char *repo_config = NULL;
const char *home = NULL;
- /* $GIT_CONFIG makes git read _only_ the given config file,
- * $GIT_CONFIG_LOCAL will make it process it in addition to the
- * global config file, the same way it would the per-repository
- * config file otherwise. */
+ /* Setting $GIT_CONFIG makes git read _only_ the given config file. */
if (config_exclusive_filename)
return git_config_from_file(fn, config_exclusive_filename, data);
if (git_config_system() && !access(git_etc_gitconfig(), R_OK))
diff --git a/git-svn.perl b/git-svn.perl
index 914c707..efda5c1 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5007,8 +5007,7 @@ sub minimize_connections {
}
}
if (@emptied) {
- my $file = $ENV{GIT_CONFIG} || $ENV{GIT_CONFIG_LOCAL} ||
- "$ENV{GIT_DIR}/config";
+ my $file = $ENV{GIT_CONFIG} || "$ENV{GIT_DIR}/config";
print STDERR <<EOF;
The following [svn-remote] sections in your config file ($file) are empty
and can be safely removed:
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index da69f08..b21317d 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -99,7 +99,7 @@ test_expect_success \
! test -f victim/.git/refs/heads/extra
'
-unset GIT_CONFIG GIT_CONFIG_LOCAL
+unset GIT_CONFIG
HOME=`pwd`/no-such-directory
export HOME ;# this way we force the victim/.git/config to be used.
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 8936173..22ed448 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -471,7 +471,6 @@ PATH=$TEST_DIRECTORY/..:$PATH
GIT_EXEC_PATH=$(pwd)/..
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
-unset GIT_CONFIG_LOCAL
GIT_CONFIG_NOSYSTEM=1
GIT_CONFIG_NOGLOBAL=1
export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_CONFIG_NOGLOBAL
--
1.6.0.4.1189.g8876f
^ permalink raw reply related
* [BUG] The description of pickaxe in git-blame(1) is wrong
From: Jakub Narebski @ 2008-12-14 21:33 UTC (permalink / raw)
To: git
I think that the description of how 'pickaxe' feature works in
Documentation/git-blame.txt is wrong. It says:
Apart from supporting file annotation, git also supports searching the
development history for when a code snippet occurred in a change. This makes it
possible to track when a code snippet was added to a file, moved or copied
between files, and eventually deleted or replaced. _It works by searching for
a text string in the diff_. A small example:
The part "It works by searching for a text string in the diff" is,
if I remember correctly, wrong. Actually it (I think) compares how
many matches are in pre-image and in post-image, and shows these
commits where those number differ.
This for example means that pickaxe would not pick commit which
moved a fragment from one place to other without change, I think.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Documentation: Describe git-gui Tools menu configuration options.
From: Alexander Gavrilov @ 2008-12-14 19:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Now git gui has a customizable Tools menu, so this adds
information about variables that are used to configure it.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Documentation/config.txt | 51 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b233fe5..2a06a3c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -839,6 +839,57 @@ gui.blamehistoryctx::
Context` menu item is invoked from 'git gui blame'. If this
variable is set to zero, the whole history is shown.
+guitool.<name>.cmd::
+ Specifies the shell command line to execute when the corresponding item
+ of the linkgit:git-gui[1] `Tools` menu is invoked. This option is
+ mandatory for every tool. The command is executed from the root of
+ the working directory, and in the environment it receives the name of
+ the tool as 'GIT_GUITOOL', the name of the currently selected file as
+ 'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if
+ the head is detached, 'CUR_BRANCH' is empty).
+
+guitool.<name>.needsfile::
+ Run the tool only if a diff is selected in the GUI. It guarantees
+ that 'FILENAME' is not empty.
+
+guitool.<name>.noconsole::
+ Run the command silently, without creating a window to display its
+ output.
+
+guitool.<name>.norescan::
+ Don't rescan the working directory for changes after the tool
+ finishes execution.
+
+guitool.<name>.confirm::
+ Show a confirmation dialog before actually running the tool.
+
+guitool.<name>.argprompt::
+ Request a string argument from the user, and pass it to the tool
+ through the 'ARGS' environment variable. Since requesting an
+ argument implies confirmation, the 'confirm' option has no effect
+ if this is enabled. If the option is set to 'true', 'yes', or '1',
+ the dialog uses a built-in generic prompt; otherwise the exact
+ value of the variable is used.
+
+guitool.<name>.revprompt::
+ Request a single valid revision from the user, and set the
+ 'REVISION' environment variable. In other aspects this option
+ is similar to 'argprompt', and can be used together with it.
+
+guitool.<name>.revunmerged::
+ Show only unmerged branches in the 'revprompt' subdialog.
+ This is useful for tools similar to merge or rebase, but not
+ for things like checkout or reset.
+
+guitool.<name>.title::
+ Specifies the title to use for the prompt dialog. The default
+ is the tool name.
+
+guitool.<name>.prompt::
+ Specifies the general prompt string to display at the top of
+ the dialog, before subsections for 'argprompt' and 'revprompt'.
+ The default value includes the actual command.
+
help.browser::
Specify the browser that will be used to display help in the
'web' format. See linkgit:git-help[1].
--
1.6.0.4.30.gf4240
^ permalink raw reply related
* Re: Possibly-spurious 'not uptodate. Cannot merge'
From: Junio C Hamano @ 2008-12-14 19:33 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <874p16puuq.fsf@hades.wkstn.nix>
Nix <nix@esperi.org.uk> writes:
> Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get
> this:
> ...
> I suspect the 'problem' is that I've hardlinked a bunch of build trees
> to this tree in the interim via 'cp -al', then applied patches to each
> of those trees with quilt, then deleted all those trees prior to the git
> pull. This doesn't change the original files at all, but *does* update
> their link count: is git getting annoyed by the corresponding change in
> ctime? (If so, why did it start happening only fairly recently?)
In git timescale 1.5.4 is not recent at all ;-)
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.
The fix should have been cherry-picked to 'maint' to be part of 1.6.0.X
series, but it apparently was forgotten. Fault of mine and Shawn ;-)
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Tim Visher @ 2008-12-14 17:45 UTC (permalink / raw)
To: Li Frank; +Cc: sverre, Jakub Narebski, git
In-Reply-To: <1976ea660812140548k940a73buf307cd331b775f31@mail.gmail.com>
On Sun, Dec 14, 2008 at 8:48 AM, Li Frank <lznuaa@gmail.com> wrote:
> I think TortoiseGit can make git popular at windows enviroment.
> Window user is waiting for the good UI. Porting from TortoiseSVN is
> fastest way.
I think you nailed it on the head there, Li. I had a hell of a time
trying to convince my team to use Subversion over (*gasp*) VSS,
despite the abominable network performance that we were getting with
VSS _and_ all of its obvious flaws (which they freely admitted), until
I finally showed them Tortoise (which I don't personally use) and then
they were all for it. Something like Tortoise for Git on Windows
would remove a __huge__ barrier to entry for most people that aren't
already comfortable with the command line. As simple as git is from
the command line, certain people just don't want to bother.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Marcin Slusarz @ 2008-12-14 17:33 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <20081212182827.28408.40963.stgit@warthog.procyon.org.uk>
On Fri, Dec 12, 2008 at 06:28:27PM +0000, David Howells wrote:
> +REVERTING COMMITTED CHANGES
> +---------------------------
> +
> +And sometimes you'll want to revert changes that you've committed, but that are
> +now buried beneath other commits. Short of discarding and reapplying commits,
> +you have to apply a reverse patch:
> +
> + git diff %COMMIT_ID | patch -p1 -R
> +
> +and then commit it. Both the original application and the reversion will be
> +retained by GIT.
"git revert $commit" is a bit shorter.
Marcin
^ permalink raw reply
* Re: TortoiseGit
From: Tim Visher @ 2008-12-14 17:00 UTC (permalink / raw)
To: Alcides Fonseca; +Cc: Li Frank, git
In-Reply-To: <937EE54D-1FC0-4FFA-B273-C98C7CF321D4@alcidesfonseca.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: How to maintain private/secret/confidential branch.
From: Łukasz Lew @ 2008-12-14 16:48 UTC (permalink / raw)
To: Alexander Potashev; +Cc: Nick Andrew, git
In-Reply-To: <20081214160645.GA21358@myhost>
Hi Alexander,
On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:
> Hello, Łukasz!
>
> On 16:38 Sun 14 Dec , Łukasz Lew wrote:
>> Thanks Nick, thats really helpful (and surprisingly simple).
>> I have a couple more questions:
>>
>> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
>> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
>> >> I don't know how to make such a scenario work:
>> >> - two repositories: pub, priv
>> >> - priv is clone/branch of pub
>> >> - there is some constant developement both in pub and priv
>> >> - there are regular syncs with pub in priv
>> >>
>> >> Problem:
>> >> Occasionally I want to push some changes from priv to pub.
>> >> Then after syncing with pub I want to get as few conflicts as possible.
>> >>
>> >> Is it possible to do with git?
>> >
>> > Git can do almost anything. One should instead ask "How to do this
>> > with git?" :-)
>>
>> So I've heard, but not yet experienced it myself. I'm thrilled to try.
>>
>> >
>> > If I understand your problem, you could solve it with git cherry-pick
>> > and rebase. On priv, make a for-public branch from a pub branch. Then
>> > cherry-pick the commits you want from your private branch into the
>> > for-public branch.
>>
>> That almost works. Can I somehow split existing commits just like in git-add -p?
> It's, however, better to make more commits to not experience the need of
> commit splitting.
Indeed good advice and best practice, but another best practice is to
not commit not compiling state.
My common scenario is that I code a big change in priv repository, and
after that I find that some of its parts can and should be moved to
pub.
>
> But you can use '--no-commit' option of 'git cherry-pick' and 'git merge'
> (and 'git pull' as well as 'git merge'). For example:
>
> git cherry-pick --no-commit <sha1> # cherry-pick without commiting
> git reset -- # unstage all changes
> git add -p # patch update
>
> You can also use 'git add -i' (interative mode) instead of 'git add -p'.
That's a possible solution indeed.
Now I see that the right "plumbing" I need is splitting a commit into
smaller parts and merging several commits into a larger one.
I think that would be nice functionality.
Do you know any tool that would allow such a manipulation on commits
in history?
Thanks
Lukasz
>
>>
>> > Push your for-public branch to pub,
>> > then rebase your private branch.
>>
>> Rebase to the tip of master? Is it needed? Ie. cherry-pick does not
>> remove the patch from
>> the master in priv.
>>
>> If I now pull from pub, I will get the same change and it mereges nicely :D
>>
>> Can I get away without creating for_pub branch? maybe cherry pick in
>> pub from priv somehow?
>>
>> >
>> > Nick.
>> >
>
> Alexander
>
^ 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