* Re: New converstion tool: svn2git.py
From: Kevin Menard @ 2008-11-19 19:39 UTC (permalink / raw)
To: Neil Schemenauer; +Cc: git
In-Reply-To: <20081119191320.GA20870@arctrix.com>
Hi Neil,
You may want to look at this Ruby implementation for more ideas:
http://github.com/nirvdrum/svn2git/
I forked it from a project originally by James Coglan, but should be
able to answer most questions about it.
--
Kevin
On Wed, Nov 19, 2008 at 2:13 PM, Neil Schemenauer <nas@arctrix.com> wrote:
> Hi,
>
> I'm working on a tool to do conversions from SVN to git using a SVN
> dump. It's in early development but perhaps some people would be
> interested in it:
>
> http://python.ca/nas/python/svn2git.py
>
> I would like to improve it so that it intelligently converts SVN
> branches and tags into git branches (when possible). The basic idea
> is to map SVN paths into git branches, e.g. trunk -> master,
> branches/foo -> branch-foo, tags/bar -> tags-bar. Next, specific
> SVN dump actions like:
>
> Node-path: branches/foo
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk
>
> need to be detected and the commit needs to performed with the
> correct parent. One complication is that SVN can create a branch or
> tag from anywhere, for example, the action
>
> Node-path: tags/bar
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk/subdir
>
> would create tags/bar based on revision 3 of trunk/subdir. There
> doesn't seem to be a good way to convert that into git. I was
> thinking that the tags-bar branch in that case would have no parent.
> Would git still efficently pack that or would you end up with extra
> blobs?
>
> Neil
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* New converstion tool: svn2git.py
From: Neil Schemenauer @ 2008-11-19 19:13 UTC (permalink / raw)
To: git
Hi,
I'm working on a tool to do conversions from SVN to git using a SVN
dump. It's in early development but perhaps some people would be
interested in it:
http://python.ca/nas/python/svn2git.py
I would like to improve it so that it intelligently converts SVN
branches and tags into git branches (when possible). The basic idea
is to map SVN paths into git branches, e.g. trunk -> master,
branches/foo -> branch-foo, tags/bar -> tags-bar. Next, specific
SVN dump actions like:
Node-path: branches/foo
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 3
Node-copyfrom-path: trunk
need to be detected and the commit needs to performed with the
correct parent. One complication is that SVN can create a branch or
tag from anywhere, for example, the action
Node-path: tags/bar
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 3
Node-copyfrom-path: trunk/subdir
would create tags/bar based on revision 3 of trunk/subdir. There
doesn't seem to be a good way to convert that into git. I was
thinking that the tags-bar branch in that case would have no parent.
Would git still efficently pack that or would you end up with extra
blobs?
Neil
^ permalink raw reply
* fatal: did you run git update-server-info on the server? mv post-update.sample post-update
From: Gary Yang @ 2008-11-19 18:59 UTC (permalink / raw)
To: git
The doc, http://www.kernel.org/pub/software/scm/git/docs/gitcore-tutorial.html, at the the section, "Working with Others" says that
mv post-update.sample post-update under the $GIT_DIR/hooks directory for the public repository. I did that. The file permission is executable.
ls -alF /pub/git/u-boot.git/hooks/post-update
-rwxr-xr-x 1 garyyang6 engr 189 Nov 18 15:54 /pub/git/u-boot.git/hooks/post-update*
But, I got error, "did you run git update-server-info on the server" when I tried to "git pull". Any idea why I got this error?
I did not run post-update at public repository manually. Do I need to run it for the very first time?
At my private repository, I did:
git pull http://git01.my.com /pub/git/u-boot.git HEAD
fatal: http://git01.my.com/info/refs not found: did you run git update-server-info on the server?
Thank you,
Gary
^ permalink raw reply
* Re: [TopGit PATCH] Check for help invocation before setup
From: Petr Baudis @ 2008-11-19 18:39 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20081119183234.GA19781@piper.oerlikon.madduck.net>
On Wed, Nov 19, 2008 at 07:32:34PM +0100, martin f krafft wrote:
> also sprach Petr Baudis <pasky@suse.cz> [2008.11.19.1924 +0100]:
> > > +args_saved="$@"
> > > +while [ -n "$1" ]; do
> > > + case "$1" in
> > > + help|--help|-h)
> > > + shift
> > > + do_help "$1"
> > > + exit 1;;
> > > + esac
> > > + shift
> > > +done
> > > +set -- $args_saved
> > > +unset args_saved
> > >
> > > ## Initial setup
> >
> > Huh, why do you actually need $args_saved at all? :-) This is bound to
> > do horrible things with space-containing arguments etc., I think. You
> > don't need to do the outer shift and then drop $args_saved altogether,
> > no?
>
> I figured I need to restore $@ for others to consume, e.g. when you
> check for -r later.
>
> The challenge is to identify help|--help|-h anywhere on the command
> line. Thus, you need to iterate, or do some weird matching against
> $*.
>
> When you iterate in a for loop, it's not easy to get at the next
> argument, except if you use a state machine. I wanted to avoid that.
Oh, oops - I missed the loop, I should get some lunch. ;-)
Thus, something like this?
check_help() { while [ -n "$1" ]; do ...; shift; done }
check_help "$@"
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: [TopGit PATCH] Check for help invocation before setup
From: martin f krafft @ 2008-11-19 18:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20081119182436.GB10544@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]
also sprach Petr Baudis <pasky@suse.cz> [2008.11.19.1924 +0100]:
> > +args_saved="$@"
> > +while [ -n "$1" ]; do
> > + case "$1" in
> > + help|--help|-h)
> > + shift
> > + do_help "$1"
> > + exit 1;;
> > + esac
> > + shift
> > +done
> > +set -- $args_saved
> > +unset args_saved
> >
> > ## Initial setup
>
> Huh, why do you actually need $args_saved at all? :-) This is bound to
> do horrible things with space-containing arguments etc., I think. You
> don't need to do the outer shift and then drop $args_saved altogether,
> no?
I figured I need to restore $@ for others to consume, e.g. when you
check for -r later.
The challenge is to identify help|--help|-h anywhere on the command
line. Thus, you need to iterate, or do some weird matching against
$*.
When you iterate in a for loop, it's not easy to get at the next
argument, except if you use a state machine. I wanted to avoid that.
But you are right, I am wreaking havoc with space-containing
arguments. I will have to go back and rework this.
I take it you agree with the general principle though?
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"it is easier to be a lover than a husband for the simple reason
that it is more difficult to be witty every day
than to say pretty things from time to time."
-- honoré de balzac
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [TopGit PATCH] Check for help invocation before setup
From: Petr Baudis @ 2008-11-19 18:24 UTC (permalink / raw)
To: martin f. krafft; +Cc: git
In-Reply-To: <1227110623-4474-2-git-send-email-madduck@debian.org>
On Wed, Nov 19, 2008 at 05:03:40PM +0100, martin f. krafft wrote:
> diff --git a/tg.sh b/tg.sh
> index 2961106..40c4ab7 100644
> --- a/tg.sh
> +++ b/tg.sh
> @@ -235,6 +235,20 @@ do_help()
> fi
> }
>
> +## Startup
> +
> +args_saved="$@"
> +while [ -n "$1" ]; do
> + case "$1" in
> + help|--help|-h)
> + shift
> + do_help "$1"
> + exit 1;;
> + esac
> + shift
> +done
> +set -- $args_saved
> +unset args_saved
>
> ## Initial setup
Huh, why do you actually need $args_saved at all? :-) This is bound to
do horrible things with space-containing arguments etc., I think. You
don't need to do the outer shift and then drop $args_saved altogether,
no?
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Cygwin error?
From: nadim khemir @ 2008-11-19 17:57 UTC (permalink / raw)
To: git
Hi, Given:
$ git pull
remote: Counting objects: 46, done.
...
Updating b80286d..a543dae
error: Untracked working tree file 'xxx.txt' would be overwritten by merge.
This is due to a rename of xxx.txt to Xxx.txt. I understand that this is due
to files being just case preserving on Cycwin/Win32.
The only I found was to remove the xxx.txt localy and do a pull. The
interresting thing is that Xxx.txt is no present in my file system. I can
check it out from HEAD though.
What did I missunderstood and do wrong?
Cheers, Nadim.
^ permalink raw reply
* Git.pm
From: nadim khemir @ 2008-11-19 17:56 UTC (permalink / raw)
To: git
Hi, I'm new on this mailing list and quite new to git too. I named on irc that
I develop mainly in Perl (http://search.cpan.org/~nkh/) when I do open
source. I heard that Git.pm needed some love and I can take over its
maintenance if there are things that need to be done.
I need to know:
- what needs to be done
- who was doing maintenanace before
- how do you want to release it (perl modules are best placed on CPAN
(too))
- what (and who) is depending on Git.pm
- what would be expected of me
As you may have seen in another mail, the Perl community is getting
interrested in git.
Cheers, Nadim.
^ permalink raw reply
* git workshop in Sweden/Denmark
From: nadim khemir @ 2008-11-19 17:58 UTC (permalink / raw)
To: git
Hi,
Lund.pm and Data-foreningen are trying to organize a 'git' workshop.
The workshop will consist of a presentation in the morning followed by a lunch
in a local restaurant and a workshop after lunch.
We already have a location where the workshop will take place. Most probably
a Saturday to allow as many people as possible to join us. The location is in
Malmö the biggest town in the south of Sweden and only 30mn by train from
Copenhagen capital of Danmark. We, of course, welcome people from other places
too.
We are already working on securing one or two speakers that will enlighten us.
I would like the git community to help us with:
- has a git workshop already been organized?
is there material that we could get?
any conference organization existing (something like YAPC)?
- what's the interrest? I'm sure I can get 30 ppl to join but if there is
interrest we can organize something bigger.
- Can you be :
- a speaker
- a sponsor
- If you come, what would you like to learn, discuss?
Cheers, Nadim.
PS: there's a lot of interrest for git in the Perl community right now and
rumors has it that Perl itself is going over to git. Next year YAPC in
Portugal would be a great opportunity to present git in depth to perl
developers. If someone is interrested, please let me know.
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Daniel Barkalow @ 2008-11-19 18:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Mark Burton, git
In-Reply-To: <7vd4grsveo.fsf@gitster.siamese.dyndns.org>
On Wed, 19 Nov 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 19 Nov 2008, Mark Burton wrote:
> >
> >> Having said that, I still like the concept of being able to add named
> >> files without touching the index.
> >
> > That's just impossible. You cannot create a tree object, let alone a
> > commit object, without touching the index (AKA staging area).
>
> I do not think Mark really _means_ "not in the index".
>
> The wish is more like "I want to let git know that I am interested in this
> path, but I'm not ready to say what exact content I want for that path in
> the next commit, not just yet".
>
> I do not think that is an unreasonable wish. On the other hand, it is
> unreasonable for anybody to insist that we satisfy the wish without
> touching the index. The index is the most natural place to do that.
I don't think that's what Mark wants, in this case. He's looking for the
ability to have "git commit" act on a temporary index created by adding to
the parent commit explicitly named files which aren't in the non-temporary
index. That is, Mark doesn't want to touch *the* index, which is fine; git
can commit with *an* index.
> We have a half (probably a quarter) of what we need for that implemented
> already, by the way.
I've looked into what you're suggesting on occasion; the main issue is
getting the various index users to avoid getting confused. I was stumped
by the diff code, which was confusing the "intent to add something" token
with its "compare against the work tree" token. I'd say, it's half
implemented, but testing is a major unstarted undertaking.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: Gary Yang @ 2008-11-19 16:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811190740200.18283@nehalem.linux-foundation.org>
The command, "git tag -u garyyang6@yahoo.com tag-name" works! Thank you!
Below is the output of "gpg -k". I have no idea why I have three keys.
gpg -k
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
/home/garyyang6/.gnupg/pubring.gpg
----------------------------------
pub 1024D/A3F6A45E 2008-11-14 Gary Yang (For git.) <garyyang6@yahoo.com>
sub 1024g/58AE6B3C 2008-11-14
pub 1024D/EE763A89 2008-11-14 Gary Yang (PGP for git.) <garyyang6@yahoo.com>
sub 1024g/AECCA323 2008-11-14
pub 1024D/5015631E 2008-11-18 Gary Yang (For git) <garyyang6@yahoo.com>
--- On Wed, 11/19/08, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Subject: Re: "secret key not available". "unable to sign the tag".
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: "Jeff King" <peff@peff.net>, "Git Mailing List" <git@vger.kernel.org>
> Date: Wednesday, November 19, 2008, 7:42 AM
> On Tue, 18 Nov 2008, Gary Yang wrote:
> >
> > The gpg works. But, git tag dose not work. Any idea?
>
> Does
>
> git tag -u garyyang6@yahoo.com tag-name
>
> work (ie when you use an explicitly given key to tag with)?
>
> And if not, please do list the output of "gpg -K"
> if that doesn't work.
>
> Linus
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] compat/mingw.c: Teach mingw_rename() to replace read-only files
From: Johannes Sixt @ 2008-11-19 16:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <49242821.50604@viscovery.net>
From: Johannes Sixt <j6t@kdbg.org>
On POSIX, rename() can replace files that are not writable. On Windows,
however, read-only files cannot be replaced without additional efforts:
We have to make the destination writable first.
Since the situations where the destination is read-only are rare, we do not
make the destination writable on every invocation, but only if the first
try to rename a file failed with an "access denied" error.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Johannes Sixt schrieb:
> Nicolas Pitre schrieb:
>> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>>> The unusual case is where you do this:
>>>
>>> $ git rev-list -10 HEAD | git pack-objects foobar
>>>
>>> twice in a row: In this case the second invocation fails on Windows
>>> because the destination pack file already exists *and* is open. But not
>>> even git-repack does this even if it is called twice. OTOH, the test case
>>> *does* exactly this.
>> OK.... Well, despite my earlier assertion, I think the above should be a
>> valid operation.
Would you please clarify which operation you exactly mean? As is written
above, or with .git/objects/pack/foobar instead like in the test case?
>> I'm looking at it now. I'm therefore revoking my earlier ACK as well
>> (better keep that test case alive).
>
> Hold on a moment: When I tested the above sequence, I was fooled by a flaw
> in mingw_rename() (it doesn't replace read-only files). With that fixed...
Here is this fix.
-- Hannes
compat/mingw.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index b534a8a..3dbe6a7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -819,6 +819,8 @@ int mingw_connect(int sockfd, struct sockaddr *sa, size_t sz)
#undef rename
int mingw_rename(const char *pold, const char *pnew)
{
+ DWORD attrs;
+
/*
* Try native rename() first to get errno right.
* It is based on MoveFile(), which cannot overwrite existing files.
@@ -830,12 +832,19 @@ int mingw_rename(const char *pold, const char *pnew)
if (MoveFileEx(pold, pnew, MOVEFILE_REPLACE_EXISTING))
return 0;
/* TODO: translate more errors */
- if (GetLastError() == ERROR_ACCESS_DENIED) {
- DWORD attrs = GetFileAttributes(pnew);
- if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY)) {
+ if (GetLastError() == ERROR_ACCESS_DENIED &&
+ (attrs = GetFileAttributes(pnew)) != INVALID_FILE_ATTRIBUTES) {
+ if (attrs & FILE_ATTRIBUTE_DIRECTORY) {
errno = EISDIR;
return -1;
}
+ if ((attrs & FILE_ATTRIBUTE_READONLY) &&
+ SetFileAttributes(pnew, attrs & ~FILE_ATTRIBUTE_READONLY)) {
+ if (MoveFileEx(pold, pnew, MOVEFILE_REPLACE_EXISTING))
+ return 0;
+ /* revert file attributes on failure */
+ SetFileAttributes(pnew, attrs);
+ }
}
errno = EACCES;
return -1;
--
1.6.0.4.1694.g07ac
^ permalink raw reply related
* Re: git and mtime
From: Christian MICHON @ 2008-11-19 16:18 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> Would it be possible for git to store the mtime of files in the tree?
>
> This would make it possible to do this type of work in git, since it's
> currently a bit random as to whether it works or not. This only
> started when I upgraded to an amd64 architecture from powerpc32,
> I guess it's maybe using high-resolution timestamps.
>
beside the obvious answer it comes back often as a request, it is
possible in theory to create a shell script which, for each file
present in the sandbox in the current branch, would find the mtime of
the last commit on that file (quite an expensive operation) and apply
it.
I had a need for this once, then lost interest since using git as it
is is so much better than trying to mimic behaviour of old scm tools
and makefiles.
You should store mostly content of source files. You should do a make
in your first cloned repo at least once before committing anything to
the repo. That's what I did and I saved days...
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* [TopGit PATCH] Check for help invocation before setup
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-1-git-send-email-madduck@debian.org>
The user ought to be able to call `tg help` from anywhere in the
filesystem, not just Git repositories, so the help parsing has to happen
before the calls to git git binary.
Debian bug: #501982
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/tg.sh b/tg.sh
index 2961106..40c4ab7 100644
--- a/tg.sh
+++ b/tg.sh
@@ -235,6 +235,20 @@ do_help()
fi
}
+## Startup
+
+args_saved="$@"
+while [ -n "$1" ]; do
+ case "$1" in
+ help|--help|-h)
+ shift
+ do_help "$1"
+ exit 1;;
+ esac
+ shift
+done
+set -- $args_saved
+unset args_saved
## Initial setup
@@ -268,9 +282,6 @@ cmd="$1"
shift
case "$cmd" in
-help|--help|-h)
- do_help "$1"
- exit 1;;
--hooks-path)
# Internal command
echo "@hooksdir@";;
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Check for cmddir earlier
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-3-git-send-email-madduck@debian.org>
Without cmddir, tg is basically useless, even do_help() needs it, so
check it first and die hard if not found
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tg.sh b/tg.sh
index ea22544..f3d1323 100644
--- a/tg.sh
+++ b/tg.sh
@@ -237,6 +237,9 @@ do_help()
## Startup
+[ -d "@cmddir@" ] ||
+ die "No command directory: '@cmddir@'"
+
args_saved="$@"
while [ -n "$1" ]; do
case "$1" in
@@ -263,9 +266,6 @@ tg="tg"
setup_ours
setup_hook "pre-commit"
-[ -d "@cmddir@" ] ||
- die "No command directory: '@cmddir@'"
-
## Dispatch
# We were sourced from another script for our utility functions;
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Print help output when no command is given
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-4-git-send-email-madduck@debian.org>
As much as I love your message (although you really ought not be
throwing around ducks!), this is more user-friendly.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg.sh b/tg.sh
index f3d1323..e0d62e7 100644
--- a/tg.sh
+++ b/tg.sh
@@ -278,7 +278,7 @@ if [ "$1" = "-r" ]; then
fi
cmd="$1"
-[ -n "$cmd" ] || die "He took a duck in the face at two hundred and fifty knots"
+[ -n "$cmd" ] || { do_help; exit 1; }
shift
case "$cmd" in
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Change tg help exit code to 0
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-2-git-send-email-madduck@debian.org>
Printing --help is not an error, but a successful operation, if the help
output could be printed.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg.sh b/tg.sh
index 40c4ab7..ea22544 100644
--- a/tg.sh
+++ b/tg.sh
@@ -243,7 +243,7 @@ while [ -n "$1" ]; do
help|--help|-h)
shift
do_help "$1"
- exit 1;;
+ exit 0;;
esac
shift
done
--
1.6.0.2
^ permalink raw reply related
* [TopGit] Improve help output
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git
The following patches improve the help output by TopGit. They are
not all related, but they conflict.
I would just push them to the master branch, but I don't want to
risk my chances of Petr getting angry with his new release
assistant...
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: Linus Torvalds @ 2008-11-19 15:42 UTC (permalink / raw)
To: Gary Yang; +Cc: Jeff King, Git Mailing List
In-Reply-To: <31942.12221.qm@web37902.mail.mud.yahoo.com>
On Tue, 18 Nov 2008, Gary Yang wrote:
>
> The gpg works. But, git tag dose not work. Any idea?
Does
git tag -u garyyang6@yahoo.com tag-name
work (ie when you use an explicitly given key to tag with)?
And if not, please do list the output of "gpg -K" if that doesn't work.
Linus
^ permalink raw reply
* Re: git and mtime
From: Matthieu Moy @ 2008-11-19 14:54 UTC (permalink / raw)
To: Arafangion; +Cc: Roger Leigh, git
In-Reply-To: <1227098252.11370.8.camel@therock.nsw.bigpond.net.au>
Arafangion <thestar@fussycoder.id.au> writes:
> You should probably fix your build script,
ccache should help:
http://ccache.samba.org/
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 14:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811190940480.27509@xanadu.home>
Nicolas Pitre schrieb:
> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>> The unusual case is where you do this:
>>
>> $ git rev-list -10 HEAD | git pack-objects foobar
>>
>> twice in a row: In this case the second invocation fails on Windows
>> because the destination pack file already exists *and* is open. But not
>> even git-repack does this even if it is called twice. OTOH, the test case
>> *does* exactly this.
>
> OK.... Well, despite my earlier assertion, I think the above should be a
> valid operation.
>
> I'm looking at it now. I'm therefore revoking my earlier ACK as well
> (better keep that test case alive).
Hold on a moment: When I tested the above sequence, I was fooled by a flaw
in mingw_rename() (it doesn't replace read-only files). With that fixed,
it works as expected in repeated invocations (note that foobar is outside
the .git/objects/pack directory).
If I use .git/objects/pack/foobar instead, then I get the failures on
Windows, and I won't argue that this should be "fixed". ;)
-- Hannes
^ permalink raw reply
* Re: git and mtime
From: Arafangion @ 2008-11-19 12:37 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
On Wed, 2008-11-19 at 11:37 +0000, Roger Leigh wrote:
<snip>
> different systems). However, the fact that git isn't storing the
> mtime of the files confuses make, so it then tries to regenerate these
> (already up-to-date) files, and fails in the process since the tools
> aren't available.
Unless I'm mistaken, I was under the impression that the reason why git
doesn't, and shouldn't do this is _because_ it confuses make.
Suppose you've got two branches, and you check out the other branch,
resulting in changes in 3 files. Should git go and modify the mtime for
every single file, and remove any file that isn't part of the repo (Such
as generated object files)?
If it modifies the dates on every file, but doesn't remove the generated
object files, how does make handle that, as it'll likely generate some
of the object files, but not all of them.
If it doesn't, but touches the files that changed, and the dates are now
older than the corresponding object files, make would fail to recompile
the project properly!
The only way this could work is if you never switch branches, which is
quite limiting for git, and never check out an older revision, which is
quite limiting for the RCS systems in general.
You should probably fix your build script, or add a hook script that
sets the dates on the files in question manually, but the former
solution would be much better.
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Nicolas Pitre @ 2008-11-19 14:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <49241AEF.1080808@viscovery.net>
On Wed, 19 Nov 2008, Johannes Sixt wrote:
> Alex Riesen schrieb:
> > 2008/11/19 Nicolas Pitre <nico@cam.org>:
> >> On Wed, 19 Nov 2008, Johannes Sixt wrote:
> >>> The work-around is to write the repacked objects to a file of a different
> >>> name, and replace the original after git-pack-objects has terminated.
> >>>
> >>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> >> Acked-by: Nicolas Pitre <nico@cam.org>
> >
> > Are you sure? Will it work in a real repository? Were noone does
> > rename the previous pack files into packtmp-something?
>
> Oh, the patch only works around the failure in the test case. In a real
> repository there is usually no problem because the destination pack file
> does not exist.
>
> The unusual case is where you do this:
>
> $ git rev-list -10 HEAD | git pack-objects foobar
>
> twice in a row: In this case the second invocation fails on Windows
> because the destination pack file already exists *and* is open. But not
> even git-repack does this even if it is called twice. OTOH, the test case
> *does* exactly this.
OK.... Well, despite my earlier assertion, I think the above should be a
valid operation.
I'm looking at it now. I'm therefore revoking my earlier ACK as well
(better keep that test case alive).
Nicolas
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Mark Burton @ 2008-11-19 14:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vd4grsveo.fsf@gitster.siamese.dyndns.org>
Hi,
> > That's just impossible. You cannot create a tree object, let alone a
> > commit object, without touching the index (AKA staging area).
>
> I do not think Mark really _means_ "not in the index".
>
> The wish is more like "I want to let git know that I am interested in this
> path, but I'm not ready to say what exact content I want for that path in
> the next commit, not just yet".
>
> I do not think that is an unreasonable wish. On the other hand, it is
> unreasonable for anybody to insist that we satisfy the wish without
> touching the index. The index is the most natural place to do that.
>
> We have a half (probably a quarter) of what we need for that implemented
> already, by the way.
Sorry, poor choice of words on my part - you have to remember my
viewpoint is one of user more than developer.
My wish was really just based on the advertised behaviour that
specifying a file on the command line would commit the contents of that
file while leaving the index intact. Whether the index was temporarily
used/altered during the execution of the commit didn't cross my mind.
Hey, it's not a big deal and with the accepted patch to the
documentation it need not take any more of anyone's time.
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Nicolas Pitre @ 2008-11-19 14:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <49240F6D.3030203@viscovery.net>
On Wed, 19 Nov 2008, Johannes Sixt wrote:
> Nicolas Pitre schrieb:
> > On Wed, 19 Nov 2008, Johannes Sixt wrote:
> >
> >> Alex Riesen schrieb:
> >>> The opened packs seem to stay open forever.
> >> In my MinGW port I have the patch below that avoids that t5303 fails
> >> because of a pack file that remains open. (Open files cannot be replaced
> >> on Windows.) I had hoped that your patch would help, but it does not.
> >> Something else still keeps the pack file open. Can anything be done about
> >> that?
> >>
> >> -- Hannes
> >>
> >> From: Johannes Sixt <j6t@kdbg.org>
> >> Date: Mon, 17 Nov 2008 09:25:19 +0100
> >> Subject: [PATCH] t5303: Do not overwrite an existing pack
> >>
> ...
> > Acked-by: Nicolas Pitre <nico@cam.org>
>
> Thanks, but I should have mentioned that at this time this patch was just
> meant for exposition, not inclusion.
Well, I'd include it right away since it is fundamentally the right
thing to do.
> I'd prefer a solution to the problem that the pack file remains open. Do
> you have an idea where git-pack-objects keeps the pack file open, even
> with Alex's two patches applied?
That's not the issue.
The test is using pack-objects to overwrite a pack file, but to do so
pack-objects has to open and read from the pack file about to be
overwritten. This is just wrong even if it happens to work by luck on
Linux.
It is on purpose that the pack files are kept open. This is to minimize
the number of open() and mmap()/read() operations between successive
object reads. Those are not leaked file handles since they get closed
when new packs are opened and the number of concurrent opened packs
reaches a certain limit.
Nicolas
^ 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