* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Andreas Ericsson @ 2006-03-02 17:39 UTC (permalink / raw)
To: Alex Riesen; +Cc: Christopher Faylor, git
In-Reply-To: <81b0412b0603020810l57f9ee5p270f9c288770d1a7@mail.gmail.com>
Ye gawds, Alex. If you complained this much to your employer you'd get
to run whatever OS you want.
Alex Riesen wrote:
[ lots of things ]
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Johannes Schindelin @ 2006-03-02 17:33 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060302164405.GB7292@trixie.casa.cgf.cx>
Hi,
On Thu, 2 Mar 2006, Christopher Faylor wrote:
> If anyone has a problem with Cygwin where signals do not seem to be
> working, I'd appreciate a bug report to the Cygwin list. We really do
> expect that things should work and want to fix things if they don't.
I am glad to have you on this list. Thanks for all your efforts.
Ciao,
Dscho
^ permalink raw reply
* Re: windows problems summary
From: Johannes Schindelin @ 2006-03-02 17:33 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0603020833j214556bek887c53a3ef43fd58@mail.gmail.com>
Hi,
On Thu, 2 Mar 2006, Alex Riesen wrote:
> On 3/2/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > 1. opened and mmaped files can't be removed or renamed
> > > (caused workaround with reading index in memory)
> >
> > It was not the locking which caused the workaround. It was the
> > not-working. (I still have to find a Windows machine where git-whatchanged
> > does not segfault without NO_MMAP.)
>
> me too. It crashes everywhere here.
>
> > > 4. non-unix permissions model
> > > (breaks x-attr)
> > > 5. real slow filesystems and caching
> > > (makes everything slow. I noticed I'm trying to avoid git status!).
> > > Caused workaround with manual checkout)
> > > 6. real slow program startup
> > > (makes everything slow, eventually may cause everything being put
> > > in one super-executable, just to avoid spawning new processes,
> > > with all associated problems. Makes scripting harder)
> >
> > Except for (4), these issues should be resolvable by the libifying effort.
> >
>
> How can it help with 5? Less accesses to index?
Exactly.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Prevent --index-info from ignoring -z.
From: Shawn Pearce @ 2006-03-02 17:21 UTC (permalink / raw)
To: git
If git-update-index --index-info -z is used only the first
record given to the process will actually be updated as
the -z option is ignored until after all index records
have been read and processed. This meant that multiple
null terminated records were seen as a single record which
was lacking a trailing LF, however since the first record
ended in a null the C string handling functions ignored the
trailing garbage. So --index-info should be required to be
the last command line option, much as --stdin is required
to be the last command line option. Because --index-info
implies --stdin this isn't an issue as the user shouldn't
be passing --stdin when also passing --index-info.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
update-index.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
base eab8a06b5f0937ead199cbd35950a213486f34eb
last 77565623e6c7a02ead3d080816c761da85421781
diff --git a/update-index.c b/update-index.c
index ce1db38..797245a 100644
--- a/update-index.c
+++ b/update-index.c
@@ -577,9 +577,11 @@ int main(int argc, const char **argv)
break;
}
if (!strcmp(path, "--index-info")) {
+ if (i != argc - 1)
+ die("--index-info must be at the end");
allow_add = allow_replace = allow_remove = 1;
read_index_info(line_termination);
- continue;
+ break;
}
if (!strcmp(path, "--ignore-missing")) {
not_new = 1;
--
1.2.3.g5f0e
^ permalink raw reply related
* Re: [PATCH] Teach git-checkout-index to use file suffixes.
From: Shawn Pearce @ 2006-03-02 17:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqwp6zvg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> However, --stage=all with --suffix would introduce name clashes
> between repeated conflicted merge runs, which requires Porcelain
> to be extra careful. Your last merge run might have involved
> three conflicting stages (leaving a.c~1, a.c~2, and a.c~3 in
> your working tree) and this time it may be "we removed it while
> they modified it" situation (needing to extract a.c~1, a.c~3 but
> not a.c~2). The Porcelain needs to make sure not to get
> confused by leftover a.c~2 file in the working tree from the
> previous run.
Clearly. pg was trying to delete all of those files before doing its
merge work but failed because of the --ignored bug in git-ls-files;
but this is now fixed. Still a possibility for confusion does exist.
But in at least one case my Porcelain is Eclipse and a Cygwin
prompt. In this case I want to view and edit everything in Eclipse.
Having all of the files in the same directory just makes it easier
to view. Random temporary names in the same directory as the tracked
file would be OK except if I had multiple conflicts in the same
directory, in which case I need some easy way to tell them apart.
At which point we're starting to derive off the tracked file name
and might as well always use well-known names.
> If what you are trying is to reduce the number of checkout-index
> calls by your Porcelain to extract conflicted stages, it _might_
> make more sense to do something like this instead (I am thinking
> aloud, so take this with a big grain of salt -- it may not make
> sense at all):
>
> checkout-index --stage=all checks out higher-order stages in
> made-up temporary filenames, just like git-merge-one-file
> does using git-unpack-file one-by-one, with a single
> invocation.
>
> It reports the following to its standard output, one record
> per pathname in the index:
>
> tmp1 <SP> tmp2 <SP> tmp3 <TAB> pathname <RS>
[...]
That's not a bad idea. The only thing I don't like about that
is that git-checkout-index won't build the directory tree for me;
the Porcelain must still be responsible for doing that before it
can rename the temporary files (if available) into the correct
subdirectory.
My plan with git-checkout-index though was originally to just have
it fail if the file already exists, unless -f is given. So if
a left-over foo.c#2 was still on disk and git-checkout-index was
going to write to that name it would fail.
I see a lot of benefit from the checkout to temporary file names
and let the Porcelian rename (if it desires).
So I'm going to ask you to withdraw the --suffix patch from pu.
I'll write up a new patch using the ideas you suggest above and
submit that instead.
--
Shawn.
^ permalink raw reply
* Re: cygwin: push/pull takes very long time
From: Alex Riesen @ 2006-03-02 17:09 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <81b0412b0603020526w7db41994v54a96895c1a6e960@mail.gmail.com>
On 3/2/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> It's still working, half an hour since it was started.
> It can be seen that it is constantly growing and shrinking
> (for about 20k,50k,80k,100k back and forth).
The distribution is (there are some git-commits and gitks
probably, here as git-read-tree?) below. The first number
after program name is lower range limit, the second - upper limit.
The number after them - counter of *alloc calls.
The strange pair 65536:99999 means very big objects, more than 1Mb.
I'll cleanup the profiling code and send it as well soon
(I had to instrument x*alloc).
git-read-tree:16:256 127002
git-rev-list:16:256 44775
git-read-tree:0:16 22577
git-pack-objects:16:256 12495
git-pack-objects:256:4096 12303
git-pack-objects:4096:65536 6929
git-diff-index:16:256 4381
git-http-fetch:16:256 3535
git-diff-index:16:256 2914
git-write-tree:4096:65536 2876
git-http-fetch:0:16 2111
git-fetch-pack:16:256 1646
git-fetch-pack:0:16 1522
git-rev-list:256:4096 1067
:16:256 976
git-read-tree:256:4096 965
git-http-fetch:256:4096 835
:0:16 825
git-ls-files:0:16 791
git-rev-list:0:16 748
git-fetch-pack:256:4096 698
git-upload-pack:16:256 610
git-pack-objects:65536:1048576 594
git-rev-parse:16:256 571
:256:4096 554
git-rev-parse:0:16 492
git-upload-pack:0:16 469
git-upload-pack:256:4096 248
git-cat-file:0:16 243
git-peek-remote:16:256 242
git-merge-base:0:16 229
git-merge-base:16:256 208
git-cat-file:16:256 167
git-rev-parse:256:4096 141
git-rev-parse:16:256 117
git-rev-parse:0:16 116
git-cat-file:256:4096 80
git-pack-objects:0:16 73
git-diff-index:0:16 65
git-merge-base:256:4096 59
git-pack-objects:65536:99999 54
git-current-branch:0:16 48
git-diff-index:0:16 47
git-diff-tree:16:256 42
git-diff-index:256:4096 36
git-unpack-objects:16:256 31
git-diff-tree:16:256 30
git-ls-files:16:256 27
git-update-index:16:256 27
git-diff-index:256:4096 24
git-write-tree:16:256 23
git-cat-file:16:256 22
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Shawn Pearce @ 2006-03-02 16:55 UTC (permalink / raw)
To: git
In-Reply-To: <20060302164405.GB7292@trixie.casa.cgf.cx>
Maybe I missed this but why are people using the native Windows
ActiveState Perl with GIT+Cygwin when Cygwin has a Cygwin-ized Perl
installation available?
I've been using the Cygwin Perl with GIT without any problems
whatsoever. Including the open(I, "-|")... exec(@argv) code that
doesn't work correctly in ActiveState and started this whole thread.
--
Shawn.
^ permalink raw reply
* Re: windows problems summary
From: Shawn Pearce @ 2006-03-02 16:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Christopher Faylor, Git Mailing List
In-Reply-To: <81b0412b0603020735j603b3518ob5e27a02c531093a@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> >
> > Are we *really* contemplating porting git to native Windows?
> >
>
> Actually, I wasn't thinking about that when I was writing that mail,
> but ... why not?
> Cygwin makes syscalls many times slower, git is very slow on
> windows, users (well, I) want it faster, so if the needed api subset
> can be narrowed down to a reasonable amount of work - I think
> I'd give the idea a try.
I'd certainly appreciate faster response times from GIT on Windows.
Hell, I'd port GIT myself and cross my fingers that Junio, et. al.
would be open to accepting the changes into the tree.
But right now I don't really have a Windows development environment
available to me that I can hack on releasable changes from (damn
lawyers and those agreements about things on work computers being
owned by work). If I get time I'll try rebuilding a system at
home that is currently offline due to failed disk as a Windows
development environment.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Christopher Faylor @ 2006-03-02 16:44 UTC (permalink / raw)
To: git
So to summarize:
If anyone has a problem with Cygwin where signals do not seem to be
working, I'd appreciate a bug report to the Cygwin list. We really do
expect that things should work and want to fix things if they don't.
If that isn't possible to use the Cygwin list for some reason, I will
continue to read this mailing list and respond to Cygwin problems but I
would appreciate it if any Cygwin problem report contained details for
reproducing the problem. We usually point people to this page
http://cygwin.com/problems.html when they have problems. The basic take
away from that page is to provide the cygcheck output which shows what
settings have been used for your Cygwin installation. The interesting
stuff in that output is the cygwin mount points, the CYGWIN environment
variable, and version information about the Cygwin DLL.
The Cygwin web site is http://cygwin.com/ and it has a lot of information
about Cygwin. Some of it is undoubtedly out-of-date or unclear but we
do try to improve things if they are brought to our attention.
I don't see any reason to respond to this thread any further but I will
continue to rectify any misstatements that I see being made about
Windows or Cygwin here.
cgf (Cygwin Maintainer)
^ permalink raw reply
* Re: windows problems summary
From: Alex Riesen @ 2006-03-02 16:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0603021636020.30490@wbgn013.biozentrum.uni-wuerzburg.de>
On 3/2/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > 1. opened and mmaped files can't be removed or renamed
> > (caused workaround with reading index in memory)
>
> It was not the locking which caused the workaround. It was the
> not-working. (I still have to find a Windows machine where git-whatchanged
> does not segfault without NO_MMAP.)
me too. It crashes everywhere here.
> > 4. non-unix permissions model
> > (breaks x-attr)
> > 5. real slow filesystems and caching
> > (makes everything slow. I noticed I'm trying to avoid git status!).
> > Caused workaround with manual checkout)
> > 6. real slow program startup
> > (makes everything slow, eventually may cause everything being put
> > in one super-executable, just to avoid spawning new processes,
> > with all associated problems. Makes scripting harder)
>
> Except for (4), these issues should be resolvable by the libifying effort.
>
How can it help with 5? Less accesses to index?
^ permalink raw reply
* Re: windows problems summary
From: Alex Riesen @ 2006-03-02 16:26 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Christopher Faylor, Git Mailing List
In-Reply-To: <440716DB.7080108@op5.se>
On 3/2/06, Andreas Ericsson <ae@op5.se> wrote:
> >>Are we *really* contemplating porting git to native Windows?
> >
> > Actually, I wasn't thinking about that when I was writing that mail,
> > but ... why not?
>
> For the same reason we don't support Perl 5.4. It's too much effort for
> too little gain. OTOH, if you want to do the effort, I won't mind taking
> the gain. ;)
I don't care. I just have nothing for you to gain from yet.
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-03-02 16:20 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060302152219.GG2781@trixie.casa.cgf.cx>
On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> >> The cygwin/windows version of spawn is basically like an extended version
> >> of exec*():
> >>
> >> pid = spawnlp (P_NOWAIT, "/bin/ls", "ls", "-l", NULL);
> >>
> >
> >By the way, is argv worked around?
> >AFAIK, windows has only one argument, returned by GetCommandLine?
>
> Cygwin passes an argv list between cygwin processes and a quoted command
> line to pure windows processes.
What for? They can't use it anyway.
$ notepad '"abc"'
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-03-02 16:11 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne0e36r.fr9.mdw@metalzone.distorted.org.uk>
On 3/2/06, Mark Wooding <mdw@distorted.org.uk> wrote:
>
> > AFAIK, windows has only one argument, returned by GetCommandLine?
>
> This is true, but there's a standard quoting convention which (in
> particular) Microsoft's C library uses to split the single argument back
> into an argv. The spawn* functions quote; the C library startup stuff
> unquotes and splits.
Doesn't for programs using WinMain, which is probably 90% of all
windows programs.
^ permalink raw reply
* [PATCH] manpages: insert two missing [verse] markers for multi-line SYNOPSIS
From: Jonas Fonseca @ 2006-03-02 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Found with:
for i in *.txt; do
grep -A 2 "SYNOPSIS" "$i" | grep -q "^\[verse\]$" && continue
multiline=$(grep -A 3 "SYNOPSIS" "$i" | tail -n 1)
test -n "$multiline" && echo "$i: $multiline"
done
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-repo-config.txt | 1 +
Documentation/git-svnimport.txt | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
c7336e4b19bf7683540ea4d6704c0f522067f2de
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index 33fcde4..00efde5 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -8,6 +8,7 @@ git-repo-config - Get and set options in
SYNOPSIS
--------
+[verse]
'git-repo-config' [type] name [value [value_regex]]
'git-repo-config' [type] --replace-all name [value [value_regex]]
'git-repo-config' [type] --get name [value_regex]
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index 912a808..deee66a 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -9,6 +9,7 @@ git-svnimport - Import a SVN repository
SYNOPSIS
--------
+[verse]
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
--
1.2.3.g858c-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-03-02 16:10 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060302150016.GC2781@trixie.casa.cgf.cx>
On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> >That's not enough.
> >Try interrupting busy processes. Like "git pull", "git clone" or make.
>
> Are you saying that typing CTRL-C doesn't work when you use "git pull"?
It does. Almost always. It's the seldom cases when this does not
really work which annoy me that much.
> If so, give me a real bug report that I can look into. I interrupt
> "busy" processes on cygwin all of the time so I'm not going to spend a
> few hours typing "git pull" on my system only to find out that you are
> talking about an environment that uses ActiveState perl on Windows 95
> using Netware.
well, it is almost exactly the case: WinNT 2K. And I cannot change this.
> If you are reporting a problem you need to provide details.
I am NOT reporting a problem. Everyone knows there are these problems,
it's just almost no one (including me) cares enough about getting anything
to work sanely on windows.
Please, stop assuming that every my complaint is a bug report about
cygwin. It is not. You can use my mails as you please, even as bug reports.
If you ask nicely, I can provide more details maybe. But I am not asking
YOU for anything, and not complaining to YOU about anything.
I _do_not_ like how Cygwin workarounds windows, but I respect the
effort and understand why it happens. Still, I'd prefer it die. I'll try to
keep it moving, but no farther than needed and only when I really have to.
> There are also other mechanisms for a native windows
> program to deal with CTRL-C so this really shouldn't be an issue for
> any well-written program.
In windows you have to do hell of a lot useless typing to write what you
consider a "well-written program".
> >I wont be pressing anyone to implement them in windows, having the
> >knowledge. What I'd actually suggest is to drop their implementation
> >entierly, returning ENOSYS,
>
> You're not being clear again, but if you are actually promoting the
> notion of cygwin not implementing signals then that is a really daft
> idea. Really. Go to the Cygwin web site and look at all of the
> packages which have been ported. Now think about how they would work if
> Cygwin didn't support signals. bash wouldn't work, openssh, X wouldn't
> work.
That's right. They are not _ported_. I'm not interested in xterm which
prints page in a minute.
> >so that programs are not fooled into believing that the system will
> >work as expected. It never will. "Ctrl-C" in windows console is just
> >a shortcut to TerminateProcess, live with that.
>
> Let me say it again since it isn't clear that you are getting it. If
> signals in a pure cygwin environment don't work then that is *a bug*.
Whatever you say. I never expected them to, personally.
> If you are running pure windows programs in the mix with cygwin programs
> then if *they* don't stop when you hit CTRL-C, that is undoubtedly a bug
> in that pure windows program.
Maybe. I wouldn't blame that poor windows programmer though: it's hard,
boring and in 99.9999% of starts of that program - dead code.
> If you find that a pure windows program terminates when run from a
> windows command prompt but keeps running when run by a cygwin program
> then that is likely a cygwin problem that can be reported to the cygwin
> mailing list.
gui applications detach from cmd (not from cygwin console),
so that kind of pointless exercise.
> I'd suggest that using git with native windows programs should probably
> be considered "unsupported" since you seem to be having so much trouble
> with it.
I'd suggest calling cygwin ports unsupported.
> >I cannot use umask, because I have to use stupid windows programs, and
> >they always create "executable" *.c and *.h, and I cannot blindly
> >remove it with something like "chmod -R -x", because it'd remove it
> >also from executables.
>
> find . -name '*.[ch]' | xargs chmod a-x
find . -name '*.[ch]' -o -name '*.[ch]pp' -o -name Makefile -o -name
'*.txt' -o ...ooh! damn it^C -print0| xargs -0 chmod -x
You oversimplifying.
^ permalink raw reply
* Re: windows problems summary
From: Andreas Ericsson @ 2006-03-02 16:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Christopher Faylor, Git Mailing List
In-Reply-To: <81b0412b0603020735j603b3518ob5e27a02c531093a@mail.gmail.com>
Alex Riesen wrote:
> On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
>
>>Are we *really* contemplating porting git to native Windows?
>>
>
>
> Actually, I wasn't thinking about that when I was writing that mail,
> but ... why not?
For the same reason we don't support Perl 5.4. It's too much effort for
too little gain. OTOH, if you want to do the effort, I won't mind taking
the gain. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: windows problems summary
From: Bertrand Jacquin @ 2006-03-02 15:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: Christopher Faylor, Git Mailing List
In-Reply-To: <81b0412b0603020735j603b3518ob5e27a02c531093a@mail.gmail.com>
On 3/2/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> >
> > Are we *really* contemplating porting git to native Windows?
> >
>
> Actually, I wasn't thinking about that when I was writing that mail,
> but ... why not?
> Cygwin makes syscalls many times slower, git is very slow on
> windows, users (well, I) want it faster, so if the needed api subset
> can be narrowed down to a reasonable amount of work - I think
> I'd give the idea a try.
Is the goal to have something like a git-turtoise (as {svn,cvs}-turtoise) ?
I personaly think that is could be benefic.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: Newbie question: git tag failure
From: Jan-Benedict Glaw @ 2006-03-02 15:54 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50603020751v4bb96b75q1686d36b32e2c40f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
On Thu, 2006-03-02 23:51:04 +0800, Aubrey <aubreylee@gmail.com> wrote:
> aubrey@linux:~/local/mygit>git tag -u
> 43368b967bd838292b8cc6b576c5aa13850551cc v2.5
> gpg: directory `/home/aubrey/.gnupg' created
> gpg: new configuration file `/home/aubrey/.gnupg/gpg.conf' created
> gpg: WARNING: options in `/home/aubrey/.gnupg/gpg.conf' are not yet
> active during this run
> gpg: keyring `/home/aubrey/.gnupg/secring.gpg' created
> gpg: keyring `/home/aubrey/.gnupg/pubring.gpg' created
> gpg: skipped "43368b967bd838292b8cc6b576c5aa13850551cc": secret key
> not available
> gpg: signing failed: secret key not available
> failed to sign the tag with GPG.
You seem to not have a working GnuPG installation, inclusing an
(already present) private key. Please first get familiar with GnuPG,
then try to use it :-) "gpg --gen-key" may help.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Newbie question: git tag failure
From: Aubrey @ 2006-03-02 15:51 UTC (permalink / raw)
To: git
There are two commit. I want to tag one commit by commit id, but failed.
Thanks for any hints.
Regards,
-Aubrey
aubrey@linux:~/local/mygit> git log
===============================================================
commit a8ac6540cf96f79225cc8457b02cb90d40ac7991
Author: Aubrey.Li <aubrey@linux.site>
Date: Thu Mar 2 23:34:18 2006 +0800
add commit log
commit 43368b967bd838292b8cc6b576c5aa13850551cc
Author: Aubrey.Li <aubrey@linux.site>
Date: Thu Mar 2 22:24:55 2006 +0800
Initial commit
===============================================================
aubrey@linux:~/local/mygit>git tag -u
43368b967bd838292b8cc6b576c5aa13850551cc v2.5
gpg: directory `/home/aubrey/.gnupg' created
gpg: new configuration file `/home/aubrey/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/aubrey/.gnupg/gpg.conf' are not yet
active during this run
gpg: keyring `/home/aubrey/.gnupg/secring.gpg' created
gpg: keyring `/home/aubrey/.gnupg/pubring.gpg' created
gpg: skipped "43368b967bd838292b8cc6b576c5aa13850551cc": secret key
not available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
^ permalink raw reply
* Re: windows problems summary
From: Johannes Schindelin @ 2006-03-02 15:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0603020649u99a2035i3b8adde8ddce9410@mail.gmail.com>
Hi,
On Thu, 2 Mar 2006, Alex Riesen wrote:
> 1. opened and mmaped files can't be removed or renamed
> (caused workaround with reading index in memory)
It was not the locking which caused the workaround. It was the
not-working. (I still have to find a Windows machine where git-whatchanged
does not segfault without NO_MMAP.)
> 2. command can safely contain only one argument
> (breaks and complicates passing things between processes)
> 3. no fork
> (slows down and complicates passing things between processes)
> 4. non-unix permissions model
> (breaks x-attr)
> 5. real slow filesystems and caching
> (makes everything slow. I noticed I'm trying to avoid git status!).
> Caused workaround with manual checkout)
> 6. real slow program startup
> (makes everything slow, eventually may cause everything being put
> in one super-executable, just to avoid spawning new processes,
> with all associated problems. Makes scripting harder)
Except for (4), these issues should be resolvable by the libifying effort.
Ciao,
Dscho
^ permalink raw reply
* Re: windows problems summary
From: Alex Riesen @ 2006-03-02 15:35 UTC (permalink / raw)
To: Christopher Faylor; +Cc: Git Mailing List
In-Reply-To: <20060302152329.GH2781@trixie.casa.cgf.cx>
On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
>
> Are we *really* contemplating porting git to native Windows?
>
Actually, I wasn't thinking about that when I was writing that mail,
but ... why not?
Cygwin makes syscalls many times slower, git is very slow on
windows, users (well, I) want it faster, so if the needed api subset
can be narrowed down to a reasonable amount of work - I think
I'd give the idea a try.
^ permalink raw reply
* Re: windows problems summary
From: Christopher Faylor @ 2006-03-02 15:23 UTC (permalink / raw)
To: Alex Riesen, Git Mailing List
In-Reply-To: <81b0412b0603020649u99a2035i3b8adde8ddce9410@mail.gmail.com>
On Thu, Mar 02, 2006 at 03:49:24PM +0100, Alex Riesen wrote:
>This is just to summarize all the problems which make porting to that
>thing so boring. Maybe if we have them all on one page, it'd be easier
>to locate the workarounds (it can be one thread, for example).
>
>1. opened and mmaped files can't be removed or renamed
> (caused workaround with reading index in memory)
>2. command can safely contain only one argument
> (breaks and complicates passing things between processes)
>3. no fork
> (slows down and complicates passing things between processes)
>4. non-unix permissions model
> (breaks x-attr)
>5. real slow filesystems and caching
> (makes everything slow. I noticed I'm trying to avoid git status!).
> Caused workaround with manual checkout)
>6. real slow program startup
> (makes everything slow, eventually may cause everything being put
> in one super-executable, just to avoid spawning new processes,
> with all associated problems. Makes scripting harder)
>
>I hope this message can be a start of a big porting thread,
>even though it is only about windows at the moment.
Are we *really* contemplating porting git to native Windows?
I guess I missed that memo.
cgf
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Christopher Faylor @ 2006-03-02 15:22 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0603020618q3b205cdeuabc7e204044cca5b@mail.gmail.com>
On Thu, Mar 02, 2006 at 03:18:44PM +0100, Alex Riesen wrote:
>On 2/26/06, Christopher Faylor <me@cgf.cx> wrote:
>> The cygwin/windows version of spawn is basically like an extended version
>> of exec*():
>>
>> pid = spawnlp (P_NOWAIT, "/bin/ls", "ls", "-l", NULL);
>>
>
>By the way, is argv worked around?
>AFAIK, windows has only one argument, returned by GetCommandLine?
Cygwin passes an argv list between cygwin processes and a quoted command
line to pure windows processes.
cgf
^ permalink raw reply
* Re: git push issue
From: Aubrey @ 2006-03-02 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <6d6a94c50603020246g1520ceahb970da7bbf965dfc@mail.gmail.com>
OK. I help myself out.
It's not complex to put own work on a web server. And it works on my
end. Because git:// or rsync:// need the port which it's possibly
unaccessible behind a firewall. I think it's good enough so far to use
http connection.
Regards,
-Aubrey
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Mark Wooding @ 2006-03-02 15:18 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0603020618q3b205cdeuabc7e204044cca5b@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> wrote:
> AFAIK, windows has only one argument, returned by GetCommandLine?
This is true, but there's a standard quoting convention which (in
particular) Microsoft's C library uses to split the single argument back
into an argv. The spawn* functions quote; the C library startup stuff
unquotes and splits.
The actual quoting convention is /horrible/. I had to implement the
darned thing once. See
http://sources.redhat.com/ml/cygwin/1999-08/msg00701.html
for the details.
-- [mdw]
^ 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