* Re: fatal output from git-show really wants a terminal
From: Junio C Hamano @ 2008-12-15 8:15 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <7vr64eb9ha.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Boyd Stephen Smith Jr." <bss03@volumehost.net> writes:
>
>>> $ git log >foo.out
>>>
>>>and start a pager, which makes no sense.
>>
>> Good point, I'll try and consider that while I investgate the history of the
>> issue.
>
> Isn't the issue about 61b8050 (sending errors to stdout under $PAGER,
> 2008-02-16)? With that commit, we changed things so that when we send the
> standard output to the $PAGER, we dup stderr to the $PAGER as well,
> because otherwise any output to stderr will be wiped out by whatever the
> pager does and the user will not notice the breakage. E.g.
>
> $ git log
>
> will just show reams of output, and you won't see any errors and warnings
> even if there were any encountered during the process.
>
> Unfortunately we did it unconditionally. There is no reason to dup stderr
> to the $PAGER if the command line was:
>
> $ git log 2>error.log
>
> in which case you would want to view the normal output in your $PAGER and
> you are keeping the log of the error output in a separate file.
I haven't heard anything more about this, but if you were indeed
discussing the change made by 61b8050, I think the fix should just be like
this.
| 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
--git c/pager.c w/pager.c
index aa0966c..f19ddbc 100644
--- c/pager.c
+++ w/pager.c
@@ -70,7 +70,8 @@ void setup_pager(void)
/* original process continues, but writes to the pipe */
dup2(pager_process.in, 1);
- dup2(pager_process.in, 2);
+ if (isatty(2))
+ dup2(pager_process.in, 2);
close(pager_process.in);
/* this makes sure that the parent terminates after the pager */
^ permalink raw reply related
* Re: is gitosis secure?
From: Mike Hommey @ 2008-12-15 7:17 UTC (permalink / raw)
To: david; +Cc: martin, git
In-Reply-To: <alpine.DEB.1.10.0812141655150.17688@asgard.lang.hm>
On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
> 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.
But ssh itself allows you to do proxying. See ProxyCommand in
ssh_config's manpage.
Mike
^ permalink raw reply
* Re: is gitosis secure?
From: Rogan Dawes @ 2008-12-15 7:52 UTC (permalink / raw)
To: david; +Cc: Sitaram Chamarty, git
In-Reply-To: <alpine.DEB.1.10.0812150026570.17688@asgard.lang.hm>
david@lang.hm wrote:
> On Mon, 15 Dec 2008, Rogan Dawes wrote:
>
>> david@lang.hm wrote:
>>
>>>
>>> what would I like to see in an ideal world?
>>>
>>> something that runs as the git user, does not enable tunneling, and only
>>> does the data transfer functions needed for a push. it should use
>>> off-the-shelf libraries for certificate authentication and tie into PAM
>>> for additional authentication.
>>
>> How about a git-specific deployment/configuration of ssh? You can
>> certainly run multiple copies of SSH (on different ports), by providing
>> a restricted configuration file you can disable tunneling and any other
>> functionality that you don't like.
>>
>> And if you want it to run as a non-root user, simply choose a port>1024,
>> but keep in mind that you won't be able to authenticate by password
>> (IIRC, only key auth will work when running non-root), or setuid to
>> those users when they log in. Nonetheless, this could be sufficient for
>> gitosis, since everything runs as the specified user anyway, and IIRC,
>> gitosis wants individual SSH pubkeys to allow access.
>
> IMHO this is better then exposing a 'normal' ssh daemon to the Internet
> just to be able to do a git push. the fact that you loose authentication
> options is not a good thing, are you sure that you cannot hook into PAM
> authentication for this?
I *think* that an unprivileged user cannot invoke PAM for accounts other
than its own, and most certainly cannot change to that other user
without being setuid (or having the appropriate capability).
>> In many cases, especially if the tool is unix based, you can specify (in
>> ~/.ssh/config) a Proxy command that is executed before the SSH protocol
>> negotiation begins, which results in stdin and stdout being connected to
>> the SSH daemon at the destination. The most common variations are the
>> HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
>> the limit in terms of what is possible.
>
> as I just commented, this looks like it's a per-user config option that
> is designed to be used as a proxy out of the network you are in to get
> to the Internet, not to be used at the far side of a connection to get
> to things on a remote network. as I understand it, you would need to
> change this config file for each different destination network you need
> to connect to.
That may be its original intention, but it can nonetheless be used for
other purposes. Yes, you might need a different configuration for each
network that you need to access, and quite possibly for each location
that you need to access them from. This may result in config entry
proliferation, but it is manageable, especially with the openssh
wildcard syntax in the config file.
man ssh_config:
Host
Restricts the following declarations (up to the next Host keyword) to be
only for those hosts that match one of the patterns given after the
keyword. If more than one pattern is provided, they should be separated
by whitespace. A single `*' as a pattern can be used to provide global
defaults for all hosts. The host is the hostname argument given on the
command line (i.e. the name is not converted to a canonicalized host
name before matching).
e.g
Host *-home
ProxyCommand . . . .
FWIW.
Rogan
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 8:37 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Sitaram Chamarty, git
In-Reply-To: <49460531.8010808@dawes.za.net>
On Mon, 15 Dec 2008, Rogan Dawes wrote:
> david@lang.hm wrote:
>
>>
>> as a security person who doesn't like how ssh is used for everything,
>> let me list a couple of concerns.
>>
>> ssh is default allow (it lets you run any commands), you can lock it
>> down with effort.
>>
>> ssh defaults to establishing a tunnel between machines that other
>> network traffic can use to bypass your system. yes I know that with
>> enough effort and control of both systems you can tunnel over anything,
>> the point is that ssh is eager to do this for you (overly eager IMHO)
>>
>> ssh depends primarily on certificates that reside on untrusted machines.
>> it can be made to work with tokens or such, but it takes a fair bit of
>> effort.
>>
>> sshd runs as root on just about every system
>>
>> people trust ssh too much. they tend to think that anything is
>> acceptable if it's done over ssh (this isn't a technical issue, but it
>> is a social issue)
>>
>>
>> what would I like to see in an ideal world?
>>
>> something that runs as the git user, does not enable tunneling, and only
>> does the data transfer functions needed for a push. it should use
>> off-the-shelf libraries for certificate authentication and tie into PAM
>> for additional authentication.
>
> How about a git-specific deployment/configuration of ssh? You can
> certainly run multiple copies of SSH (on different ports), by providing
> a restricted configuration file you can disable tunneling and any other
> functionality that you don't like.
>
> And if you want it to run as a non-root user, simply choose a port>1024,
> but keep in mind that you won't be able to authenticate by password
> (IIRC, only key auth will work when running non-root), or setuid to
> those users when they log in. Nonetheless, this could be sufficient for
> gitosis, since everything runs as the specified user anyway, and IIRC,
> gitosis wants individual SSH pubkeys to allow access.
IMHO this is better then exposing a 'normal' ssh daemon to the Internet
just to be able to do a git push. the fact that you loose authentication
options is not a good thing, are you sure that you cannot hook into PAM
authentication for this?
>> the authentication would not be any better than with SSH, but the rest
>> would be better. I was very pleased to watch the git-daemon development,
>> and the emphisis on it running with minimum privilages and provide just
>> the functionality that was needed, and appropriately assuming that any
>> connection from the outside is hostile until proven otherwise.
>
> In another mail, David wrote:
>
>> 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.
>
> In many cases, especially if the tool is unix based, you can specify (in
> ~/.ssh/config) a Proxy command that is executed before the SSH protocol
> negotiation begins, which results in stdin and stdout being connected to
> the SSH daemon at the destination. The most common variations are the
> HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
> the limit in terms of what is possible.
as I just commented, this looks like it's a per-user config option that is
designed to be used as a proxy out of the network you are in to get to the
Internet, not to be used at the far side of a connection to get to things
on a remote network. as I understand it, you would need to change this
config file for each different destination network you need to connect to.
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 8:25 UTC (permalink / raw)
To: Mike Hommey; +Cc: martin, git
In-Reply-To: <20081215071737.GA32387@glandium.org>
On Mon, 15 Dec 2008, Mike Hommey wrote:
> On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
>> 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.
>
> But ssh itself allows you to do proxying. See ProxyCommand in
> ssh_config's manpage.
I was not aware of that option, but it looks like it's designed to be one
setting for all your ssh communications, so unless you always use the same
gateway box to get to your destination you would need to tweak your ssh
config for each different thing that you are doing.
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: Rogan Dawes @ 2008-12-15 7:20 UTC (permalink / raw)
To: david; +Cc: Sitaram Chamarty, git
In-Reply-To: <alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm>
david@lang.hm wrote:
>
> as a security person who doesn't like how ssh is used for everything,
> let me list a couple of concerns.
>
> ssh is default allow (it lets you run any commands), you can lock it
> down with effort.
>
> ssh defaults to establishing a tunnel between machines that other
> network traffic can use to bypass your system. yes I know that with
> enough effort and control of both systems you can tunnel over anything,
> the point is that ssh is eager to do this for you (overly eager IMHO)
>
> ssh depends primarily on certificates that reside on untrusted machines.
> it can be made to work with tokens or such, but it takes a fair bit of
> effort.
>
> sshd runs as root on just about every system
>
> people trust ssh too much. they tend to think that anything is
> acceptable if it's done over ssh (this isn't a technical issue, but it
> is a social issue)
>
>
> what would I like to see in an ideal world?
>
> something that runs as the git user, does not enable tunneling, and only
> does the data transfer functions needed for a push. it should use
> off-the-shelf libraries for certificate authentication and tie into PAM
> for additional authentication.
How about a git-specific deployment/configuration of ssh? You can
certainly run multiple copies of SSH (on different ports), by providing
a restricted configuration file you can disable tunneling and any other
functionality that you don't like.
And if you want it to run as a non-root user, simply choose a port>1024,
but keep in mind that you won't be able to authenticate by password
(IIRC, only key auth will work when running non-root), or setuid to
those users when they log in. Nonetheless, this could be sufficient for
gitosis, since everything runs as the specified user anyway, and IIRC,
gitosis wants individual SSH pubkeys to allow access.
> the authentication would not be any better than with SSH, but the rest
> would be better. I was very pleased to watch the git-daemon development,
> and the emphisis on it running with minimum privilages and provide just
> the functionality that was needed, and appropriately assuming that any
> connection from the outside is hostile until proven otherwise.
In another mail, David wrote:
> 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.
In many cases, especially if the tool is unix based, you can specify (in
~/.ssh/config) a Proxy command that is executed before the SSH protocol
negotiation begins, which results in stdin and stdout being connected to
the SSH daemon at the destination. The most common variations are the
HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
the limit in terms of what is possible.
Rogan
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Junio C Hamano @ 2008-12-15 6:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3prjvdngm.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> [New Topics]
>>
>> * jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
>> - gitweb: cache $parent_commit info in git_blame()
>> - gitweb: A bit of code cleanup in git_blame()
>> - gitweb: Move 'lineno' id from link to row element in git_blame
>
> I wonder if it should made into 1.6.1 for the performance improvements
> in 'blame' view...
Does is addresses a grave bug? I thought not.
>> [Post 1.6.1 items]
>>
>> * gb/gitweb-patch (Sat Dec 6 16:02:35 2008 +0100) 3 commits
>> Updated series. Reviews and Acks?
>
> I'll try to find time to review (and most probably Ack) later today.
Thanks.
>> * jn/gitweb-utf8 (Mon Dec 1 19:01:42 2008 +0100) 1 commit
>> + gitweb: Fix handling of non-ASCII characters in inserted HTML
>> files.
>>
>> A bugfix.
>
> What about
>
> + gitweb: Fix bug in insert_file() subroutine
It already is part of 'master' for some time, isn't it?.
>> * jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
> ...
> What happened to this series to be so stale^Wstalled?
Mostly lack of positive feedbacks which is the same thing as "nobody but
the author is interested'.
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 6:32 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Nix, git
In-Reply-To: <alpine.DEB.2.00.0812142121090.9552@vellum.laroia.net>
On Sun, 14 Dec 2008, Asheesh Laroia wrote:
> 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.
>
> If that's the only way you can access the network, you can take advantage of
> the way HTTP proxies deal with HTTPS: they typically let it through byte for
> byte.
>
> "connect.c is the simple relaying command to make network connection via
> SOCKS and https proxy. It is mainly intended to be used as proxy command of
> OpenSSH."
>
> Run sshd on port 443, use connect.c, and you're set.
>
> (Except for some really smart SSL-aware HTTP proxies that verify that it's an
> SSL connection of some kind. In theory, you could then sslwrap your sshd and
> then be set.)
although, if the company is doing this as a deliberate security measure
(as opposed to not knowing what they are doing), setting up a bypass like
this can get you fired for deliberatly bypassing a security device.
also, examples of people going to this sort of effort to bypass security
policies end up with employees being trusted less.
you are far better off going through channels and discussing what you are
trying to do and why.
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: Asheesh Laroia @ 2008-12-15 5:24 UTC (permalink / raw)
To: Nix; +Cc: git
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.
If that's the only way you can access the network, you can take advantage
of the way HTTP proxies deal with HTTPS: they typically let it through
byte for byte.
"connect.c is the simple relaying command to make network connection via
SOCKS and https proxy. It is mainly intended to be used as proxy command
of OpenSSH."
Run sshd on port 443, use connect.c, and you're set.
(Except for some really smart SSL-aware HTTP proxies that verify that it's
an SSL connection of some kind. In theory, you could then sslwrap your
sshd and then be set.)
-- Asheesh.
--
Q: Why did the astrophysicist order three hamburgers?
A: Because he was hungry.
^ permalink raw reply
* Re: TortoiseGit
From: Geoffrey Lee @ 2008-12-15 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Li Frank, git
In-Reply-To: <7vhc56yume.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 14, 2008 at 7:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> That cuts both ways. Most development around git happen on this list and
> taking a project's development discussion away from here will hide it from
> the mainstream development. People involved in TortoiseGit may decide
> that asking for some change in the core is a good idea on their own Wiki,
> and after spending significant amount of effort come back to this list
> with a request for change, which may turn out to be suboptimal (or worse,
> impossible) solution, and you can avoid such wasted effort by keeping the
> discussion on list here.
We ended up creating:
http://groups.google.com/group/tortoisegit-users
http://groups.google.com/group/tortoisegit-dev
http://groups.google.com/group/tortoisegit-announce
Although I believe Frank wanted to keep discussion on here for now
until our growth warrants a separate list.
-Geoffrey Lee
^ permalink raw reply
* Re: TortoiseGit
From: Junio C Hamano @ 2008-12-15 3:39 UTC (permalink / raw)
To: Geoffrey Lee; +Cc: Li Frank, git
In-Reply-To: <83d7aaa40812141803x4cdc1151y8ef82b9e19eceb80@mail.gmail.com>
"Geoffrey Lee" <geoffreyj.lee@gmail.com> writes:
> On Sun, Dec 14, 2008 at 5:12 PM, Li Frank <lznuaa@gmail.com> wrote:
>> What's better github compared with repos.or.cz.
>
> Github projects come with a wiki,...
That cuts both ways. Most development around git happen on this list and
taking a project's development discussion away from here will hide it from
the mainstream development. People involved in TortoiseGit may decide
that asking for some change in the core is a good idea on their own Wiki,
and after spending significant amount of effort come back to this list
with a request for change, which may turn out to be suboptimal (or worse,
impossible) solution, and you can avoid such wasted effort by keeping the
discussion on list here.
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-15 3:34 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <7v63lm1c76.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 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....
-- >8 --
merge-recursive: do not clobber untracked working tree garbage
When merge-recursive wanted to create a new file in the work tree (either
as the final result, or a hint for reference purposes while delete/modify
conflicts), it unconditionally overwrote an untracked file in the working
tree. Be careful not to lose whatever the user has that is not tracked.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
merge-recursive.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git c/merge-recursive.c w/merge-recursive.c
index a0c804c..2da4333 100644
--- c/merge-recursive.c
+++ w/merge-recursive.c
@@ -447,6 +447,30 @@ static void flush_buffer(int fd, const char *buf, unsigned long size)
}
}
+static int would_lose_untracked(const char *path)
+{
+ int pos = cache_name_pos(path, strlen(path));
+
+ if (pos < 0)
+ pos = -1 - pos;
+ while (pos < active_nr &&
+ !strcmp(path, active_cache[pos]->name)) {
+ /*
+ * If stage #0, it is definitely tracked.
+ * If it has stage #2 then it was tracked
+ * before this merge started. All other
+ * cases the path was not tracked.
+ */
+ switch (ce_stage(active_cache[pos])) {
+ case 0:
+ case 2:
+ return 0;
+ }
+ pos++;
+ }
+ return file_exists(path);
+}
+
static int make_room_for_path(const char *path)
{
int status;
@@ -462,6 +486,14 @@ static int make_room_for_path(const char *path)
die(msg, path, "");
}
+ /*
+ * Do not unlink a file in the work tree if we are not
+ * tracking it.
+ */
+ if (would_lose_untracked(path))
+ return error("refusing to lose untracked file at '%s'",
+ path);
+
/* Successful unlink is good.. */
if (!unlink(path))
return 0;
^ permalink raw reply related
* Re: TortoiseGit
From: Geoffrey Lee @ 2008-12-15 2:03 UTC (permalink / raw)
To: Li Frank; +Cc: git
In-Reply-To: <1976ea660812141712w196540caue9525ddbae8192f3@mail.gmail.com>
On Sun, Dec 14, 2008 at 5:12 PM, Li Frank <lznuaa@gmail.com> wrote:
> What's better github compared with repos.or.cz.
Github projects come with a wiki, and you can watch the project for
changes. If you are only concerned about having your source code
publicly accessible, then repo.or.cz is perfectly fine.
Regardless of whether or not you migrate to github, I recommend that
you setup mailing lists for announcements, users, and devs.
-Geoffrey Lee
^ permalink raw reply
* 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
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