* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Andy Parkins @ 2007-05-14 22:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <7v646vo3pn.fsf@assigned-by-dhcp.cox.net>
On Monday 2007, May 14, Junio C Hamano wrote:
> My take when I did the $ident$ stuff on this issue was quite the
> opposite. CVS "$Id$" means quite a different thing (pathname,
You're right, but I think it's intended as a unique identifier rather
than that specific information. If that were wanted by a CVS/SVN user
they would have used $Author$, $Rev$, $Date$, etc. $Id$ to me was just
some way of identifying the file its in uniquely - the fact that git
has a much better way of doing that is a bonus, and is exactly right
for $Id$ IMHO.
> per-file revision number, date, and status) and it would not be
> right to overwrite it with $ident$ which does not record any of
> those "context sensitive" information.
It would be perfectly correct to overwrite it, as in the repository
version none of that information is present, and even if it wasn't, as
we've discussed at length, it's all meaningless in a git context
anyway - the best thing that you could do for it _is_ overwrite it.
> I did not think other systems making that mistake was not an
> excuse for us to do so, but on the other hand, if the users of
> those other systems are happy to lose the information from CVS
> then perhaps the users do want $Id$.
As I said, there is no information in that field when we import from
CVS/SVN - the repository versions are stored with the fields
collapsed - so you are not overwriting anything, and therefore not
losing information.
> Obviously I do not care much about this feature and I have not
> look at Andy's patch too deeply yet, but in any case I think the
> inverse conversion needs to be modified to match it, if it
> hasn't been done so.
I believe I did the inverse conversion as well. It's only rough, in the
end I don't care much either way - I've already converted everything of
mine to git so it affects me not at all. I offer it only as a
suggestion for imports from other repositories.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH 06/10] user-manual: move howto/make-dist.txt into user manual
From: J. Bruce Fields @ 2007-05-14 21:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.98.0705141043080.6739@woody.linux-foundation.org>
On Mon, May 14, 2007 at 10:44:26AM -0700, Linus Torvalds wrote:
> Actually, these days it looks more like
>
> #!/bin/sh
> stable="$1"
> last="$2"
> new="$3"
> echo "# git tag v$new"
> echo "git archive --prefix=linux-$new/ v$new | gzip -9 > ../linux-$new.tar.gz"
> echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz"
> echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new"
> echo "git shortlog --no-merges v$new ^v$last > ../ShortLog"
> echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
>
> ie I'm using more modern versions of the git tools ;)
Oh, good. I'll update that.
--b.
^ permalink raw reply
* Re: [PATCH] user-manual: fix branch names in examples
From: J. Bruce Fields @ 2007-05-14 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Frank Lichtenheld, git
In-Reply-To: <7viravm6s7.fsf@assigned-by-dhcp.cox.net>
On Mon, May 14, 2007 at 02:31:20PM -0700, Junio C Hamano wrote:
> Thanks everybody for participating in these fixups.
>
> Bruce, how heavy is your workload these days?
Probably lighter than yours.
> Would you mind if I ask you to collect the list comments, have me wait
> for a few days until the discussions and updates settle down and give
> me "Ok, all ready to be pulled" after that?
Yep, that should be no problem.
--b.
^ permalink raw reply
* Re: [PATCH] user-manual: fix branch names in examples
From: Junio C Hamano @ 2007-05-14 21:31 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Frank Lichtenheld, git
In-Reply-To: <20070514160507.GB20736@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> Thanks to Frank Lichtenheld for pointing out inconsistent use of branch
> names in a couple examples.
>
> Add a little more example output while I'm at it.
> ...
Thanks everybody for participating in these fixups.
Bruce, how heavy is your workload these days? Would you mind if
I ask you to collect the list comments, have me wait for a few
days until the discussions and updates settle down and give me
"Ok, all ready to be pulled" after that?
^ permalink raw reply
* Re: [PATCH] cvsserver: Don't send mixed messages to clients
From: Junio C Hamano @ 2007-05-14 21:28 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Martin Langhoff, git
In-Reply-To: <20070514131528.GC5272@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> After looking through all the uses of
> die "something"
> and
> print "E something";
> exit;
> and
> print "error 1 something";
> exit;
>
> in the current code I fail to see a real pattern there, is there any?
> If yes, we should maybe document it in a comment somewhere...
>
> For the record, cvs (server side) does the following in this particular situation:
> buf_output0 (buf_to_net, "I HATE YOU\n");
> buf_flush (buf_to_net, true);
>
> /* Don't worry about server_cleanup, server_active isn't set
> yet. */
> exit (EXIT_FAILURE);
Ok, I stand corrected. If there is a pattern to emulate, that
should be found in the real cvs server.
^ permalink raw reply
* [PATCH] Fix git-clone buglet for remote case.
From: Junio C Hamano @ 2007-05-14 21:25 UTC (permalink / raw)
To: Tero Roponen; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705141836350.26948@jalava.cc.jyu.fi>
c2f599e09fd0496413d1744b5b89b9b5c223555d introduced a buglet while
cloning from a remote URL; we forgot to squelch the unnecessary
error message when we try to cd to the given "remote" name,
in order to see if it is a local directory.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Tero Roponen <teanropo@jyu.fi> writes:
> the latest git seems to output a warning every time I
> try to clone a repository that is not local:
>
> $ git --version
> git version 1.5.2.rc3.27.g43d151
>
> $ git clone git://git.kernel.org/pub/scm/git/git.git
> /usr/local/bin/git-clone: line 23: cd: git://git.kernel.org/pub/scm/git/git.git: No such file or directory
Yup, thankfully that is harmless but it is ugly and wrong
nevertheless. Thanks for the report.
git-clone.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 70374aa..fdd354f 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -22,10 +22,10 @@ get_repo_base() {
cd "`/bin/pwd`" &&
cd "$1" &&
{
- cd .git 2>/dev/null
+ cd .git
pwd
}
- )
+ ) 2>/dev/null
}
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
--
1.5.2.rc3.27.g43d151
^ permalink raw reply related
* [PATCH] Set required execution enviroment
From: Robin Rosenberg @ 2007-05-14 20:56 UTC (permalink / raw)
To: git; +Cc: Robin Rosenberg
In-Reply-To: <11791001343234-git-send-email-robin.rosenberg@dewire.com>
This is required to be able to export the plugin to jar
files, at least using Eclipse 3.3 M7, otherwise the compiler
assumes 1.4 syntax and compilation fails.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
org.spearce.egit.core.test/META-INF/MANIFEST.MF | 1 +
org.spearce.egit.core/META-INF/MANIFEST.MF | 1 +
org.spearce.egit.ui/META-INF/MANIFEST.MF | 1 +
org.spearce.jgit/META-INF/MANIFEST.MF | 1 +
4 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/org.spearce.egit.core.test/META-INF/MANIFEST.MF b/org.spearce.egit.core.test/META-INF/MANIFEST.MF
index e553c1e..b0f365d 100644
--- a/org.spearce.egit.core.test/META-INF/MANIFEST.MF
+++ b/org.spearce.egit.core.test/META-INF/MANIFEST.MF
@@ -17,3 +17,4 @@ Import-Package: org.eclipse.core.resources,
org.eclipse.jdt.junit,
org.eclipse.jdt.launching
Export-Package: org.spearce.egit.core.internal.mapping
+Bundle-RequiredExecutionEnvironment: J2SE-1.5
diff --git a/org.spearce.egit.core/META-INF/MANIFEST.MF b/org.spearce.egit.core/META-INF/MANIFEST.MF
index e3cfc13..384b87e 100644
--- a/org.spearce.egit.core/META-INF/MANIFEST.MF
+++ b/org.spearce.egit.core/META-INF/MANIFEST.MF
@@ -17,3 +17,4 @@ Export-Package: org.spearce.egit.core.internal.mapping;x-friends:="org.spearce.e
org.spearce.egit.core.op,
org.spearce.egit.core.project
Eclipse-LazyStart: true
+Bundle-RequiredExecutionEnvironment: J2SE-1.5
diff --git a/org.spearce.egit.ui/META-INF/MANIFEST.MF b/org.spearce.egit.ui/META-INF/MANIFEST.MF
index 9857e3f..e1dcc12 100644
--- a/org.spearce.egit.ui/META-INF/MANIFEST.MF
+++ b/org.spearce.egit.ui/META-INF/MANIFEST.MF
@@ -19,3 +19,4 @@ Require-Bundle: org.eclipse.core.runtime,
org.spearce.jgit,
org.spearce.egit.core
Eclipse-LazyStart: true
+Bundle-RequiredExecutionEnvironment: J2SE-1.5
diff --git a/org.spearce.jgit/META-INF/MANIFEST.MF b/org.spearce.jgit/META-INF/MANIFEST.MF
index 3f9d29c..c5c0e0a 100644
--- a/org.spearce.jgit/META-INF/MANIFEST.MF
+++ b/org.spearce.jgit/META-INF/MANIFEST.MF
@@ -9,3 +9,4 @@ Export-Package: org.spearce.jgit.errors,
org.spearce.jgit.lib
Require-Bundle: org.junit
Eclipse-LazyStart: true
+Bundle-RequiredExecutionEnvironment: J2SE-1.5
--
1.5.1.1
^ permalink raw reply related
* Re: [RFC] Optimize diff-delta.c
From: Martin Koegler @ 2007-05-14 20:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Martin Koegler
git-pack-objects: cache small deltas between big objects
---
On Mon, 14 May 2007, Nicolas Pitre wrote:
> > I did some tests on differenent machines:
> >
> > - attached patch
> > Total 6452 (delta 4581), reused 1522 (delta 0)
> > 11354.38user 5451.60system 4:40:09elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (0major+1371504762minor)pagefaults 0swaps
> > =>75 MB pack size
>
> This is quite weird. I wonder what might cause such a large difference
> in pack size.
>
> Your first patch is probably faster due to the use of memcmp() which is
> certainly highly optimized, more than the comparison loop we have. It
> is unfortunate that there is no library function to find the number of
> identical bytes between two buffers. Or is there some?
As far as I know, no.
> But the size difference? That has certainly something to do with your
> data set since your patch makes no significant difference on the git.git
> nor the Linux kernel repos. Would it be possible for me to have a copy
> of your repo for further analysis?
I generate my repository by dumping a database. A script dumps a
few tables with mysqldump into per table files and commits them.
The dump file of each tables uses the one insert per line syntax, so
nearly all lines of a file share a >=27 bytes prefix. A diffstat to
the previous commit typically shows, that some
hundred lines are added at the end of each file.
A statistic of dropped hash table entries of the first thousand objects
in create_delta_index shows, that up to 41 % are dropped, eg:
Dropping: 3404731 of 8540915 (39.86 %)
Dropping: 3397330 of 8525886 (39.85 %)
Dropping: 3388813 of 8509648 (39.82 %)
Dropping: 3381134 of 8494317 (39.80 %)
Dropping: 3381128 of 8494294 (39.80 %)
Dropping: 3375786 of 8483589 (39.79 %)
Dropping: 3369725 of 8472206 (39.77 %)
Dropping: 3364377 of 8460707 (39.76 %)
Dropping: 3358120 of 8447813 (39.75 %)
Dropping: 3351482 of 8435015 (39.73 %)
Dropping: 3351481 of 8435007 (39.73 %)
Dropping: 3351478 of 8435000 (39.73 %)
Dropping: 3346193 of 8424055 (39.72 %)
Dropping: 3339952 of 8410503 (39.71 %)
Dropping: 3334324 of 8398253 (39.70 %)
Dropping: 3370085 of 8384362 (40.19 %)
Dropping: 3362979 of 8369151 (40.18 %)
Dropping: 3354905 of 8353432 (40.16 %)
So the current code will probably not always find the best match. As
my last patch can match nearly the whole file after finding a match,
the missing entries will not have a big influence.
As a side effect, my last patch increased the total running time and
minor page faults compared to the orignal version. I can not explain,
why this happens. The deltifing phase needs to read and uncompress the
same data. The only difference I can image, is, that different objects are selected
as delta base for the writing phase, which require more reading time (eg. because
they are bigger or have a longer delta chain in their current pack file).
As a large amount of CPU time is spent in writing the pack file (reading
all blobs again and applying the delta chain, computing the
delta_index and recomputing the delta) and the deltas are small,
I tried to cache the deltas from try_delta,
if the compared blobs are big (and therefore the delta operation is
expensive):
- my last patch + this patch
Total 6452 (delta 4581), reused 1522 (delta 0)
4176.04user 322.10system 1:14:58elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+83869085minor)pagefaults 0swaps
=> 75MB
builtin-pack-objects.c | 35 +++++++++++++++++++++++++----------
1 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 966f843..fe19272 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -35,6 +35,7 @@ struct object_entry {
struct object_entry *delta_sibling; /* other deltified objects who
* uses the same base as me
*/
+ void *delta_data; /* cached delta (uncompressed) */
unsigned long delta_size; /* delta data size (uncompressed) */
enum object_type type;
enum object_type in_pack_type; /* could be delta */
@@ -445,17 +446,24 @@ static unsigned long write_object(struct sha1file *f,
}
if (!to_reuse) {
- buf = read_sha1_file(entry->sha1, &type, &size);
- if (!buf)
- die("unable to read %s", sha1_to_hex(entry->sha1));
- if (size != entry->size)
- die("object %s size inconsistency (%lu vs %lu)",
- sha1_to_hex(entry->sha1), size, entry->size);
- if (entry->delta) {
- buf = delta_against(buf, size, entry);
+ if (entry->delta_data) {
+ buf = entry->delta_data;
size = entry->delta_size;
obj_type = (allow_ofs_delta && entry->delta->offset) ?
- OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ } else {
+ buf = read_sha1_file(entry->sha1, &type, &size);
+ if (!buf)
+ die("unable to read %s", sha1_to_hex(entry->sha1));
+ if (size != entry->size)
+ die("object %s size inconsistency (%lu vs %lu)",
+ sha1_to_hex(entry->sha1), size, entry->size);
+ if (entry->delta) {
+ buf = delta_against(buf, size, entry);
+ size = entry->delta_size;
+ obj_type = (allow_ofs_delta && entry->delta->offset) ?
+ OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ }
}
/*
* The object header is a byte of 'type' followed by zero or
@@ -1359,10 +1367,17 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
if (!delta_buf)
return 0;
+ if (trg_entry->delta_data)
+ free (trg_entry->delta_data);
+ trg_entry->delta_data = 0;
trg_entry->delta = src_entry;
trg_entry->delta_size = delta_size;
trg_entry->depth = src_entry->depth + 1;
- free(delta_buf);
+ /* cache delta, if objects are large enough compared to delta size */
+ if ((src_size >> 20) + (trg_size >> 21) > (delta_size >> 10))
+ trg_entry->delta_data = delta_buf;
+ else
+ free(delta_buf);
return 1;
}
--
1.5.1.4.g01b3
^ permalink raw reply related
* [StGIT PATCH] Fix bash completion after the DAG appliedness patch
From: Karl Hasselström @ 2007-05-14 19:44 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The bash tab completion used the "applied", "unapplied" and "current"
files to generate completions. Since these don't exist anymore, use
stg applied/unapplied/series to obtain the same info. It's a bit
slower, but not terribly much so.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
contrib/stgit-completion.bash | 15 ++++-----------
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/contrib/stgit-completion.bash b/contrib/stgit-completion.bash
index 3c3bf92..2032323 100644
--- a/contrib/stgit-completion.bash
+++ b/contrib/stgit-completion.bash
@@ -70,32 +70,25 @@ _current_branch ()
# List of all applied patches.
_applied_patches ()
{
- local g=$(_gitdir)
- [ "$g" ] && cat "$g/patches/$(_current_branch)/applied"
+ stg applied 2> /dev/null
}
# List of all unapplied patches.
_unapplied_patches ()
{
- local g=$(_gitdir)
- [ "$g" ] && cat "$g/patches/$(_current_branch)/unapplied"
+ stg unapplied 2> /dev/null
}
# List of all patches.
_all_patches ()
{
- local b=$(_current_branch)
- local g=$(_gitdir)
- [ "$g" ] && cat "$g/patches/$b/applied" "$g/patches/$b/unapplied"
+ stg series --noprefix 2> /dev/null
}
# List of all patches except the current patch.
_all_other_patches ()
{
- local b=$(_current_branch)
- local g=$(_gitdir)
- [ "$g" ] && cat "$g/patches/$b/applied" "$g/patches/$b/unapplied" \
- | grep -v "^$(cat $g/patches/$b/current 2> /dev/null)$"
+ stg series 2> /dev/null | grep -v '^>' | cut -f 2 -d ' '
}
# List the command options
^ permalink raw reply related
* [StGIT PATCH] Store branch description in the config file
From: Karl Hasselström @ 2007-05-14 19:28 UTC (permalink / raw)
To: Catalin Marinas
Cc: git, Junio C Hamano, Yann Dirson, Carl Worth, Petr Baudis,
J. Bruce Fields, Linus Torvalds, Johannes Sixt
In-Reply-To: <7vy7jtyh8q.fsf@assigned-by-dhcp.cox.net>
Instead of storing the branch description in an StGIT-specific file,
store it in the git config file, where tools other than StGIT can read
and write it.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
On 2007-05-12 12:27:49 -0700, Junio C Hamano wrote:
> Will it be something like
>
> [branch "master"]
> description = "My primary development line"
This was easier to do than I'd thought. I don't get quotes around the
description, though; do I have to insert them manually? And what
purpose do they serve?
stgit/stack.py | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index c105b21..7048af7 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -451,7 +451,6 @@ class Series(StgitObject):
self.__name)
self.__hidden_file = os.path.join(self._dir(), 'hidden')
- self.__descr_file = os.path.join(self._dir(), 'description')
# where this series keeps its patches
self.__patch_dir = os.path.join(self._dir(), 'patches')
@@ -550,11 +549,23 @@ class Series(StgitObject):
if os.path.isfile(protect_file):
os.remove(protect_file)
+ def __branch_descr(self):
+ return 'branch.%s.description' % self.get_branch()
+
def get_description(self):
- return self._get_field('description') or ''
+ # Fall back to the .git/patches/<branch>/description file if
+ # the config variable is unset.
+ return (config.get(self.__branch_descr())
+ or self._get_field('description') or '')
def set_description(self, line):
- self._set_field('description', line)
+ if line:
+ config.set(self.__branch_descr(), line)
+ else:
+ config.unset(self.__branch_descr())
+ # Delete the old .git/patches/<branch>/description file if it
+ # exists.
+ self._set_field('description', None)
def get_parent_remote(self):
value = config.get('branch.%s.remote' % self.__name)
@@ -787,8 +798,6 @@ class Series(StgitObject):
# (move functionality to StgitObject ?)
if os.path.exists(self.__hidden_file):
os.remove(self.__hidden_file)
- if os.path.exists(self.__descr_file):
- os.remove(self.__descr_file)
if os.path.exists(self._dir()+'/orig-base'):
os.remove(self._dir()+'/orig-base')
^ permalink raw reply related
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-14 18:58 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <20070514183931.GC23090@fieldses.org>
On 2007-05-14 14:39:31 -0400, J. Bruce Fields wrote:
> No, I appreciate the complaint, I just don't know what to do about
> it--as far as I can tell, I've chosen utf-8 everywhere I can: my
> commits are in utf-8, and "locale" run from the shell reports
> everything as "en_US.UTF-8". But I suspect the problem is on my end
> somewhere--do I need to do something to make sure mail I send gets a
> header identifying it as utf-8 and not iso-8859-1? I'll investigate
> some more tonight if I get the chance; any advice welcomed.
Your mail headers include this:
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
but the mail body has this:
It includes modifications as suggested by J. Bruce Fields, Karl
Hasselstr=C3=B6m and Daniel Barkalow.
(That's a two-byte sequence for a single character, which indicates
utf8 and rules out latin1.)
I guess the program that generates the e-mail (git-format-patch?)
thinks it's getting latin1 input, when it's in fact getting utf8
input. This is the exact same error (or rather, the exact same
symptom) that's happened once or twice the last week or so.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Matthieu Moy @ 2007-05-14 18:57 UTC (permalink / raw)
To: git
In-Reply-To: <20070514183931.GC23090@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: 8bit
[...]
> as far as I can tell, I've chosen utf-8 everywhere I can:
Probably except in your mailer's configuration then!
--
Matthieu
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: J. Bruce Fields @ 2007-05-14 18:39 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <20070514181943.GA31749@diana.vm.bytemark.co.uk>
On Mon, May 14, 2007 at 08:19:43PM +0200, Karl Hasselström wrote:
> On 2007-05-14 11:21:20 -0400, J. Bruce Fields wrote:
>
> > It includes modifications as suggested by J. Bruce Fields, Karl
> > Hasselström and Daniel Barkalow.
>
> Agh! utf8/latin1 confusion! Your mail is in latin1, but you've used
> the utf8 byte sequence for my name.
>
> Hmm. Maybe I should keep quiet, so people won't start dropping my name
> completely just to get rid of my complaints. :-)
No, I appreciate the complaint, I just don't know what to do about
it--as far as I can tell, I've chosen utf-8 everywhere I can: my commits
are in utf-8, and "locale" run from the shell reports everything as
"en_US.UTF-8". But I suspect the problem is on my end somewhere--do I
need to do something to make sure mail I send gets a header identifying
it as utf-8 and not iso-8859-1? I'll investigate some more tonight if I
get the chance; any advice welcomed.
--b.
^ permalink raw reply
* git-clone tries to cd to a remote repository
From: Tero Roponen @ 2007-05-14 15:41 UTC (permalink / raw)
To: junkio; +Cc: git
Hi,
the latest git seems to output a warning every time I
try to clone a repository that is not local:
$ git --version
git version 1.5.2.rc3.27.g43d151
$ git clone git://git.kernel.org/pub/scm/git/git.git
/usr/local/bin/git-clone: line 23: cd: git://git.kernel.org/pub/scm/git/git.git: No such file or directory
Initialized empty Git repository in /home/terrop/repositories/git/.git/
remote: Generating pack...
...
I think the output should be redirected to /dev/null,
but I'm not a shell/git guru...
--
Tero Roponen
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-14 18:19 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git, Johannes Schindelin
On 2007-05-14 11:21:20 -0400, J. Bruce Fields wrote:
> It includes modifications as suggested by J. Bruce Fields, Karl
> Hasselström and Daniel Barkalow.
Agh! utf8/latin1 confusion! Your mail is in latin1, but you've used
the utf8 byte sequence for my name.
Hmm. Maybe I should keep quiet, so people won't start dropping my name
completely just to get rid of my complaints. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Matthieu Moy @ 2007-05-14 18:13 UTC (permalink / raw)
To: git
In-Reply-To: <8c5c35580705110427o4de686e8qdb37f6a2da0043e4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
"Lars Hjemli" <lh@elementstorage.no> writes:
> Is this happening if you dcommit a file in a new directory?
That's it indeed.
The attached script seems to reproducibly trigger the problem on my
box:
$ ../git-svn-test.sh
Checked out revision 0.
A file
Adding file
Transmitting file data .
Committed revision 1.
Initialized empty Git repository in .git/
moy@localhost's password:
A file
r1 = 4357177f2d927931d31c8c49c0237561648001a7 (git-svn)
Checked out HEAD:
svn+ssh://localhost//home/moy/tmp/test/test.26377/svnrepo r1
Created commit aa2db5a: newdir
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 newdir/newfile
moy@localhost's password:
A newdir/newfile
Network connection closed unexpectedly: Connection closed unexpectedly at /home/moy/bin/local/verimag/git-svn line 405
$
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git-svn-test.sh --]
[-- Type: text/x-sh, Size: 465 bytes --]
#! /bin/sh
mkdir test.$$
cd test.$$
svnadmin create svnrepo
svn co file://$PWD/svnrepo svnco
cd svnco
echo content > file
svn add file
svn commit -m "added file"
cd ../
# This triggers the bug.
git-svn clone svn+ssh://localhost/$PWD/svnrepo git-svn-co
# while this doesn't
# git-svn clone file://localhost/$PWD/svnrepo git-svn-co
cd git-svn-co
mkdir newdir
echo othercontent > newdir/newfile
git add newdir/newfile
git commit -m "newdir"
git-svn dcommit
[-- Attachment #3: Type: text/plain, Size: 15 bytes --]
--
Matthieu
^ permalink raw reply
* Re: git log and merge commits
From: Geert Uytterhoeven @ 2007-05-14 18:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0705141045180.6739@woody.linux-foundation.org>
On Mon, 14 May 2007, Linus Torvalds wrote:
> On Mon, 14 May 2007, Geert Uytterhoeven wrote:
> > I noticed `git log -p' doesn't show the changes introduced by merge commits.
> > This is true for plain `git log -p' and for `git log -p <filename>'.
>
> The default diff output format is silent about merges, because merges can
> be shown multiple different ways, and you have to tell git which format
> you want.
IC.
> "git show" defaults to using "--cc", which is usually what you want. But
> it can be a fairly expensive operation, so "git log" defaults to not
> showing the merges at all.
>
> The alternative format is just plain "-c", which shows a combined merge
> (ie it effectively shows the diff from *both* parents for any file with
> content merging). It gets really really large, really easily, which is why
> "--cc" is often more interesting (since it shows what looks like just the
> potential conflicts!)
Yes, --cc (as pointed out by Jakub, too), and -c both show the merge change.
In my case a file was modified by a merge, but semantically that change didn't
belong to the merge. I saw during `git pull' that the file got modified, but I
couldn't find the actual change with `git log -p'...
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: git log and merge commits
From: Linus Torvalds @ 2007-05-14 17:51 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0705141803590.11269@pademelon.sonytel.be>
On Mon, 14 May 2007, Geert Uytterhoeven wrote:
>
> I noticed `git log -p' doesn't show the changes introduced by merge commits.
> This is true for plain `git log -p' and for `git log -p <filename>'.
The default diff output format is silent about merges, because merges can
be shown multiple different ways, and you have to tell git which format
you want.
"git show" defaults to using "--cc", which is usually what you want. But
it can be a fairly expensive operation, so "git log" defaults to not
showing the merges at all.
The alternative format is just plain "-c", which shows a combined merge
(ie it effectively shows the diff from *both* parents for any file with
content merging). It gets really really large, really easily, which is why
"--cc" is often more interesting (since it shows what looks like just the
potential conflicts!)
Linus
^ permalink raw reply
* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Matthieu Moy @ 2007-05-14 17:50 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.98.0705141016370.6739@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I wouldn't personally mind if somebody taught git to just track empty
> directories too.
Just to add my 2 cents: I just had a case where I would have needed
empty directories, and it seems reasonable as a workflow:
As a group of teachers, one created a skeleton, with stg like
./course/
./practical-works/day1
./practical-works/day2
./exercices/day1
./exercices/day2
...
He did it with svn, filled in only a few directories, I "git-svn
clone"d it, and I got almost nothing!
These empty directories are not interesting by themselves, but as a
placeholder to add files, I think it's a good thing to have them.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 06/10] user-manual: move howto/make-dist.txt into user manual
From: Linus Torvalds @ 2007-05-14 17:44 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <11791560892667-git-send-email->
On Mon, 14 May 2007, J. Bruce Fields wrote:
>
> +where release-script is a shell script that looks like:
> +
> +-------------------------------------------------
> +#!/bin/sh
> +stable="$1"
> +last="$2"
> +new="$3"
> +echo "# git-tag v$new"
> +echo "git-tar-tree v$new linux-$new | gzip -9 > ../linux-$new.tar.gz"
> +echo "git-diff-tree -p v$stable v$new | gzip -9 > ../patch-$new.gz"
> +echo "git-rev-list --pretty v$new ^v$last > ../ChangeLog-$new"
> +echo "git-rev-list --pretty=short v$new ^v$last | git-shortlog > ../ShortLog"
> +echo "git-diff-tree -p v$last v$new | git-apply --stat > ../diffstat-$new"
Actually, these days it looks more like
#!/bin/sh
stable="$1"
last="$2"
new="$3"
echo "# git tag v$new"
echo "git archive --prefix=linux-$new/ v$new | gzip -9 > ../linux-$new.tar.gz"
echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz"
echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new"
echo "git shortlog --no-merges v$new ^v$last > ../ShortLog"
echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
ie I'm using more modern versions of the git tools ;)
Linus
^ permalink raw reply
* Re: suggestions for gitweb
From: Michael Niedermayer @ 2007-05-14 17:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <200705141849.36457.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]
Hi
On Mon, May 14, 2007 at 06:49:35PM +0200, Jakub Narebski wrote:
[...]
> I think it would be nice to have --blame option to git-ls-tree
> (optionally copuled with --porcelain and perhaps --incremental, like
> in git-blame), which would return blame information for tree entries.
> It means that for each tree entry return commit closest to given commit
> (or furthest from a given commit) which has changed entry to current
> version. It should be much easier and faster than to do "blob"-blame.
>
> The --porcelain would also return 'last changed' info, like committer
> info for a commit-which-changed.
>
> But is this info actually interesting, or is it there in ViewVC because
> it is easy to get this info in CVS and Subversion? The "last changed"
> info for tree entries encourages to think of a history as a collection
> of per file histories... while git is all about whole project history.
> Note that history of two files is *more* than concatenation of
> histories of those individual files. See entries on GitFaq wiki page:
well, i do think that the age can be interesting, consider the 2
hypothetical cases:
'release_notes.txt 5 years ago' while all other files have been recently
changed
clearly says: noone cares about this file or there was no release in
the last 5 years
also for example
'vo_x11.c 2 days ago michael update all vos to use correct foobar'
'vo_mga.c 8 weeks ago diego spelling fixes'
would immedeatly hint that ive forgotten vo_mga.c ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Linus Torvalds @ 2007-05-14 17:26 UTC (permalink / raw)
To: Eric Wong; +Cc: Karl Hasselstr?m, Martin Eisenhardt, git, Matthieu.Moy
In-Reply-To: <20070513210128.GA13428@muzzle>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1682 bytes --]
On Sun, 13 May 2007, Eric Wong wrote:
> Karl Hasselström <kha@treskal.com> wrote:
>
> > It might be a net win to let git-svn handle empty directories by
> > creating an empty .git-svn-empty-dir file in them, instead of
> > pretending they don't exist.
>
> No. This is *WAY* too ugly.
I wouldn't personally mind if somebody taught git to just track empty
directories too.
There is no fundamental git database reason not to allow them: it's in
fact quite easy to create an empty tree object. The problems with empty
directories are in the *index*, and they shouldn't be insurmountable.
I never wanted empty directories for the kernel, but there is nothing
really fundamentally wrong with them either. They do have some problems,
which is why I don't particularly like tracking them, but if *not*
tracking them causes more problems for people who import from SVN, I could
easily see the balance moving towards "let people do it if they want".
In fact, I think the subproject support might have made it easier to track
directories as empty directory entries. Pretty much every place that got
impacted by subprojects would be where empty directory entries would be
handled too.
In fact, one of the questions when tracking empty directories is whether
you should track non-empty directories too. IOW, should we _always_ put
the directory entry into the index (even when it's not empty), or should
we do it only when somebody explicitly asks for it. I suspect the "always"
case would is the right answer (ie a read-tree would always add a
directory entry to the index before it starts adding the actual entries
in the read-tree)
Anybody want to try it?
Linus
^ permalink raw reply
* Re: [PATCH] Require JDK1.5
From: Robin Rosenberg @ 2007-05-14 17:24 UTC (permalink / raw)
To: Noel Grandin; +Cc: Grzegorz Kulewski, spearce, git
In-Reply-To: <46480E02.1010500@peralex.com>
måndag 14 maj 2007 skrev Noel Grandin:
>
> >> diff --git
> >> a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
> >> b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
> >> index c397a0d..63796fd 100644
> >> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
> >> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
> >> @@ -50,9 +50,9 @@ public class ObjectIdMap implements Map {
> >>
> >> public ObjectIdMap(Map sample) {
> >> try {
> >> - Method m=sample.getClass().getMethod("clone", null);
> >> + Method m=sample.getClass().getMethod("clone",
> >> (Class[])null);
> >> for (int i=0; i<256; ++i) {
> >> - level0[i] = (Map)m.invoke(sample, null);
> >> + level0[i] = (Map)m.invoke(sample, (Object[])null);
> >> }
> >> } catch (IllegalAccessException e) {
> >> throw new IllegalArgumentException(e);
> >
> > I wonder why one would need changes like this?
> >
> > These casts are not needed for anything as far as I can see and your
> > IDE should easily tell you what type that parameter is. No?
> >
> Those are varargs parameters, so when compiling under 1.5 you sometimes
> have to tell the compiler the difference between passing a varargs array
> and passing one parameter.
The compiler does the right thing by default in this case, but I don't
like seeing warnings for code that is perfectly fine, hence the cast.
I noticed I dropped using this class just before sending the previous set
of patches, so it isn't really necessary in the current code, but I think I will start
using it soon so it can stay.
-- robin
^ permalink raw reply
* [PATCH] user-manual: fix origin/linus confusion in topic-branches example
From: J. Bruce Fields @ 2007-05-14 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luck, Tony, git
In-Reply-To: <617E1C2C70743745A92448908E030B2A01749B36@scsmsx411.amr.corp.intel.com>
Tony Luck points out that I missed a few places when I tried to convert
from using a "linus" branch to using the more standard "origin" remote
setup.
This is my quick fix. I haven't yet tested the scripts. (And the
modifications aren't *completely* trivial, so it would probably be a
good idea.)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 34 +++++++++++++++++-----------------
1 files changed, 17 insertions(+), 17 deletions(-)
On Mon, May 14, 2007 at 09:30:47AM -0700, Luck, Tony wrote:
> There are a few places where the text still references my "linus"
> branch ... you fixed up the start of the document to switch this
> over to the more standard "origin".
Hm. I should actually test those scripts and maybe take a harder look
at them to decide whether they could be simplified or replaced with any
new git functionality.
Anyway, thanks for the proofreading! (And for putting that together in
the first place. People seem to find this sort of example really
helpful.)
--b.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5fb86f2..6324a09 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1895,9 +1895,9 @@ public trees using gitlink:git-remote[1] to set up a "remote" and
git-fetch[1] to keep them up-to-date; see <<repositories-and-branches>>.
Now create the branches in which you are going to work; these start out
-at the current tip of the linus branch, and should be set up (using the
---track option to gitlink:git-branch[1]) to merge changes in from linus
-by default.
+at the current tip of origin/master branch, and should be set up (using
+the --track option to gitlink:git-branch[1]) to merge changes in from
+Linus by default.
-------------------------------------------------
$ git branch --track test origin/master
@@ -1953,8 +1953,8 @@ $ git push mytree release
Now to apply some patches from the community. Think of a short
snappy name for a branch to hold this patch (or related group of
-patches), and create a new branch from the current tip of the
-linus branch:
+patches), and create a new branch from the current tip of Linus's
+branch:
-------------------------------------------------
$ git checkout -b speed-up-spinlocks origin
@@ -2012,13 +2012,13 @@ $ git log release..branchname
(If this branch has not yet been merged you will see some log entries.
If it has been merged, then there will be no output.)
-Once a patch completes the great cycle (moving from test to release, then
-pulled by Linus, and finally coming back into your local "linus" branch)
-the branch for this change is no longer needed. You detect this when the
-output from:
+Once a patch completes the great cycle (moving from test to release,
+then pulled by Linus, and finally coming back into your local
+"origin/master" branch) the branch for this change is no longer needed.
+You detect this when the output from:
-------------------------------------------------
-$ git log linus..branchname
+$ git log origin..branchname
-------------------------------------------------
is empty. At this point the branch can be deleted:
@@ -2050,16 +2050,16 @@ Here are some of the scripts that simplify all this even further.
-------------------------------------------------
==== update script ====
# Update a branch in my GIT tree. If the branch to be updated
-# is "linus", then pull from kernel.org. Otherwise merge local
-# linus branch into test|release branch
+# is origin, then pull from kernel.org. Otherwise merge
+# origin/master branch into test|release branch
case "$1" in
test|release)
git checkout $1 && git pull . origin
;;
-linus)
+origin)
before=$(cat .git/refs/heads/origin/master)
- git fetch linus
+ git fetch origin
after=$(cat .git/refs/heads/origin/master)
if [ $before != $after ]
then
@@ -2067,7 +2067,7 @@ linus)
fi
;;
*)
- echo "Usage: $0 linus|test|release" 1>&2
+ echo "Usage: $0 origin|test|release" 1>&2
exit 1
;;
esac
@@ -2122,14 +2122,14 @@ fi
for branch in `ls .git/refs/heads`
do
- if [ $branch = linus -o $branch = test -o $branch = release ]
+ if [ $branch = test -o $branch = release ]
then
continue
fi
echo -n $gb ======= $branch ====== $restore " "
status=
- for ref in test release linus
+ for ref in test release origin/master
do
if [ `git rev-list $ref..$branch | wc -c` -gt 0 ]
then
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* Re: [PATCH 03/10] glossary: expand and clarify some definitions, prune cross-references
From: Jakub Narebski @ 2007-05-14 17:00 UTC (permalink / raw)
To: git
In-Reply-To: <5520.48510076037$1179156136@news.gmane.org>
J. Bruce Fields wrote:
> +[[def_detached_HEAD]]detached HEAD::
> + Normally HEAD refers to the tip of a
> + <<def_branch,branch>>.
Normally HEAD refers to the branch _name_ (names current branch).
From this sentence one can think that normally HEAD is pointer
to commit which is tip of current branch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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