* Re: [PATCH] Fix handle leak in sha1_file/unpack_objects if there were damaged object data
From: Nicolas Pitre @ 2008-11-19 12:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190314k92a0acbn3ea820cce2a7a40b@mail.gmail.com>
On Wed, 19 Nov 2008, Alex Riesen wrote:
> 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>
Acked-by: Nicolas Pitre <nico@cam.org>
> ---
> sha1_file.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Nicolas Pitre @ 2008-11-19 12:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190313p643c0cb4vad620ea942aeea93@mail.gmail.com>
On Wed, 19 Nov 2008, Alex Riesen wrote:
> 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...
What is the actual problem? Pack windows are left open on purpose.
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 12:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190413s29644092y86d1c8840e10c28b@mail.gmail.com>
Alex Riesen schrieb:
> 2008/11/19 Johannes Sixt <j.sixt@viscovery.net>:
>> 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?
>>
>
> Do this _and_ the other handle-leak-patch together help?
> (I think the second should)
No, that doesn't help, either. :-(
-- Hannes
^ permalink raw reply
* Re: git and mtime
From: Johannes Schindelin @ 2008-11-19 12:31 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
Hi,
On Wed, 19 Nov 2008, Roger Leigh wrote:
> Would it be possible for git to store the mtime of files in the tree?
No, since this would wreck people's workflows:
- compile in branch "master"
- switch to branch "topic"
- compile
- switch back to branch "master"
Now you _want_ files in "master" that were changed in "topic" to be
recompiled.
This is a quite common case.
However, nothing hinders you having your own ".gitmtimes" in the tree, and
a script people can use as a hook, which applies the mtimes to the files.
Ciao,
Dscho
^ permalink raw reply
* Re: git and mtime
From: Matthias Kestenholz @ 2008-11-19 12:22 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
Hi,
On 19.11.2008, at 12:37, Roger Leigh wrote:
> Hi folks,
>
> I'm using git to store some generated files, as well as their sources.
> (This is in the context of Debian package development, where entire
> upstream release tarballs are injected into an upstream branch, with
> Debian releases merging the upstream branch, and adding the Debian
> packaging files.)
>
> The upstream release tarballs contains files such as
> - yacc/lex code, and the corresponding generated sources
> - Docbook/XML code, and corresponding HTML/PDF documentation
>
> These are provided by upstream so that end users don't need these
> tools
> installed (particularly docbook, since the toolchain is so flaky on
> 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.
>
> Would it be possible for git to store the mtime of files in the tree?
>
This subject comes up from time to time, but the answer always
stays the same: No. The trees are purely defined by their content, and
that's by design.
If you do not want to regenerate files that are already up-to-date,
you need multiple checkouts of the same repository.
Thanks,
Matthias
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-19 12:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <4923FE58.3090503@viscovery.net>
2008/11/19 Johannes Sixt <j.sixt@viscovery.net>:
> 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?
>
Do this _and_ the other handle-leak-patch together help?
(I think the second should)
> From: Johannes Sixt <j6t@kdbg.org>
> Date: Mon, 17 Nov 2008 09:25:19 +0100
BTW, you better report such things. Even though it is typical
for this platform brokenness, leaking open files is never good.
^ permalink raw reply
* git and mtime
From: Roger Leigh @ 2008-11-19 11:37 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]
Hi folks,
I'm using git to store some generated files, as well as their sources.
(This is in the context of Debian package development, where entire
upstream release tarballs are injected into an upstream branch, with
Debian releases merging the upstream branch, and adding the Debian
packaging files.)
The upstream release tarballs contains files such as
- yacc/lex code, and the corresponding generated sources
- Docbook/XML code, and corresponding HTML/PDF documentation
These are provided by upstream so that end users don't need these tools
installed (particularly docbook, since the toolchain is so flaky on
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.
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.
Thanks,
Roger
P.S. The repo I'm working on here is at
git://git.debian.org/git/collab-maint/gutenprint.git
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* 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
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