* Alles wird Git, Berlin, Oct 3rd, 2009
From: Johannes Schindelin @ 2009-09-25 6:19 UTC (permalink / raw)
To: git
Hi,
as some of you already know, I will be unable to Git Together with other
Gits in California this year. So the only version of such a Git Together
I will have this year is the Berlin one.
Details: it will take place on October 3rd, 2009, at the Zuse-Institut
Berlin: http://www.zib.de/besucher/index.en.html (graciously offered by
Steffen Prohaska).
We will have a room with fast internet connection and a beamer.
As for the schedule: I had something like this in mind:
10:00 Saying hello to everybody
10:30 Dscho says something about the history of msysGit
11:00 Somebody else talks about something else
11:30 ...
...
After the talks, maybe a little hackathon-style coding (I know what I
would like to implement, but let's just see what happens).
In the evening, we probably order pizza or go to a restaurant nearby.
See also http://git.or.cz/gitwiki/GitTogether
Ciao,
Dscho
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-25 6:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Heiko Voigt, git
In-Reply-To: <26ae428a0909242310r259ccf5eya7c95b8f43fc5c23@mail.gmail.com>
2009/9/25 Howard Miller <howard@e-learndesign.co.uk>:
> Hi,
>
> I don't really understand the answers I have been given. Trying
> desperately not to "top post" see bellow...
>
> 2009/9/24 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
>> Heiko Voigt <hvoigt@hvoigt.net> writes:
>>
>>> On Thu, Sep 24, 2009 at 03:51:44PM +0100, Howard Miller wrote:
>>>> Gitosis obviously uses keypairs but the config file addresses the user
>>>> by name/host. How does gitosis connect the two together? Is it any
>>>> more complicated than the user detail at the end of the public key?
>>
>> The user@host at the end of the public key is mostly a comment. No
>> serious software would use it for authentication, since you can freely
>> edit it without changing the rest of the key.
>>
>>> Not much different. It uses the command feature of the authorized_keys
>>> file of ssh to limit access to the 'gitosis-serve' command which is
>>> given the username from the gitosis.conf as argument.
>>
>> ... the username -> key association being done in gitosis's
>> configuration itself (the key held in keydir/foobar is the one of user
>> foobar).
>
>
> Yes, I realise that the association is done im gitosis' config file,
> but that is exactly my question - how does that association work?
>
> To take a step back - I have to put a name (or a name@hostname) in the
> configuration file. How do I know what that should be in the general
> sense? When I create a key it doesn't ask me for the username I want
> so I see a disconnect here. Do I put a name, do I put name@hostname,
> does it matter and (again) how does it know which is 'my' public key?
> Is it the naming convention of the key or something magic? Plus, when
> I actually use gitosis, I am logging as the user 'git' so how does it
> know who I am? I am thoroughly confused by the whole thing. I'm
> probably missing something really obvious but, AFAIK, this is not
> covered at all in the docs.
>
> Thanks!
>
> Howard
>
Ahh... just read Heiko's post properly and actually looked at the
authorized_keys file. This is now starting to make some sense. So the
name in config has to match that sent to gitosis-server presumably. I
still don't quite see the cause and effect. If I don't like being
howard@x.y.z and would rather be just 'howard' what can I change? It
tells me not to edit that file!
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-25 6:10 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Heiko Voigt, git
In-Reply-To: <vpqskeckuto.fsf@bauges.imag.fr>
Hi,
I don't really understand the answers I have been given. Trying
desperately not to "top post" see bellow...
2009/9/24 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
>
>> On Thu, Sep 24, 2009 at 03:51:44PM +0100, Howard Miller wrote:
>>> Gitosis obviously uses keypairs but the config file addresses the user
>>> by name/host. How does gitosis connect the two together? Is it any
>>> more complicated than the user detail at the end of the public key?
>
> The user@host at the end of the public key is mostly a comment. No
> serious software would use it for authentication, since you can freely
> edit it without changing the rest of the key.
>
>> Not much different. It uses the command feature of the authorized_keys
>> file of ssh to limit access to the 'gitosis-serve' command which is
>> given the username from the gitosis.conf as argument.
>
> ... the username -> key association being done in gitosis's
> configuration itself (the key held in keydir/foobar is the one of user
> foobar).
Yes, I realise that the association is done im gitosis' config file,
but that is exactly my question - how does that association work?
To take a step back - I have to put a name (or a name@hostname) in the
configuration file. How do I know what that should be in the general
sense? When I create a key it doesn't ask me for the username I want
so I see a disconnect here. Do I put a name, do I put name@hostname,
does it matter and (again) how does it know which is 'my' public key?
Is it the naming convention of the key or something magic? Plus, when
I actually use gitosis, I am logging as the user 'git' so how does it
know who I am? I am thoroughly confused by the whole thing. I'm
probably missing something really obvious but, AFAIK, this is not
covered at all in the docs.
Thanks!
Howard
^ permalink raw reply
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Li Hong @ 2009-09-25 2:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.01.0909241021120.3303@localhost.localdomain>
2009/9/25 Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Thu, 24 Sep 2009, Li Hong wrote:
>>
>> When using 'git cat-file' recently, I find its option interface is somewhat
>> inconvenient or mistakenly-designed.
>
> You likely shouldn't use 'cat-file' at all. Have you looked at 'git show'?
> That's the command meant for human beings.
>
> 'git cat-file' is really really low-level plumbing. Humans should
> generally never use it. It's one of the original git commands (it was
> literally in the original git commit), and it does some really low-level
> stuff that is good for scripting but not for any normal use.
>
> Linus
>
Yes, I know 'git show' and use it mostly. I just think the interface
of 'cat-file'
is not well designed even used by other scripts or porcelains. But from another
respect, it doesn't really annoy normal users much and we should retain
backwards compatibility. So I give up.
Thanks for all your feedbacks.
-Li Hong
^ permalink raw reply
* git merge conflict resolution?
From: Joe Perches @ 2009-09-25 1:18 UTC (permalink / raw)
To: Linux Kernel Mailing List, git; +Cc: Linus Torvalds, Russell King
In-Reply-To: <200909250101.n8P11HwO030173@hera.kernel.org>
Question about how git does merge conflict resolution.
This patch doesn't really apply, and the results after the
patch aren't what at least I expect.
Patch 1: ====================
On Fri, 2009-09-25 at 01:01 +0000, Linux Kernel Mailing List wrote:
> Gitweb: http://git.kernel.org/linus/784546839fd45de485b9e9e4cd072b9d53100aa5
> Commit: 784546839fd45de485b9e9e4cd072b9d53100aa5
> Parent: 07198871dac00e9c250d647e1976d7aee527b805
> ARM: Update mailing list addresses
> The old list has now been closed off; update the now invalid addresses.
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> MAINTAINERS | 106 +++++++++++++++++++++++++++++-----------------------------
> 1 files changed, 53 insertions(+), 53 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 837b598..12be157 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -497,7 +497,7 @@ F: arch/arm/include/asm/floppy.h
>
> ARM PORT
> M: Russell King <linux@arm.linux.org.uk>
> -L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
> +L: linux-arm-kernel@lists.infradead.org
> W: http://www.arm.linux.org.uk/
> S: Maintained
> F: arch/arm/
====================
vs the patch that was applied a bit earlier:
Patch 2: ====================
commit efc03ecb9d674588a13aee27289c2af2afe5e6b4
Author: Joe Perches <joe@perches.com>
Date: Mon Sep 21 17:04:27 2009 -0700
MAINTAINERS: move ARM lists to infradead
====================
Patch 2 was applied before patch 1.
Russell's patch removes the "(moderated for non-subscribers)"
from each entry, yet the final result includes it.
Can someone help me understand why?
^ permalink raw reply
* Re: [msysGit] Re: Add MinGW header files to build git with MSVC
From: Frank Li @ 2009-09-25 0:18 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Sebastian Schuberth, msysGit, git, Johannes.Schindelin, gitster,
j6t, raa.lkml, snaury
In-Reply-To: <4ABA0698.7020604@gmail.com>
>
> This was a patch which originated from Frank Li's original series. While we
> might have been able to simply use the MSVC one, I'm sure Frank had a reason
> for overriding it with the small content which you see in this patch. We'll
> have to ask Frank about that. We can always remove it now, if the MSVC
> version works ok and doesn't introduce any compiler errors/warnings.
>
At beginning, I don't want to copy all msys header files to
vcbuilc\include and copy only necessary header file and data
structure.
Many structures have been defined at MSVC standard file. So I use
simple utimer.h and unistd.h and dirent.h.
Best regards
Frank Li
^ permalink raw reply
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Nicolas Pitre @ 2009-09-24 19:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Linus Torvalds, Li Hong, Junio C Hamano, git
In-Reply-To: <vpqy6o4kv24.fsf@bauges.imag.fr>
On Thu, 24 Sep 2009, Matthieu Moy wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > 'git cat-file' is really really low-level plumbing. Humans should
> > generally never use it.
>
> ... except to understand Git better ;-). I enjoyed being able to to a
> 'git cat-file' on a tree or commit object when I started with Git.
In the context of learning git at that level, the current option
interface for cat-file shouldn't look too strange though.
Nicolas
^ permalink raw reply
* Re: How does gitosis know who the key belongs to
From: Matthieu Moy @ 2009-09-24 19:26 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Howard Miller, git
In-Reply-To: <20090924172610.GA31309@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> On Thu, Sep 24, 2009 at 03:51:44PM +0100, Howard Miller wrote:
>> Gitosis obviously uses keypairs but the config file addresses the user
>> by name/host. How does gitosis connect the two together? Is it any
>> more complicated than the user detail at the end of the public key?
The user@host at the end of the public key is mostly a comment. No
serious software would use it for authentication, since you can freely
edit it without changing the rest of the key.
> Not much different. It uses the command feature of the authorized_keys
> file of ssh to limit access to the 'gitosis-serve' command which is
> given the username from the gitosis.conf as argument.
... the username -> key association being done in gitosis's
configuration itself (the key held in keydir/foobar is the one of user
foobar).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Matthieu Moy @ 2009-09-24 19:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Li Hong, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.01.0909241021120.3303@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 'git cat-file' is really really low-level plumbing. Humans should
> generally never use it.
... except to understand Git better ;-). I enjoyed being able to to a
'git cat-file' on a tree or commit object when I started with Git.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH v2] perl/Makefile.PL: detect MakeMaker versions incompatible with DESTDIR
From: Brandon Casey @ 2009-09-24 18:21 UTC (permalink / raw)
To: gitster; +Cc: git, c, Brandon Casey
In-Reply-To: <7wQSYSBJPoVtvyGI0lqsDW37w4byCpgpMaHiDKALwW_oJ9nHXddX9OBMnqXGZBVAo2U7Tc1BMxg@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
It appears that ExtUtils::MakeMaker versions older than 6.11 do not
implement the DESTDIR mechanism. So add a test to the generated perl.mak
to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
abort with a message suggesting the use of NO_PERL_MAKEMAKER.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
This just reverses the logic in the test on $(MM_VERSION) so that the test
will also fail if MM_VERSION is unset. Who knows if ancient versions set
it. Sorry for the quick v2.
-brandon
perl/Makefile.PL | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 320253e..0b9deca 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -5,6 +5,14 @@ sub MY::postamble {
instlibdir:
@echo '$(INSTALLSITELIB)'
+ifneq (,$(DESTDIR))
+ifeq (0,$(shell expr '$(MM_VERSION)' '>' 6.10))
+$(error ExtUtils::MakeMaker version "$(MM_VERSION)" is older than 6.11 and so \
+ is likely incompatible with the DESTDIR mechanism. Try setting \
+ NO_PERL_MAKEMAKER=1 instead)
+endif
+endif
+
MAKE_FRAG
}
--
1.6.4.3
^ permalink raw reply related
* [PATCH] perl/Makefile.PL: detect MakeMaker versions incompatible with DESTDIR
From: Brandon Casey @ 2009-09-24 18:02 UTC (permalink / raw)
To: gitster; +Cc: git, c, Brandon Casey
In-Reply-To: <7vk4zrt035.fsf@alter.siamese.dyndns.org>
From: Brandon Casey <drafnel@gmail.com>
It appears that ExtUtils::MakeMaker versions older than 6.11 do not
implement the DESTDIR mechanism. So add a test to the generated perl.mak
to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
abort with a message suggesting the use of NO_PERL_MAKEMAKER.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
>> Possibly it is related to the version of MakeMaker? I am using version
>> 6.17 (Revision: 1.133) along with Perl 5.8.4 on Solaris 10 x86. The
>> MakeMaker version should be in the header at the top of the perl.mak
>> file.
>
> I think that is it. DESTDIR support in MakeMaker seems to be lacking in
> medieval versions of Perl. It appears that it started being usable at
> around its 6.11 (and 6.17 you have is fine).
>
> http://kobesearch.cpan.org/htdocs/ExtUtils-MakeMaker/Changes.html
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6131#c7
How about something like this?
Seems to work correctly for me on IRIX 6.5 and Solaris 7 with
ExtUtils::MakeMaker 6.03.
-brandon
perl/Makefile.PL | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 320253e..8974015 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -5,6 +5,14 @@ sub MY::postamble {
instlibdir:
@echo '$(INSTALLSITELIB)'
+ifneq (,$(DESTDIR))
+ifeq (1,$(shell expr '$(MM_VERSION)' '<' 6.11))
+$(error ExtUtils::MakeMaker version "$(MM_VERSION)" is older than 6.11 and so \
+ is likely incompatible with the DESTDIR mechanism. Try setting \
+ NO_PERL_MAKEMAKER=1 instead)
+endif
+endif
+
MAKE_FRAG
}
--
1.6.4.3
^ permalink raw reply related
* Re: How does gitosis know who the key belongs to
From: Heiko Voigt @ 2009-09-24 17:26 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0909240751k3a799750h121935a79439b389@mail.gmail.com>
On Thu, Sep 24, 2009 at 03:51:44PM +0100, Howard Miller wrote:
> Gitosis obviously uses keypairs but the config file addresses the user
> by name/host. How does gitosis connect the two together? Is it any
> more complicated than the user detail at the end of the public key?
Not much different. It uses the command feature of the authorized_keys
file of ssh to limit access to the 'gitosis-serve' command which is
given the username from the gitosis.conf as argument. gitosis-server
then takes care of the access control.
> The second part of my question then is is it possible to use the same
> private key on more than one host?
Yes definitely. It identifies the user not the host. Although you can
use differenty keys if you want.
cheers Heiko
^ permalink raw reply
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Linus Torvalds @ 2009-09-24 17:23 UTC (permalink / raw)
To: Li Hong; +Cc: Junio C Hamano, git
In-Reply-To: <3a3680030909240804w1399ed7fhd6367300544f34f@mail.gmail.com>
On Thu, 24 Sep 2009, Li Hong wrote:
>
> When using 'git cat-file' recently, I find its option interface is somewhat
> inconvenient or mistakenly-designed.
You likely shouldn't use 'cat-file' at all. Have you looked at 'git show'?
That's the command meant for human beings.
'git cat-file' is really really low-level plumbing. Humans should
generally never use it. It's one of the original git commands (it was
literally in the original git commit), and it does some really low-level
stuff that is good for scripting but not for any normal use.
Linus
^ permalink raw reply
* [PATCH] git-gui: fix use of uninitialized variable
From: Jens Lehmann @ 2009-09-24 16:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
This fixes a bug introduced by the "display summary when showing diff of a
submodule" patch. It lead to a "no such variable" error when opening the
diff context menu while no diff was shown.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
git-gui/git-gui.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 3c0ce26..f727111 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1132,6 +1132,7 @@ set current_branch {}
set is_detached 0
set current_diff_path {}
set is_3way_diff 0
+set is_submodule_diff 0
set is_conflict_diff 0
set selected_commit_type new
set diff_empty_count 0
--
1.6.5.rc2.5.gbbf1
^ permalink raw reply related
* Re: [RFC] 'git cat-file' needs a better design on its option interface
From: Jeff King @ 2009-09-24 16:48 UTC (permalink / raw)
To: Li Hong; +Cc: Junio C Hamano, git
In-Reply-To: <3a3680030909240804w1399ed7fhd6367300544f34f@mail.gmail.com>
On Thu, Sep 24, 2009 at 11:04:31PM +0800, Li Hong wrote:
> When using 'git cat-file' recently, I find its option interface is somewhat
> inconvenient or mistakenly-designed.
Yes, the current interface has grown over time and kind of sucks. I
agree with all of your complaints.
That being said, the reason it has grown in that way is that as a
plumbing command, cat-file must retain backwards compatibility so as not
to break existing scripts which make use of it. And it is not enough to
look through git.git and fix all of our scripts; the interface to
cat-file is a public one, and we must take care not to break other
people's custom scripts.
I'm not quite sure where your complaints are coming from. Do you want:
1. Something more sane to type in your terminal for everyday use? Then
you probably want to use (or invent) some sort of user-facing
porcelain that does a similar thing. This is mostly covered by "git
show" these days, but if there is something lacking, proposals
describing your use case would be welcome.
2. To script around cat-file, but there is some action you want to do
that is missing from the interface? In that case, can you describe
your use case in more detail, and exactly what addition you want to
make to the cat-file interface to accomodate it?
3. To just clean up cruft from the interface for your scripts? I am
somewhat sympathetic to wanting a nicer interface. But keep in
mind that we have to keep the old interface around to support
historical scripts. So while your new interface may be more
flexible and less complex, you have to consider whether having
_both_ interfaces will actually be less complex in the long run.
-Peff
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Eric Raible @ 2009-09-24 16:45 UTC (permalink / raw)
To: git
In-Reply-To: <5b5e291e0909240225q49a202abk7cf1a0c8f715ad5f@mail.gmail.com>
Deon George <deon.george <at> gmail.com> writes:
> > Third, if the above isn't what you want, then you can manually
> > intermingle working directories of different git repositories
> > (probably requiring decouplig of bare git repository (git-dir)
> > from working area (work-tree)).
>
> Ahh, now this sounds like it might be what I want to do - I think I'll
> explore this. I can see that it would provide file level autonomy
> only, but as a starting point I think it will help heaps...
Proof of concept:
export GIT_WORK_TREE=.
git --git-dir=.git1 init
git --git-dir=.git1 add view1-file
git --git-dir=.git1 commit -m"view1 initial"
git --git-dir=.git2 init
git --git-dir=.git2 add view1-file
git --git-dir=.git2 commit -m"view2 initial"
git --git-dir=.git1 log
git --git-dir=.git2 log
^ permalink raw reply
* Re: Per-remote tracking branch
From: Matthieu Moy @ 2009-09-24 16:00 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20090924113537.GA14113@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>> Setup "foo" so that it fetches "master" only, i.e. have
>> remote.foo.fetch = refs/heads/master:refs/remotes/foo/master
>>
>> You get that setup with: git remote add -t master foo git://...
>>
>> Then there's only one possible choice for "git pull", and it will take
>> that.
>
> Ah, crap, spoke too soon. That works only when branch.<name>.merge is
> not set. Though that's not that much of a problem. When your "primary"
> remote (the one set for branch.<name>.remote) also fetches just a single
> branch, "git pull" will still work, even if branch.<name>.merge is not
> set.
Yes, that's it. Thanks for your anwser, it works.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [RFC] 'git cat-file' needs a better design on its option interface
From: Li Hong @ 2009-09-24 15:04 UTC (permalink / raw)
To: Junio C Hamano, git
Hi All,
When using 'git cat-file' recently, I find its option interface is somewhat
inconvenient or mistakenly-designed.
1. There is no default action. You have to use -p or <type> option,
even for a simple look at the content of an object. It is better if
we can provide a default action just like 'cat' does.
2. Can't control the output. Several output options can't be used at
the same time. Can't control what to output and how to output. I
suggest here we use a simple format string to let the human being
and other batch scripts happy.
3. Batch mode is handled seperately and differently.
4. <type> option has a mix meaning (raw print and object dereference)
and is also inconsistent with -x style option.
* for raw print, an format char such as 'r' should be a good choice.
* for dereference, should use the uniform rev-naming. (e.g.
v0.99.8^{commit})
So I propose to amend the interface as follow:
git cat-file [-b] [-f <fmt>] [-e] <args> ...
-b read more objects from stdin
-f provide a output format string
-e silent, exit with zero when there's no error
the default action is to pretty-print the content when there is no
other options except -b.
A format string example can be formed as follow (this needs more discuss):
"blabla %t\s%s\t%h\n%p\n%r\n\n"
%t: type
%s: size
%h: sha1
%p: pretty-print
%r: raw-print
However, this change will give a heavy impact on many documents and scripts
depending on this command. There are 233 references in source code according
to a trivial count 'grep -r "cat-file" * | wc -l', not to mention many
private usage of this command.
So this is just a RFC. If I can get a very positive feedback from the
community, I may start to do the real code change.
Any ideas?
- Li Hong
^ permalink raw reply
* How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-24 14:51 UTC (permalink / raw)
To: git
Hi,
This is probably another one of my stupid questions.
Gitosis obviously uses keypairs but the config file addresses the user
by name/host. How does gitosis connect the two together? Is it any
more complicated than the user detail at the end of the public key?
The second part of my question then is is it possible to use the same
private key on more than one host?
Cheers,
Howard
^ permalink raw reply
* How does gitosis know who the key belongs to
From: Howard Miller @ 2009-09-24 14:49 UTC (permalink / raw)
To: git
Hi,
This is probably another one of my stupid questions.
Gitosis obviously uses keypairs but the config file addresses the user
by name/host. How does gitosis connect the two together? Is it any
more complicated than the user detail at the end of the public key?
The second part of my question then is is it possible to use the same
private key on more than one host?
Cheers,
Howard
^ permalink raw reply
* [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
From: Sebastian Schuberth @ 2009-09-24 14:42 UTC (permalink / raw)
To: git; +Cc: mstormo
From 9a0d743e227872189b17afb0b5c69b15422a0eef Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Thu, 24 Sep 2009 16:26:59 +0200
Subject: [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
The format of the generated MSVC solution file is fixed in a way that just
opening it in Visual Studio and immediately closing it again without performing
any modifications does not trigger a prompt to save the solution file. This
behavior was caused by several minor incompatibilities between the generated
file and what Visual Studio 2008 expected, so Visual Studio transparently fixed
the file format, marking it internally as modified.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 42 +++++++---------------------
1 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 50daa03..d53ff2c 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -571,45 +571,29 @@ sub createGlueProject {
print F "\"${libname}\", \"${libname}\\${libname}.vcproj\", \"${uuid}\"";
print F "$SLN_POST";
}
+ my $uuid_libgit = $build_structure{"LIBS_libgit_GUID"};
+ my $uuid_xdiff_lib = $build_structure{"LIBS_xdiff_lib_GUID"};
foreach (@apps) {
my $appname = $_;
my $uuid = $build_structure{"APPS_${appname}_GUID"};
print F "$SLN_PRE";
- print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"";
+ print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"\n";
+ print F " ProjectSection(ProjectDependencies) = postProject\n";
+ print F " ${uuid_libgit} = ${uuid_libgit}\n";
+ print F " ${uuid_xdiff_lib} = ${uuid_xdiff_lib}\n";
+ print F " EndProjectSection";
print F "$SLN_POST";
}
print F << "EOM";
Global
- GlobalSection(SolutionConfiguration) = preSolution
- ConfigName.0 = Debug|Win32
- ConfigName.1 = Release|Win32
+ GlobalSection(SolutionConfigurationPlatforms) = preSolution
+ Debug|Win32 = Debug|Win32
+ Release|Win32 = Release|Win32
EndGlobalSection
- GlobalSection(ProjectDependencies) = postSolution
EOM
- foreach (@{$build_structure{"APPS"}}) {
- my $appname = $_;
- my $appname_clean = $_;
- $appname_clean =~ s/\//_/g;
- $appname_clean =~ s/\.exe//;
-
- my $uuid = $build_structure{"APPS_${appname_clean}_GUID"};
- my $dep_index = 0;
- foreach(@{$build_structure{"APPS_${appname}_LIBS"}}) {
- my $libname = $_;
- $libname =~ s/\//_/g;
- $libname =~ s/\.(a|lib)//;
- my $libuuid = $build_structure{"LIBS_${libname}_GUID"};
- if (defined $libuuid) {
- print F "\t\t${uuid}.${dep_index} = ${libuuid}\n";
- $dep_index += 1;
- }
- }
- }
-
print F << "EOM";
- EndGlobalSection
- GlobalSection(ProjectConfiguration) = postSolution
+ GlobalSection(ProjectConfigurationPlatforms) = postSolution
EOM
foreach (@libs) {
my $libname = $_;
@@ -630,10 +614,6 @@ EOM
print F << "EOM";
EndGlobalSection
- GlobalSection(ExtensibilityGlobals) = postSolution
- EndGlobalSection
- GlobalSection(ExtensibilityAddIns) = postSolution
- EndGlobalSection
EndGlobal
EOM
close F;
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Sebastian Schuberth @ 2009-09-24 14:40 UTC (permalink / raw)
To: git; +Cc: mstormo
From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Thu, 24 Sep 2009 15:52:25 +0200
Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
In order to be able to open the generated solution file by double-clicking it
in Windows Explorer, all project files need to use DOS line-endings and a
comment about the Visual Studio version needs to be added to the header of the
solution file. This also fixes the icon that is displayed for the solution file
in Windows Explorer.
Note that opening the solution file from a running instance of Visual Studio
already worked before.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..50daa03 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -131,6 +131,7 @@ sub createLibProject {
$includes =~ s/-I//g;
mkdir "$target" || die "Could not create the directory $target for lib project!\n";
open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+ binmode F, ":crlf";
print F << "EOM";
<?xml version="1.0" encoding = "Windows-1252"?>
<VisualStudioProject
@@ -353,6 +354,7 @@ sub createAppProject {
$includes =~ s/-I//g;
mkdir "$target" || die "Could not create the directory $target for lib project!\n";
open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+ binmode F, ":crlf";
print F << "EOM";
<?xml version="1.0" encoding = "Windows-1252"?>
<VisualStudioProject
@@ -537,7 +539,7 @@ sub createGlueProject {
print "Generate solutions file\n";
$rel_dir = "..\\$rel_dir";
$rel_dir =~ s/\//\\/g;
- my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n";
+ my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n# Visual Studio 2008\n";
my $SLN_PRE = "Project(\"{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\") = ";
my $SLN_POST = "\nEndProject\n";
@@ -560,6 +562,7 @@ sub createGlueProject {
@apps = @tmp;
open F, ">git.sln" || die "Could not open git.sln for writing!\n";
+ binmode F, ":crlf";
print F "$SLN_HEAD";
foreach (@libs) {
my $libname = $_;
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
From: Sebastian Schuberth @ 2009-09-24 14:42 UTC (permalink / raw)
To: git; +Cc: mstormo
From 9a0d743e227872189b17afb0b5c69b15422a0eef Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Thu, 24 Sep 2009 16:26:59 +0200
Subject: [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
The format of the generated MSVC solution file is fixed in a way that just
opening it in Visual Studio and immediately closing it again without performing
any modifications does not trigger a prompt to save the solution file. This
behavior was caused by several minor incompatibilities between the generated
file and what Visual Studio 2008 expected, so Visual Studio transparently fixed
the file format, marking it internally as modified.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 42 +++++++---------------------
1 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 50daa03..d53ff2c 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -571,45 +571,29 @@ sub createGlueProject {
print F "\"${libname}\", \"${libname}\\${libname}.vcproj\", \"${uuid}\"";
print F "$SLN_POST";
}
+ my $uuid_libgit = $build_structure{"LIBS_libgit_GUID"};
+ my $uuid_xdiff_lib = $build_structure{"LIBS_xdiff_lib_GUID"};
foreach (@apps) {
my $appname = $_;
my $uuid = $build_structure{"APPS_${appname}_GUID"};
print F "$SLN_PRE";
- print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"";
+ print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"\n";
+ print F " ProjectSection(ProjectDependencies) = postProject\n";
+ print F " ${uuid_libgit} = ${uuid_libgit}\n";
+ print F " ${uuid_xdiff_lib} = ${uuid_xdiff_lib}\n";
+ print F " EndProjectSection";
print F "$SLN_POST";
}
print F << "EOM";
Global
- GlobalSection(SolutionConfiguration) = preSolution
- ConfigName.0 = Debug|Win32
- ConfigName.1 = Release|Win32
+ GlobalSection(SolutionConfigurationPlatforms) = preSolution
+ Debug|Win32 = Debug|Win32
+ Release|Win32 = Release|Win32
EndGlobalSection
- GlobalSection(ProjectDependencies) = postSolution
EOM
- foreach (@{$build_structure{"APPS"}}) {
- my $appname = $_;
- my $appname_clean = $_;
- $appname_clean =~ s/\//_/g;
- $appname_clean =~ s/\.exe//;
-
- my $uuid = $build_structure{"APPS_${appname_clean}_GUID"};
- my $dep_index = 0;
- foreach(@{$build_structure{"APPS_${appname}_LIBS"}}) {
- my $libname = $_;
- $libname =~ s/\//_/g;
- $libname =~ s/\.(a|lib)//;
- my $libuuid = $build_structure{"LIBS_${libname}_GUID"};
- if (defined $libuuid) {
- print F "\t\t${uuid}.${dep_index} = ${libuuid}\n";
- $dep_index += 1;
- }
- }
- }
-
print F << "EOM";
- EndGlobalSection
- GlobalSection(ProjectConfiguration) = postSolution
+ GlobalSection(ProjectConfigurationPlatforms) = postSolution
EOM
foreach (@libs) {
my $libname = $_;
@@ -630,10 +614,6 @@ EOM
print F << "EOM";
EndGlobalSection
- GlobalSection(ExtensibilityGlobals) = postSolution
- EndGlobalSection
- GlobalSection(ExtensibilityAddIns) = postSolution
- EndGlobalSection
EndGlobal
EOM
close F;
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Sebastian Schuberth @ 2009-09-24 14:40 UTC (permalink / raw)
To: git; +Cc: mstormo
From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Thu, 24 Sep 2009 15:52:25 +0200
Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
In order to be able to open the generated solution file by double-clicking it
in Windows Explorer, all project files need to use DOS line-endings and a
comment about the Visual Studio version needs to be added to the header of the
solution file. This also fixes the icon that is displayed for the solution file
in Windows Explorer.
Note that opening the solution file from a running instance of Visual Studio
already worked before.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..50daa03 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -131,6 +131,7 @@ sub createLibProject {
$includes =~ s/-I//g;
mkdir "$target" || die "Could not create the directory $target for lib project!\n";
open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+ binmode F, ":crlf";
print F << "EOM";
<?xml version="1.0" encoding = "Windows-1252"?>
<VisualStudioProject
@@ -353,6 +354,7 @@ sub createAppProject {
$includes =~ s/-I//g;
mkdir "$target" || die "Could not create the directory $target for lib project!\n";
open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+ binmode F, ":crlf";
print F << "EOM";
<?xml version="1.0" encoding = "Windows-1252"?>
<VisualStudioProject
@@ -537,7 +539,7 @@ sub createGlueProject {
print "Generate solutions file\n";
$rel_dir = "..\\$rel_dir";
$rel_dir =~ s/\//\\/g;
- my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n";
+ my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n# Visual Studio 2008\n";
my $SLN_PRE = "Project(\"{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\") = ";
my $SLN_POST = "\nEndProject\n";
@@ -560,6 +562,7 @@ sub createGlueProject {
@apps = @tmp;
open F, ">git.sln" || die "Could not open git.sln for writing!\n";
+ binmode F, ":crlf";
print F "$SLN_HEAD";
foreach (@libs) {
my $libname = $_;
--
1.6.4.msysgit.0
^ permalink raw reply related
* Re: 'git am' doubt
From: Thiago Farina @ 2009-09-24 14:09 UTC (permalink / raw)
To: David Aguilar; +Cc: Git Mailing List
In-Reply-To: <20090923235433.GB80337@gmail.com>
On Wed, Sep 23, 2009 at 8:54 PM, David Aguilar <davvid@gmail.com> wrote:
> On Wed, Sep 23, 2009 at 07:20:53PM -0300, Thiago Farina wrote:
>> Hi,
>>
>> I'm trying to apply a patch from the mailing list using 'git am'.
>>
>> What I'm doing is:
>>
>> - In gmail:
>> - Save original, then I copied the content to a text editor.
>> - In text editor:
>> - Remove the first empty line.
>> - Save the file in the same directory where I have the git source.
>> - In git directory:
>> - $ git am -s ./filename.mbox
>>
>> Of course I'm doing something wrong here, but I don't know what.
>> The error is:
>> cat: /home/tfarina/git/.git/rebase-apply/next: No such file or directory
>> previous rebase directory /home/tfarina/git/.git/rebase-apply still
>> exists but mbox given.
>
>
> Perhaps you tried this previously and 'git am' failed?
> In which case, run 'git am --abort'.
I didn't try before.
>
>
> Now.. I've _never_ had luck saving patches out of gmail.
> But, I've had good luck with its imap interface.
> I use mutt, save emails to an mbox file, and use 'git am'
> on them. This has worked great for me.
Yeah, I tried with Evolution, and it worked for me, so the problem was
with Gmail.
>
> For sending emails to the list, I use msmtp and a
> ~/.gitconfig setting:
>
>
> [sendemail]
> smtpserver = /usr/bin/msmtp
>
>
> Then it's simply 'git send-email <patch-file>'.
>
>
> Here's a random page explaining how to use mutt with gmail.
> http://shreevatsa.wordpress.com/2007/07/31/using-gmail-with-mutt-the-minimal-way/
>
> I can send you my .muttrc if that helps.
I'm using send-email to send my patches too. If you could, send me
your .muttrc, I will appreciate, may be I can try to use it instead of
Evolution.
Thanks for your help. ;)
^ 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