* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 11:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190313p643c0cb4vad620ea942aeea93@mail.gmail.com>
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
This test corrupts a pack file, then repacks the objects. The consequence
is that the repacked pack file has the same name as the original file
(that has been corrupted).
During its operation, git-pack-objects opens the corrupted file and keeps
it open at all times. On Windows, this is a problem because a file that is
open in any process cannot be delete or replaced, but that is what we do
in some of the test cases, and so they fail.
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>
---
t/t5303-pack-corruption-resilience.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t5303-pack-corruption-resilience.sh
b/t/t5303-pack-corruption-resilience.sh
index 5132d41..41c83e3 100755
--- a/t/t5303-pack-corruption-resilience.sh
+++ b/t/t5303-pack-corruption-resilience.sh
@@ -43,8 +43,11 @@ create_new_pack() {
do_repack() {
pack=`printf "$blob_1\n$blob_2\n$blob_3\n" |
- git pack-objects $@ .git/objects/pack/pack` &&
- pack=".git/objects/pack/pack-${pack}"
+ git pack-objects $@ .git/objects/pack/packtmp` &&
+ packtmp=".git/objects/pack/packtmp-${pack}" &&
+ pack=".git/objects/pack/pack-${pack}" &&
+ mv "${packtmp}.pack" "${pack}.pack" &&
+ mv "${packtmp}.idx" "${pack}.idx"
}
do_corrupt_object() {
--
1.6.0.4.1683.g35125
^ permalink raw reply related
* Re: [PATCH] Retain multiple -q/-v occurrences in git pull
From: Constantine Plotnikov @ 2008-11-19 11:46 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git, gitster
In-Reply-To: <1226959770-4252-1-git-send-email-tuncer.ayaz@gmail.com>
On Tue, Nov 18, 2008 at 1:09 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> To support counting -q/-v options in git pull retain
> them by concatenating.
>
[rest of message cut]
By the way, there is yet another way to invoke git fetch. It is "git
remote update". Possibly it should support "-v" and "-q" options for
consistency as well.
Regards,
Constantine
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Johannes Schindelin @ 2008-11-19 11:27 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20081119095452.3018d2de@crow>
Hi,
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).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix t4030-diff-textconv.sh
From: Alex Riesen @ 2008-11-19 11:14 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
Avoid passing cygwin pathnames to Perl. Some Perls have problems using them
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t4030-diff-textconv.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-t4030-diff-textconv.sh.patch --]
[-- Type: text/x-diff; name=0001-Fix-t4030-diff-textconv.sh.patch, Size: 798 bytes --]
From e8562487da0336f0f16832e72264f98879e0394b Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 18 Nov 2008 11:39:46 +0100
Subject: [PATCH] Fix t4030-diff-textconv.sh
Avoid passing cygwin pathnames to Perl. Some Perls have problems using them
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t4030-diff-textconv.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 03ba26a..0b76e7c 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -21,7 +21,7 @@ EOF
cat >hexdump <<'EOF'
#!/bin/sh
-perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' "$1"
+perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' < "$1"
EOF
chmod +x hexdump
--
1.6.0.4.644.gb619a
^ permalink raw reply related
* [PATCH] Fix handle leak in sha1_file/unpack_objects if there were damaged object data
From: Alex Riesen @ 2008-11-19 11:14 UTC (permalink / raw)
To: Nicolas Pitre, Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
In the case of bad packed object CRC, unuse_pack wasn't called after
check_pack_crc which calls use_pack.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
sha1_file.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Fix-handle-leak-in-sha1_file-unpack_objects-if-there.patch --]
[-- Type: text/x-diff; name=0002-Fix-handle-leak-in-sha1_file-unpack_objects-if-there.patch, Size: 846 bytes --]
From 3b4c13ddeebe4bc54a3f9ab9bd26909cc5e1eff3 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 19 Nov 2008 11:17:13 +0100
Subject: [PATCH] Fix handle leak in sha1_file/unpack_objects if there were damaged object data
In the case of bad packed object CRC, unuse_pack wasn't called after
check_pack_crc which calls use_pack.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
sha1_file.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 75a748a..0106e2c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1749,6 +1749,7 @@ void *unpack_entry(struct packed_git *p, off_t obj_offset,
error("bad packed object CRC for %s",
sha1_to_hex(sha1));
mark_bad_packed_object(p, sha1);
+ unuse_pack(&w_curs);
return NULL;
}
}
--
1.6.0.4.644.gb619a
^ permalink raw reply related
* [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-19 11:13 UTC (permalink / raw)
To: Nicolas Pitre, Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
The opened packs seem to stay open forever.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
I'm very unsure about the solution, though: it is really horrible code
to debug...
builtin-pack-objects.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-handle-leak-in-builtin-pack-objects.patch --]
[-- Type: text/x-diff; name=0001-Fix-handle-leak-in-builtin-pack-objects.patch, Size: 827 bytes --]
From d0fbfd05e5c1f41f58281d85d68c705c5f036e7d Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 19 Nov 2008 11:04:48 +0100
Subject: [PATCH] Fix handle leak in builtin-pack-objects
The opened packs seem to stay open forever.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-pack-objects.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 67eefa2..e68e997 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -532,6 +532,7 @@ static void write_pack_file(void)
idx_tmp_name = write_idx_file(NULL, written_list,
nr_written, sha1);
+ release_pack_memory(-1, -1);
snprintf(tmpname, sizeof(tmpname), "%s-%s.pack",
base_name, sha1_to_hex(sha1));
--
1.6.0.4.644.gb619a
^ permalink raw reply related
* Re: Git commit won't add an untracked file given on the command line
From: Mark Burton @ 2008-11-19 9:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811190206170.30769@pacific.mpi-cbg.de>
Hi,
> It may be a traditional wart, but a helpful one. Remember, you can also
> say:
>
> git commit that/directory/
>
> I do _not_ want Git to add all untracked (and unignored) files in that
> directory automatically.
Yes, I can see the wisdom in not automatically adding the contents of a
directory specified on the command line. So that's probably the answer
to my original question.
As for "knowing what the staging area is about", I use the staging
area almost all the time as I consider it one of git's major
improvements over "traditional" SCM systems. I especially like how I
can use tools like git gui to browse and select the changes to be
staged for the next commit.
Having said that, I still like the concept of being able to add named
files without touching the index.
Feature request for the git gui people:
It would be nice if git gui was able to stage a highlighted region
rather than either the whole hunk or just the line under the cursor
as I believe it behaves now. I might be wrong but I don't think it
can do that at the moment. I think that would be useful because
although it's a step forward to be able to stage individual lines in
a hunk, it can be laborious if you want to pick out more than just a
couple of lines.
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH] Fix deletion of last character in levenshtein distance
From: Johannes Schindelin @ 2008-11-19 9:57 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git
In-Reply-To: <2008-11-19-09-42-45+trackit+sam@rfc1149.net>
Hi,
On Wed, 19 Nov 2008, Samuel Tardieu wrote:
> * Johannes Schindelin <Johannes.Schindelin@gmx.de> [2008-11-19 01:53:45 +0100]
>
> | Hi,
> |
> | On Tue, 18 Nov 2008, Samuel Tardieu wrote:
> |
> | > diff --git a/levenshtein.c b/levenshtein.c
> | > index db52f2c..98fea72 100644
> | > --- a/levenshtein.c
> | > +++ b/levenshtein.c
> | > @@ -25,7 +25,7 @@ int levenshtein(const char *string1, const char *string2,
> | > row2[j + 1] > row0[j - 1] + w)
> | > row2[j + 1] = row0[j - 1] + w;
> | > /* deletion */
> | > - if (j + 1 < len2 && row2[j + 1] > row1[j + 1] + d)
> | > + if (row2[j + 1] > row1[j + 1] + d)
> |
> | I do not understand: does row2 have more entries than len2?
>
> Yes it does: int *row2 = xmalloc(sizeof(int) * (len2 + 1));
>
> | In any case, you will _have_ to guard against accessing elements
> | outside the reserved memory.
>
> Why would that be needed? j belongs to [0, len2[, so j+1 is always
> in [0, len2+1[ which is ok for both row2 and row1.
Okay, I understand now, _after_ having looked at the original
levenshtein.c.
IOW you could have made my task of reviewing your patch much easier.
Anyway, here is my
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Thanks for the bugfix,
Dscho
^ permalink raw reply
* git gui: update Italian translation
From: Michele Ballabio @ 2008-11-19 9:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081116215822.GF2932@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
On Sunday 16 November 2008, Shawn O. Pearce wrote:
> git-gui 0.12 will be coming soon. Some new strings have entered
> the project, so I'd like to ask everyone to update their .po with
> new translations. I'm freezing new features, so we can focus on
> translation activity and bug fixing during the git 1.6.1 rc period.
>
> Thanks!
>
Patch attached.
[-- Attachment #2: 0001-git-gui-update-Italian-translation.patch.gz --]
[-- Type: application/x-gzip, Size: 13308 bytes --]
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Johannes Schindelin @ 2008-11-19 9:41 UTC (permalink / raw)
To: Miles Bader; +Cc: Mark Burton, Francis Galiegue, git
In-Reply-To: <buomyfwmldj.fsf@dhapc248.dev.necel.com>
Hi,
On Wed, 19 Nov 2008, Miles Bader wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> I agree, but it would kinda handy to have an exception for files
> >> explicitly named on the command line.
> >
> > Only if you do not have a clear picture of what the staging area is
> > about, IMHO.
>
> That's such a vague statement, I've not sure how to take it.
>
> I use the staging area a lot, so I think I have a pretty clear idea of
> what it's "about", but I also often use "commit FILE" or "commit -a" for
> simple cases; even when splitting a change into multiple commits, it's
> often more convenient to do "commit FILE..." instead of "add FILE;
> commit".
What I meant was this: the "commit <file>" paradigm is not what you should
do most of the time. In order to work with the staging area efficiently,
you should make staging and committing two separate steps.
I regularly encounter people who never call "git diff --cached" before
committing, and guess who introduces all kinds of debug statements and
other cruft into their commits? Exactly.
So my point is this: stage first, verify, then commit. That saves you a
lot of embarrassment.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix deletion of last character in levenshtein distance
From: Samuel Tardieu @ 2008-11-19 8:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811190151000.30769@pacific.mpi-cbg.de>
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [2008-11-19 01:53:45 +0100]
| Hi,
|
| On Tue, 18 Nov 2008, Samuel Tardieu wrote:
|
| > diff --git a/levenshtein.c b/levenshtein.c
| > index db52f2c..98fea72 100644
| > --- a/levenshtein.c
| > +++ b/levenshtein.c
| > @@ -25,7 +25,7 @@ int levenshtein(const char *string1, const char *string2,
| > row2[j + 1] > row0[j - 1] + w)
| > row2[j + 1] = row0[j - 1] + w;
| > /* deletion */
| > - if (j + 1 < len2 && row2[j + 1] > row1[j + 1] + d)
| > + if (row2[j + 1] > row1[j + 1] + d)
|
| I do not understand: does row2 have more entries than len2?
Yes it does: int *row2 = xmalloc(sizeof(int) * (len2 + 1));
| In any case, you will _have_ to guard against accessing elements
| outside the reserved memory.
Why would that be needed? j belongs to [0, len2[, so j+1 is always
in [0, len2+1[ which is ok for both row2 and row1.
^ permalink raw reply
* Re: removing svn remotes
From: Björn Steinbrink @ 2008-11-19 8:32 UTC (permalink / raw)
To: Matt Graham; +Cc: git
In-Reply-To: <1c5969370811181747i240ed22bk73ca62e09b3d0172@mail.gmail.com>
On 2008.11.18 20:47:24 -0500, Matt Graham wrote:
> Hi,
> I have a svn repo cloned into a git repo. There are several remote
> refs that are there that I don't care about and don't want to fetch.
>
> git svn fetch --fetch-all gets a bunch of stuff from branches I don't want
> git svn fetch requires I checkout the branches I care about before fetching
>
> git svn fetch doesn't accept a branch name
> git remote rm isn't able to see the svn remotes
>
> Is there a way to either:
> 1) get rid of the svn remotes that I don't want?
> 2) fetch only the remotes that I do want?
Uhm, are you talking about remote tracking branches (what "git branch
-r" shows), or svn-remotes (not sure if git-svn can list them, they're
in .git/config)?
The behaviour you describe doesn't match my experience with git-svn, so
maybe you could elaborate a bit on the exact problem?
Thanks,
Björn
^ permalink raw reply
* Re: git rev-list ordering
From: Björn Steinbrink @ 2008-11-19 8:26 UTC (permalink / raw)
To: Pete Harlan; +Cc: Johannes Schindelin, Ian Hilt, sverre, Git Mailing List
In-Reply-To: <4923256B.3000807@pcharlan.com>
On 2008.11.18 12:28:27 -0800, Pete Harlan wrote:
> I have a script that runs periodically where I need to know the email
> address of who added $file to the system, for a handful of $files,
> because I'm moving them somewhere else and want to let them know. The
> most recent commits aren't interesting, it's the first commit that matters.
>
> I use:
>
> git rev-list --reverse --pretty=format:%ae HEAD -- $file
>
> and the second line has the information I need.
>
> Perhaps there's a more straightforward way to answer the question "who
> first put this file here".
>
> (One can imagine that may be no "first", because $file merged from
> different paths, but in mine as in many real-world cases, it (a) won't
> happen and (b) whatever happens will be fine if it does.)
>
> I don't need this to work differently than it does, but perhaps it
> constitutes an "interesting situation where you need to list the oldest
> n commits"?
What you're asking for are commits that added the file, and you can tell
git to find them, instead of using the --reverse work-around:
git log --diff-filter=A --pretty=format:%ae HEAD -- $file
If you're running that with a single file, you might want to add
--follow and maybe add R to the diff-filter as well (to get the renaming
commits).
Björn
^ permalink raw reply
* Re: [RFC] On how to manage tags fetched from remote?
From: Kalle Olavi Niemitalo @ 2008-11-19 7:50 UTC (permalink / raw)
To: git
In-Reply-To: <91b13c310811181827y4e37815egaa34ba164d9f4269@mail.gmail.com>
"rae l" <crquan@gmail.com> writes:
> 2. Store a no-tags config item to the remote config, which like:
> [remote "linux-iscsi"]
> url = git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
> fetch = +refs/heads/*:refs/remotes/linux-iscsi/*
> fetch-tags = false
> when git fetch read the no-tags config, it will disable tags from this remote;
A config option like that already exists. I am using:
[remote "git.debian.org"]
url = git://git.debian.org/git/collab-maint/elinks.git
fetch = +refs/heads/*:refs/remotes/git.debian.org/*
fetch = refs/tags/*:refs/tags/git.debian.org/*
tagopt = --no-tags
So I have e.g. a ref called refs/tags/git.debian.org/orig-0.11.4
that points to a tag object that says "tag orig-0.11.4". I hope
git fsck will never be changed to complain about that.
^ permalink raw reply
* Re: [RFC] On how to manage tags fetched from remote?
From: rae l @ 2008-11-19 4:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzljwsads.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 19, 2008 at 10:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Slurping very many (possibly unrelated) projects into one repository is
No. They are all kernel development related. You know the linux kernel
has many subsystem,
from http://git.kernel.org/, hundreds of repos, most are kernel
development related.
Every subsystem has a single maintainer git repository, with linus's
git repos is the center,
So if one want to track the kernel development, he needs to track many repo.
The kernel is in developing at a very high speed, so always complex
and different than other projbects.
> your choice (I wouldn't comment if it is a sane choice -- I do not have
> time to ponder the pros and cons. If it suits your needs, that's good
> enough) If you do not want tags from some repositories but do want from
> some others copied to that repository, per remote configuration feature is
> exactly how it was designed to be used.
I think this is a good idea for me and I will implement it. Thanks for review.
--
Cheng Renquan, Shenzhen, China
Lily Tomlin - "The trouble with the rat race is that even if you win,
you're still a rat."
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Miles Bader @ 2008-11-19 3:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Burton, Francis Galiegue, git
In-Reply-To: <alpine.DEB.1.00.0811190238360.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I agree, but it would kinda handy to have an exception for files
>> explicitly named on the command line.
>
> Only if you do not have a clear picture of what the staging area is about,
> IMHO.
That's such a vague statement, I've not sure how to take it.
I use the staging area a lot, so I think I have a pretty clear idea of what
it's "about", but I also often use "commit FILE" or "commit -a" for simple
cases; even when splitting a change into multiple commits, it's often more
convenient to do "commit FILE..." instead of "add FILE; commit".
I agree that having "commit DIR" add new files would likely be more
annoying than helpful (it's not uncommon to have some temporary files
laying around), but given that "commit FILE" is _explicitly_ naming the new
file, it seems hard to imagine somebody would be surprised if it worked
even when FILE was a new file...
-Miles
--
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.
^ permalink raw reply
* Re: [RFC] On how to manage tags fetched from remote?
From: Junio C Hamano @ 2008-11-19 2:43 UTC (permalink / raw)
To: rae l; +Cc: Junio C Hamano, git
In-Reply-To: <91b13c310811181827y4e37815egaa34ba164d9f4269@mail.gmail.com>
"rae l" <crquan@gmail.com> writes:
> I use one git working tree to track many remote git repository:
> ...
> 2. Store a no-tags config item to the remote config, which like:
> [remote "linux-iscsi"]
> url = git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
> fetch = +refs/heads/*:refs/remotes/linux-iscsi/*
> fetch-tags = false
> when git fetch read the no-tags config, it will disable tags from this remote;
Slurping very many (possibly unrelated) projects into one repository is
your choice (I wouldn't comment if it is a sane choice -- I do not have
time to ponder the pros and cons. If it suits your needs, that's good
enough) If you do not want tags from some repositories but do want from
some others copied to that repository, per remote configuration feature is
exactly how it was designed to be used.
^ permalink raw reply
* [RFC] On how to manage tags fetched from remote?
From: rae l @ 2008-11-19 2:27 UTC (permalink / raw)
To: Junio C Hamano, git
The application field:
I use one git working tree to track many remote git repository:
$ git remote -v
227-archives ssh://192.168.3.227/vmos/linux-with-dm-patches.git
block git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
btrfs git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git
cryptodev git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
djbw-md git://git.kernel.org/pub/scm/linux/kernel/git/djbw/md.git
dk-block git://git.kernel.dk/linux-2.6-block
fastboot git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
gfs2-2.6-nmw git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw.git
linux-2.6-stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
linux-2.6-target git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-target.git
linux-iscsi git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
linux-mm-trees git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
linux-nfs-server git://git.linux-nfs.org/projects/bfields/linux.git
lio-core-2.6 git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core-2.6.git
ocfs2 git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git
origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
rostedt-rt git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-rt.git
staging git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tj-misc git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git
tytso-ext4 git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
utrace git://git.kernel.org/pub/scm/linux/kernel/git/frob/utrace.git
v16.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
v21.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.21.y.git
v22.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git
v23.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git
v24.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.24.y.git
v25.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git
v26.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.26.y.git
v27.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.27.y.git
xfs git://oss.sgi.com:8090/xfs/xfs-2.6.git
Among them only 227-archives is where I will push to, others are all fetch only,
When I want to update, I just issue a "git remote -v update" command,
I'd like tags from origin, and from the stable kernel team, those tags
are all named well,
like v2.6.27, v2.6.27.1, v2.6.28-rc1, ...
But some tags from some other developeres are named bad, some tags named origin,
or named block, which will be ambigous when I want to refer a local remote name.
Asking every developer to delete their ambigous tag name is very troublesome!
The problem is because tags have no namespace, not similar to remote
branches have
namespaces which I named for the remote. Like this command: "git branch -a":
master
my-test
block/bfq
block/blktrace
block/cmdfilter
block/dynpipe
block/fcache
block/for-linus
djbw-md/for-neil
...
The local branch have no namespace, while remote branches all have
their remote name first.
One solution to avoid the ambigous names is that give tags namespaces,
too; But then a tag
will not be a simple tag anymore;
Another approach is not fetching tags from remotes which have ambigous
tag names; the current
git implementation will need I run "git fetch -n <remote>" many times,
I cannot use just one
"git remote -v update";
To achieve one "git remote -v update", there are two approaches, too:
1. Bypassing any switches or other arguments after "git remote udpate"
directly to git fetch,
then "git remote update -n" will call "git fetch -n";
But this will disable all tags in all remotes;
2. Store a no-tags config item to the remote config, which like:
[remote "linux-iscsi"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
fetch = +refs/heads/*:refs/remotes/linux-iscsi/*
fetch-tags = false
when git fetch read the no-tags config, it will disable tags from this remote;
I think the last approach is the best, and most feasible;
However, please comment. Thanks.
--
Cheng Renquan, Shenzhen, China
Steven Wright - "Cross country skiing is great if you live in a small country."
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: Gary Yang @ 2008-11-19 2:19 UTC (permalink / raw)
To: Pete Harlan; +Cc: git
In-Reply-To: <49236F67.6080807@pcharlan.com>
FYI,
Pete helped me solved the problem. Somehow I got two gpg keys. Pete discovered that and suggested me the proper command to tag the code. I am going to figure out how to remove the extra key. Many thanks to Pete.
git tag -u 'For git' -s some-tag
Sincerely,
Gary
--- On Tue, 11/18/08, Pete Harlan <pgit@pcharlan.com> wrote:
> From: Pete Harlan <pgit@pcharlan.com>
> Subject: Re: "secret key not available". "unable to sign the tag".
> To: garyyang6@yahoo.com
> Date: Tuesday, November 18, 2008, 5:44 PM
> Hi Gary,
>
> No output doesn't mean anything is wrong, just that my
> suggestion wasn't
> useful.
>
> I saw from your other post that you use C-shell. I tried
> things here
> using C-shell and it all worked as expected.
>
> One odd-looking thing is that when you show it working from
> the
> command-line it says:
>
> > > > You need a passphrase to unlock the secret
> key for
> > > > user: "Gary Yang (For git.)
> > > > <garyyang6@yahoo.com>"
>
> whereas when you show it not working within Git it says:
>
> > gpg: skipped `Gary Yang
> > <garyyang6@yahoo.com>': secret key not
> > available
> > gpg: signing failed: secret key not available
>
> which leads me to believe that you have two similarly-named
> keys, and
> that the command-line gpg is finding the one that has
> "For git" in the
> name, but git is finding the one that doesn't, and this
> second one
> doesn't have a secret key available.
>
> If you try specifying the first key to git:
>
> git tag -u 'For git' -s some-tag
>
> does that work?
>
> --Pete
>
>
> Gary Yang wrote:
> > Hi Pete,
> >
> > I got no output of the commands you told me. That
> means I have no environment setup. Can you please tell me
> what kind of environment variables need to setup? Thank you
> very much!
> >
> >> env | grep -i gnupg
> >> env | grep -i gpg
> >> env | grep -i pgp
> >
> >
> > Gary
> >
> > --- On Tue, 11/18/08, Pete Harlan
> <pgit@pcharlan.com> wrote:
> >
> >> From: Pete Harlan <pgit@pcharlan.com>
> >> Subject: Re: "secret key not available".
> "unable to sign the tag".
> >> To: garyyang6@yahoo.com
> >> Date: Tuesday, November 18, 2008, 5:16 PM
> >> Gary Yang wrote:
> >>> Hi Pete,
> >>>
> >>> What I should export? Do you have any idea?
> >> Hi Gary,
> >>
> >> I'd look for anything that says gnupg or gpg
> in the
> >> environment.
> >>
> >> env | grep -i gnupg
> >> env | grep -i gpg
> >> env | grep -i pgp
> >>
> >> I'm afriad it's not much of an idea. If
> the above
> >> don't match
> >> anything, I don't know what to suggest.
> >>
> >> Good luck,
> >>
> >> --Pete
> >>
> >>
> >>
> >>>
> >>> Thank you,
> >>>
> >>>
> >>> Gary
> >>>
> >>>
> >>>
> >>>
> >>> --- On Tue, 11/18/08, Pete Harlan
> >> <pgit@pcharlan.com> wrote:
> >>>> From: Pete Harlan
> <pgit@pcharlan.com>
> >> Subject: Re: "secret key not
> >>>> available". "unable to sign the
> >> tag". To: garyyang6@yahoo.com Date:
> >>>> Tuesday, November 18, 2008, 2:18 PM Gary
> Yang
> >> wrote:
> >>>>> Peter,
> >>>>>
> >>>>> The gpg works. But, git tag dose not
> work. Any
> >> idea?
> >>>> Could gpg be using something from your
> environment
> >> that you're not
> >>>> exporting, so git can't see it?
> >>>>
> >>>> --Pete
> >>>>
> >>>>
> >>>>> gpg --detach-sign foo.bar gpg:
> WARNING: using
> >> insecure memory!
> >>>>> gpg: please see
> http://www.gnupg.org/faq.html
> >> for more
> >>>> information
> >>>>> You need a passphrase to unlock the
> secret key
> >> for user: "Gary
> >>>>> Yang (For git.)
> >>>> <garyyang6@yahoo.com>"
> >>>>> 1024-bit DSA key, ID A3F6A45E, created
> >> 2008-11-14
> >>>>> Enter passphrase:
> >>>>>
> >>>>>
> >>>>> [garyyang6@svdclc313
> ~/git-repository]%
> >>>>>
> >>>>>
> >>>>> It successfully signed.
> >>>>>
> >>>>>
> >>>>> Gary
> >>>>>
> >
> >
> >
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Junio C Hamano @ 2008-11-19 2:18 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git, Shawn O. Pearce
In-Reply-To: <7vk5b0vp19.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> On Wed, Oct 01, 2008 at 11:04:05AM +0700, Nguyễn Thái Ngọc Duy wrote:
>>
>>> +test_expect_success 'setup' '
>>> + mkdir sub &&
>>> + touch 1 2 sub/1 sub/2 &&
>>> + git add 1 2 sub/1 sub/2
>>
>> Mind-boggling, but this manages to break on Solaris. Fix is
>> below.
>
> I tend to avoid "touch", not specifically for this reason, but surely this
> is another reason why ">sub/1" is much better way to create a throw-away
> file ;-)
>
>> Note that this has implications for 'touch "$FOO" "$BAR"'
>> used in scripts if FOO might be entirely numeric. However, a
>> quick grep shows we usually touch one file at a time.
>
> You can always do:
>
> : >>"$FOO"
Having said all that, I wouldn't suggest redoing the patch using >>
redirection. But change from "touch 1 nondigit" to "touch nondigit 1"
is a bit too subtle to my taste. Let's write it this way instead:
diff --git a/t/t2104-update-index-no-checkout.sh b/t/t2104-update-index-no-checkout.sh
index be9f913..37a6861 100755
--- a/t/t2104-update-index-no-checkout.sh
+++ b/t/t2104-update-index-no-checkout.sh
@@ -9,7 +9,7 @@ test_description='git update-index no-checkout bits (a.k.a sparse checkout)'
test_expect_success 'setup' '
mkdir sub &&
- touch 1 2 sub/1 sub/2 &&
+ touch ./1 ./2 sub/1 sub/2 &&
git add 1 2 sub/1 sub/2
'
^ permalink raw reply related
* Re: [PATCH] Retain multiple -q/-v occurrences in git pull
From: Junio C Hamano @ 2008-11-19 1:53 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <1226959770-4252-1-git-send-email-tuncer.ayaz@gmail.com>
Thanks, queued.
^ permalink raw reply
* Re: [PATCH] Documentation: rev-list-options.txt: added --branches, --tags & --remotes.
From: Junio C Hamano @ 2008-11-19 1:53 UTC (permalink / raw)
To: Mark Burton; +Cc: git mailing list
In-Reply-To: <20081117210359.316adf11@crow>
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] git-remote: add verbose mode to git remote update
From: Junio C Hamano @ 2008-11-19 1:53 UTC (permalink / raw)
To: crquan; +Cc: git
In-Reply-To: <1227006242-21290-1-git-send-email-crquan@gmail.com>
crquan@gmail.com writes:
> From: Cheng Renquan <crquan@gmail.com>
>
> Pass the verbose mode parameter to the underlying fetch command.
>
> $ ./git remote -v update
> Updating origin
> From git://git.kernel.org/pub/scm/git/git
> ...
> Signed-off-by: Cheng Renquan <crquan@gmail.com>
> ---
> So now the patch looks very simple.
Indeed it does ;-), but there still is a minor nit.
> + "git remote update [-v | --verbose] [group]",
Notice the difference between the example in your commit log message and
the help text?
I think "git remote [options] [cmd] [more options]" which is the current
option parser seems to try doing is very misguided, and a longer term
fix-up might be to redo the cmd_remote() option parser, but in the short
term, let's apply your patch with the following minor fixup:
diff --git c/builtin-remote.c w/builtin-remote.c
index 0af742b..abc8dd8 100644
--- c/builtin-remote.c
+++ w/builtin-remote.c
@@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
"git remote rm <name>",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote update [-v | --verbose] [group]",
+ "git remote [-v | --verbose] update [group]",
NULL
};
^ permalink raw reply related
* Re: Git commit won't add an untracked file given on the command line
From: Junio C Hamano @ 2008-11-19 1:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Burton, Francis Galiegue, git
In-Reply-To: <alpine.DEB.1.00.0811190206170.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It may be a traditional wart, but a helpful one. Remember, you can also
> say:
>
> git commit that/directory/
>
> I do _not_ want Git to add all untracked (and unignored) files in that
> directory automatically.
Yes, very much so.
Although it is conceivable that we may want to change that to behave more
like "git add that/directory && git commit that/directory", that is a
rather large UI semantics change (even if it could be a useful one) that
needs to wait for a major version bump, perhaps in 1.7.0.
I think Mark's update to the documentation is a good thing to have in any
case, so I've applied it.
^ permalink raw reply
* removing svn remotes
From: Matt Graham @ 2008-11-19 1:47 UTC (permalink / raw)
To: git
Hi,
I have a svn repo cloned into a git repo. There are several remote
refs that are there that I don't care about and don't want to fetch.
git svn fetch --fetch-all gets a bunch of stuff from branches I don't want
git svn fetch requires I checkout the branches I care about before fetching
git svn fetch doesn't accept a branch name
git remote rm isn't able to see the svn remotes
Is there a way to either:
1) get rid of the svn remotes that I don't want?
2) fetch only the remotes that I do want?
Thanks!
^ 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