* Re: [PATCH] git-gui: Update Japanese strings
From: Shawn O. Pearce @ 2007-11-01 4:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ, git
In-Reply-To: <7v640mfvqu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> しらいしななこ <nanako3@bluebottle.com> writes:
>
> > This updates the Japanese translation file.
>
> This seems to be missing an earlier suggestion from Christian.
Thanks for the follow-up. This plus all of the other git-gui
patches from the past couple of days are now on repo.or.cz.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Jeff King @ 2007-11-01 4:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry Potapov, Karl Hasselström, Björn Steinbrink,
Johannes.Schindelin, git
In-Reply-To: <7vabpyfvwp.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 31, 2007 at 09:10:30PM -0700, Junio C Hamano wrote:
> I think assuming utf-8 and reencoding is actively wrong.
> Existing setups of people with names that cannot be expressed in
> ASCII would already have the commit encoding specified in the
> configuration and user.name stored in that encoding, so passing
> things through as we have always done is the right thing to do.
That will break any time somebody uses -s with a --encoding= that is
different from their usual encoding. My patch assumes the source is
utf-8, but should perhaps assume some other default encoding from the
config.
But if this is not a problem for people, I'm not going to push it. I
don't actually use any of these features; it was just something I
noticed while looking at the actual bug.
-Peff
^ permalink raw reply
* Re: [PATCH] git-gui: Update Japanese strings
From: Junio C Hamano @ 2007-11-01 4:14 UTC (permalink / raw)
To: しらいしななこ; +Cc: spearce, git
In-Reply-To: <200710311412.l9VECpnI002616@mi0.bluebottle.com>
しらいしななこ <nanako3@bluebottle.com> writes:
> This updates the Japanese translation file.
This seems to be missing an earlier suggestion from Christian.
diff --git a/po/ja.po b/po/ja.po
index e4491f7..f3a547b 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -1776,7 +1776,7 @@
#: lib/status_bar.tcl:83
#, tcl-format
msgid "%s ... %*i of %*i %s (%3i%%)"
-msgstr "%1$s ... %3$*i %4$s 中の %$2*i (%5$3i%%)"
+msgstr "%1$s ... %4$*i %6$s 中の %2$*i (%7$3i%%)"
#: lib/transport.tcl:6
#, tcl-format
^ permalink raw reply related
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Junio C Hamano @ 2007-11-01 4:10 UTC (permalink / raw)
To: Jeff King
Cc: Dmitry Potapov, Karl Hasselström, Björn Steinbrink,
Johannes.Schindelin, git
In-Reply-To: <20071101032303.GA14495@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 31, 2007 at 03:31:20PM -0700, Junio C Hamano wrote:
>
>> > ... I had one concern that
>> > I was tracking down: is the author name encoding necessarily the same as
>> > the commit text encoding?
>>
>> The user is screwing himself already if that is the case and
>> uses -s to format-patch, isn't he?
>
> Hrm, they probably _should_ be the same in the output. It's not clear to
> me what encoding we assume the name comes in (utf-8, I guess). Looks
> like we don't touch it at all when putting it in the signoff. I think we
> should just be able to reencode when appending the signoff; patch is
> below.
I think assuming utf-8 and reencoding is actively wrong.
Existing setups of people with names that cannot be expressed in
ASCII would already have the commit encoding specified in the
configuration and user.name stored in that encoding, so passing
things through as we have always done is the right thing to do.
^ permalink raw reply
* [PATCH] Show total transferred as part of throughput progress display
From: Shawn O. Pearce @ 2007-11-01 3:57 UTC (permalink / raw)
To: Junio C Hamano, Nicolas Pitre; +Cc: git
Right now it is infeasible to offer to the user a reasonable concept
of when a clone will be complete as we aren't able to come up with
the final pack size until after we have actually transferred the
entire thing to the client. However in many cases users can work
with a rough rule-of-thumb; for example it is somewhat well known
that git.git is about 16 MiB today and that linux-2.6.git is over
120 MiB.
We now show the total amount of data we have transferred over
the network as part of the throughput meter, organizing it in
"human friendly" terms like `ls -h` would do. Users can glance at
this, see that the total transferred size is about 3 MiB, see the
throughput of X KiB/sec, and determine a reasonable figure of about
when the clone will be complete, assuming they know the rough size
of the source repository or are able to obtain it.
This is also a helpful indicator that there is progress being made
even if we stall on a very large object. The thoughput meter may
remain relatively constant and the percentage complete and object
count won't be changing, but the total transferred will be increasing
as additional data is received for this object.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This follows on top of Nico's 5 patch series to add the thoughput
meter. I think its a useful addition.
progress.c | 32 +++++++++++++++++++++++++++++---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/progress.c b/progress.c
index 23ee9f3..5c95091 100644
--- a/progress.c
+++ b/progress.c
@@ -11,7 +11,11 @@ struct throughput {
unsigned int avg_misecs;
unsigned int last_misecs[TP_IDX_MAX];
unsigned int idx;
- char display[20];
+ unsigned int unit_size;
+ unsigned int unit_index;
+ unsigned int total_units;
+ unsigned int curr_bytes;
+ char display[40];
};
struct progress {
@@ -24,6 +28,7 @@ struct progress {
struct throughput *throughput;
};
+static const char *units[] = {"bytes", "KiB", "MiB", "GiB"};
static volatile sig_atomic_t progress_update;
static void progress_interval(int signum)
@@ -113,12 +118,27 @@ void display_throughput(struct progress *progress, unsigned long n)
if (!tp) {
progress->throughput = tp = calloc(1, sizeof(*tp));
- if (tp)
+ if (tp) {
tp->prev_tv = tv;
+ tp->unit_size = 1;
+ }
return;
}
tp->count += n;
+ tp->curr_bytes += n;
+ if (tp->curr_bytes > tp->unit_size) {
+ tp->total_units += tp->curr_bytes / tp->unit_size;
+ tp->curr_bytes = tp->curr_bytes % tp->unit_size;
+
+ while (tp->total_units >= 1024
+ && tp->unit_index < ARRAY_SIZE(units)) {
+ tp->curr_bytes += (tp->total_units % 1024) * tp->unit_size;
+ tp->total_units = tp->total_units / 1024;
+ tp->unit_size *= 1024;
+ tp->unit_index++;
+ }
+ }
/*
* We have x = bytes and y = microsecs. We want z = KiB/s:
@@ -143,7 +163,13 @@ void display_throughput(struct progress *progress, unsigned long n)
tp->avg_bytes += tp->count;
tp->avg_misecs += misecs;
snprintf(tp->display, sizeof(tp->display),
- ", %lu KiB/s", tp->avg_bytes / tp->avg_misecs);
+ ", %3u.%2.2u %s %lu KiB/s",
+ tp->total_units,
+ tp->unit_size > 1
+ ? tp->curr_bytes / (tp->unit_size / 100)
+ : 0,
+ units[tp->unit_index],
+ tp->avg_bytes / tp->avg_misecs);
tp->avg_bytes -= tp->last_bytes[tp->idx];
tp->avg_misecs -= tp->last_misecs[tp->idx];
tp->last_bytes[tp->idx] = tp->count;
--
1.5.3.4.1481.g854da
^ permalink raw reply related
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Jeff King @ 2007-11-01 3:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry Potapov, Karl Hasselström, Björn Steinbrink,
Johannes.Schindelin, git
In-Reply-To: <7vzlxygblz.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 31, 2007 at 03:31:20PM -0700, Junio C Hamano wrote:
> > ... I had one concern that
> > I was tracking down: is the author name encoding necessarily the same as
> > the commit text encoding?
>
> The user is screwing himself already if that is the case and
> uses -s to format-patch, isn't he?
Hrm, they probably _should_ be the same in the output. It's not clear to
me what encoding we assume the name comes in (utf-8, I guess). Looks
like we don't touch it at all when putting it in the signoff. I think we
should just be able to reencode when appending the signoff; patch is
below.
I'm sure there are other weird interactions lurking. For example, do we
correctly detect an existing signoff if we are storing in a non-utf8
encoding? I must admit to being a little ignorant to some of the
encoding magic of git, having a us-ascii name myself.
---
diff --git a/log-tree.c b/log-tree.c
index 3763ce9..906942d 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -3,6 +3,7 @@
#include "commit.h"
#include "log-tree.h"
#include "reflog-walk.h"
+#include "utf8.h"
struct decoration name_decoration = { "object names" };
@@ -111,7 +112,14 @@ static void append_signoff(struct strbuf *sb, const char *signoff)
strbuf_addch(sb, '\n');
strbuf_addstr(sb, signed_off_by);
- strbuf_add(sb, signoff, signoff_len);
+ if (git_log_output_encoding) {
+ char *encoded_name = reencode_string(signoff,
+ git_log_output_encoding, "utf-8");
+ strbuf_addstr(sb, encoded_name);
+ free(encoded_name);
+ }
+ else
+ strbuf_add(sb, signoff, signoff_len);
strbuf_addch(sb, '\n');
}
^ permalink raw reply related
* Re: [PATCH 1/5] prune-packed: don't call display_progress() for every file
From: Shawn O. Pearce @ 2007-11-01 2:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <1193770655-20492-2-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> wrote:
> The progress count is per fanout directory, so it is useless to call
> it for every file as the count doesn't change that often.
If you go back into the history and look at the commit message for
when I introduced this per-object display_progress() call we find
the following:
commit b5d72f0a4cd3cce945ca0d37e4fa0ebbfcdcdb52
Author: Shawn O. Pearce <spearce@spearce.org>
Date: Fri Oct 19 00:08:37 2007 -0400
[...snip...]
We perform the display_progress() call from within the very innermost
loop in case we spend more than 1 second within any single object
directory. This ensures that a progress_update event from the
timer will still trigger in a timely fashion and allow the user to
see the progress meter.
During my testing with a 40,000 loose object case (yea, I fully
unpacked a git.git clone I had laying around) my system stalled
hard in the first object directory. A *lot* longer than 1 second.
So I got no progress meter for a long time, and then a progress
meter appeared on the second directory.
The display_progress() call already does a reasonably cheap
comparsion to see if the timer has tripped or if the percent complete
has changed. So I figured it was more useful to get feedback to
the user that we were working, but were going to take a while,
than it was to optimize a few machine instructions out of that
inner-most per-object loop.
So I'm a little against this patch. But I think I understand why
you think its worth doing. I just consider the progress feedback
more important than the few machine cycles avoiding it saves.
--
Shawn.
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: Nicolas Pitre @ 2007-11-01 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Sergei Organov, git
In-Reply-To: <7vhck7gdzs.fsf@gitster.siamese.dyndns.org>
On Wed, 31 Oct 2007, Junio C Hamano wrote:
> A rebase conflict resolution that results in emptiness is a
> rather rare event (especially because rebase drops upfront the
> identical changes from the set of commits to be replayed), but
> it does happen. One could argue that "rebase --continue" can
> notice that the resolved index is identical to the tree of the
> HEAD commit and skip it automatically.
>
> Given an index that is identical to HEAD, however, it is not
> easy to safely determine if that is because the patch did not
> apply at all, or the patch was applied with conflicts _and_ the
> user decided to make the patch a no-op by resolving. The
> automatic droppage of the commit needs to happen only on the
> latter and never on the former.
Probably some additional clue could be displayed for the user benefit.
This might solve the issue nicely.
Nicolas
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Nguyen Thai Ngoc Duy @ 2007-11-01 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Hommey, git
In-Reply-To: <7vejfag40g.fsf@gitster.siamese.dyndns.org>
On 11/1/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > BTW, you have workaround for git-merge also? It uses cpio to save/restore state.
>
> Why do people want "workaround"? Is installing cpio such a
> hassle?
It is on Windows because busybox cpio is not really good and busybox
tar is even worse (for cpio emulation). Maybe I should just improve
busybox cpio :-)
--
Duy
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Junio C Hamano @ 2007-11-01 1:15 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Mike Hommey, git, Junio C Hamano
In-Reply-To: <fcaeb9bf0710311809o41703bc5hda36a9d44a538eeb@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> BTW, you have workaround for git-merge also? It uses cpio to save/restore state.
Why do people want "workaround"? Is installing cpio such a
hassle?
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Junio C Hamano @ 2007-11-01 1:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Hommey, git
In-Reply-To: <alpine.LFD.0.999.0710311742170.3342@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 31 Oct 2007, Mike Hommey wrote:
>> + if type cpio > /dev/null 2>&1; then
>> + local=yes
>> + fi
>
> Isn't "type" a bashism?
I seem to recall that it is in POSIX.
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Nguyen Thai Ngoc Duy @ 2007-11-01 1:09 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <1193861145-20357-1-git-send-email-mh@glandium.org>
BTW, you have workaround for git-merge also? It uses cpio to save/restore state.
On 11/1/07, Mike Hommey <mh@glandium.org> wrote:
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
> git-clone.sh | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/git-clone.sh b/git-clone.sh
> index 0ea3c24..57e96ae 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -191,7 +191,9 @@ fi
> # it is local
> if base=$(get_repo_base "$repo"); then
> repo="$base"
> - local=yes
> + if type cpio > /dev/null 2>&1; then
> + local=yes
> + fi
> fi
>
> dir="$2"
> --
> 1.5.3.4
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Duy
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Nguyen Thai Ngoc Duy @ 2007-11-01 1:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Hommey, git, Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710311742170.3342@woody.linux-foundation.org>
On 11/1/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 31 Oct 2007, Mike Hommey wrote:
> > + if type cpio > /dev/null 2>&1; then
> > + local=yes
> > + fi
>
> Isn't "type" a bashism?
busybox ash has "type". I'm happy.
--
Duy
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Jakub Narebski @ 2007-11-01 1:00 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0710311742170.3342@woody.linux-foundation.org>
Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Mike Hommey wrote:
>> + if type cpio > /dev/null 2>&1; then
>> + local=yes
>> + fi
>
> Isn't "type" a bashism?
>
> Maybe just do
>
> if echo . | cpio -o > /dev/null 2>&1; then
>
> instead? Maybe even doing this at install time to avoid the overhead of
> executing another process..
Or perhaps trap / check actual execution of cpio in git-clone, and
fallback to ln -s / link if it fails...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Linus Torvalds @ 2007-11-01 0:46 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <1193861145-20357-1-git-send-email-mh@glandium.org>
On Wed, 31 Oct 2007, Mike Hommey wrote:
> + if type cpio > /dev/null 2>&1; then
> + local=yes
> + fi
Isn't "type" a bashism?
Maybe just do
if echo . | cpio -o > /dev/null 2>&1; then
instead? Maybe even doing this at install time to avoid the overhead of
executing another process..
Linus
^ permalink raw reply
* Re: remote#branch
From: Jakub Narebski @ 2007-11-01 0:22 UTC (permalink / raw)
To: Mike Hommey; +Cc: Andreas Ericsson, Jeff King, git
In-Reply-To: <20071031091529.GA25025@glandium.org>
Mike Hommey wrote:
> On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:
>>>
>>>Or copied from gitweb.
>>>
>> Perhaps, but I've never seen that done. Partly because you can't be sure
>> the HTTP url is the same as the git address (perhaps people are used to
>> this from CVS and the likes), and partly because you'd, for most cases,
>> want to use git:// or ssh transport instead of http.
>>
>> It might be nifty to have gitweb print some git-valid locator for a repo
>> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
>> command-line thingie. I'll look into it when I have leisure.
>
> Hum... it already does print http and git "Mirror URL"s which are ready to
> be copy/pasted to feed git clone arguments.
The only thing to add (for absolutely no gain IMHO) would be code
which would add quotes (single or double) around URL/path which
contain spaces:
Mirror URL 'git://repo.or.cz/repo with spaces.git'
'http://repo.or.cz/r/repo with spaces.git'
Push URL 'repo.or.cz:/srv/git/repo with spaces.git'
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Implement sending mails over TLS in git-send-email.
From: Baz @ 2007-10-31 23:59 UTC (permalink / raw)
To: Simon Sasburg; +Cc: git
In-Reply-To: <981e6de60710311504v666943beve3b87c6a713fb18c@mail.gmail.com>
On 31/10/2007, Simon Sasburg <simon.sasburg@gmail.com> wrote:
> > In other words, this patch should be entirely unnecessary if you have
> > Authen::SASL installed - could you try this? (I've checked for myself,
> > git-send-email sends me mail fine via gmail without this patch)
>
> Well, it fails here, maybe maybe you can show me exactly what you did
> (configuration/parameters etc)?
>
> This is what i do now:
> > git-send-email testfile.patch -to simon.sasburg@gmail.com --chain-reply-to --smtp-server smtp.gmail.com --smtp-user simon.sasburg --smtp-pass secret --smtp-ssl --smtp-server-port 587
> and it fails, while the same line using --smtp-tls instead of
> --smtp-ssl with my patch applied works.
>
> What am i missing?
>
ok I'm going to downgrade what I said to 'it works fine with gmail' -
it just doesnt do starttls, your code does.
git-send-email --from 'brian.ewins@gmail.com' --to
'brian.ewins@gmail.com' --smtp-server smtp.gmail.com --smtp-user
'brian.ewins@gmail.com' --smtp-pass 'secret' --smtp-ssl
0001-the-patch-goes-here
That's using SSL on port 465, not TLS. Did this not work for you? I
thought Net::SMTP passed its constructor options to IO::Socket, but
no. An alternate way of getting starttls to work, without using
Net::SMTP::TLS, is this:
#connect with Net::SMTP - not ::SSL or the connect will fail
$smtp = Net::SMTP->new('smtp.gmail.com',
Port => 587,
Debug => 1) or die "Could not connect
to server\n";
#issue the starttls command, assuming user asked for this
$smtp->command('STARTTLS');
$smtp->response();
#if server says 220, then go ahead and convert the socket. Bless as
Net::SMTP::SSL
# - necessary to inherit both IO::Socket::SSL and Net::SMTP
#start_SSL has been renamed, twice. Nice stable api :)
#extra args for checking server cert etc can be passed to start_SSL.
$smtp->code() == 220 and $smtp = Net::SMTP::SSL->start_SSL($smtp) or
die "STARTTLS failed! ".$smtp->message;
# say hello again to get server features (including auth)
$smtp->hello();
# now continue as before, with $smtp->auth()...
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Johannes Schindelin @ 2007-10-31 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Hommey, git
In-Reply-To: <7v4pg6hq8u.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 31 Oct 2007, Junio C Hamano wrote:
> "type"? That's probably better than using "which", but sounds quite
> wrong. Why not add Makefile target that the shell scripts depend on to
> see if necessary tools are available and let the builder know if they
> are not?
I thought the accord was that "cpio" is a _runtime_ dependency. But yes,
I agree "type" is not necessarily the best choice. Maybe testing the exit
code for 127 (not found) is the better choice?
Ciao,
Dscho
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: David Kastrup @ 2007-10-31 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Sergei Organov, git
In-Reply-To: <7vhck7gdzs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> A rebase conflict resolution that results in emptiness is a rather
> rare event (especially because rebase drops upfront the identical
> changes from the set of commits to be replayed), but it does happen.
> One could argue that "rebase --continue" can notice that the resolved
> index is identical to the tree of the HEAD commit and skip it
> automatically.
>
> Given an index that is identical to HEAD, however, it is not
> easy to safely determine if that is because the patch did not
> apply at all,
Wouldn't there be a conflict in the index? A conflict which can only be
resolved by adding? Which then results in a question whether you forgot
to add?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: David Kastrup @ 2007-10-31 22:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sergei Organov, git
In-Reply-To: <Pine.LNX.4.64.0710312111170.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 31 Oct 2007, Sergei Organov wrote:
>
>> Yes, and that's the problem. Why 'git --continue' didn't just skip this
>> patch that *already became no-op* after conflict resolution and forced
>> me to explicitly use 'git --skip' instead?
>
> Isn't that obvious? To prevent you from accidentally losing a commit.
The commit would not change anything, so what is there to lose?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.3.5
From: Junio C Hamano @ 2007-10-31 22:40 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.5.3.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.5.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.5.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.5-1.$arch.rpm (RPM)
There are many fixes including a handful bugs that led to
segfaults.
----------------------------------------------------------------
GIT v1.5.3.5 Release Notes
==========================
Fixes since v1.5.3.4
--------------------
* Comes with git-gui 0.8.4.
* "git-config" silently ignored options after --list; now it will
error out with a usage message.
* "git-config --file" failed if the argument used a relative path
as it changed directories before opening the file.
* "git-config --file" now displays a proper error message if it
cannot read the file specified on the command line.
* "git-config", "git-diff", "git-apply" failed if run from a
subdirectory with relative GIT_DIR and GIT_WORK_TREE set.
* "git-blame" crashed if run during a merge conflict.
* "git-add -i" did not handle single line hunks correctly.
* "git-rebase -i" and "git-stash apply" failed if external diff
drivers were used for one or more files in a commit. They now
avoid calling the external diff drivers.
* "git-log --follow" did not work unless diff generation (e.g. -p)
was also requested.
* "git-log --follow -B" did not work at all. Fixed.
* "git-log -M -B" did not correctly handle cases of very large files
being renamed and replaced by very small files in the same commit.
* "git-log" printed extra newlines between commits when a diff
was generated internally (e.g. -S or --follow) but not displayed.
* "git-push" error message is more helpful when pushing to a
repository with no matching refs and none specified.
* "git-push" now respects + (force push) on wildcard refspecs,
matching the behavior of git-fetch.
* "git-filter-branch" now updates the working directory when it
has finished filtering the current branch.
* "git-instaweb" no longer fails on Mac OS X.
* "git-cvsexportcommit" didn't always create new parent directories
before trying to create new child directories. Fixed.
* "git-fetch" printed a scary (but bogus) error message while
fetching a tag that pointed to a tree or blob. The error did
not impact correctness, only user perception. The bogus error
is no longer printed.
* "git-ls-files --ignored" did not properly descend into non-ignored
directories that themselves contained ignored files if d_type
was not supported by the filesystem. This bug impacted systems
such as AFS. Fixed.
* Git segfaulted when reading an invalid .gitattributes file. Fixed.
* post-receive-email example hook fixed was fixed for
non-fast-forward updates.
* Documentation updates for supported (but previously undocumented)
options of "git-archive" and "git-reflog".
* "make clean" no longer deletes the configure script that ships
with the git tarball, making multiple architecture builds easier.
* "git-remote show origin" spewed a warning message from Perl
when no remote is defined for the current branch via
branch.<name>.remote configuration settings.
* Building with NO_PERL_MAKEMAKER excessively rebuilt contents
of perl/ subdirectory by rewriting perl.mak.
* http.sslVerify configuration settings were not used in scripted
Porcelains.
* "git-add" leaked a bit of memory while scanning for files to add.
* A few workarounds to squelch false warnings from recent gcc have
been added.
* "git-send-pack $remote frotz" segfaulted when there is nothing
named 'frotz' on the local end.
* "git-rebase -interactive" did not handle its "--strategy" option
properly.
----------------------------------------------------------------
Changes since v1.5.3.4 are as follows:
Alex Bennee (1):
Ensure we add directories in the correct order
Alex Riesen (1):
Fix generation of perl/perl.mak
Andrew Clausen (1):
helpful error message when send-pack finds no refs in common.
Aurelien Bompard (1):
honor the http.sslVerify option in shell scripts
Benoit Sigoure (1):
Fix a small memory leak in builtin-add
Bj旦rn Steinbrink (3):
Fix --strategy parsing in git-rebase--interactive.sh
git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.
git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
Brian Gernhardt (1):
cvsserver: Use exit 1 instead of die when req_Root fails.
Frank Lichtenheld (1):
git-config: don't silently ignore options after --list
Gerrit Pape (2):
git-config: handle --file option with relative pathname properly
git-config: print error message if the config file cannot be read
Jean-Luc Herren (2):
git add -i: Fix parsing of abbreviated hunk headers
git add -i: Remove unused variables
Jeff King (1):
send-pack: respect '+' on wildcard refspecs
Joakim Tjernlund (1):
Improve receive-pack error message about funny ref creation
Johannes Schindelin (5):
clear_commit_marks(): avoid deep recursion
rebase -i: use diff plumbing instead of porcelain
Fix setup_git_directory_gently() with relative GIT_DIR & GIT_WORK_TREE
fix filter-branch documentation
filter-branch: update current branch when rewritten
Julian Phillips (1):
fast-import: Fix argument order to die in file_change_m
Junio C Hamano (8):
git-remote: fix "Use of uninitialized value in string ne"
sha1_file.c: avoid gcc signed overflow warnings
merge-recursive.c: mrtree in merge() is not used before set
RelNotes-1.5.3.5: describe recent fixes
Prevent send-pack from segfaulting (backport from 'master')
git-merge: document but discourage the historical syntax
Update GIT 1.5.3.5 Release Notes
GIT 1.5.3.5
Lars Hjemli (1):
Make merge-recursive honor diff.renamelimit
Linus Torvalds (6):
Fix embarrassing "git log --follow" bug
Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
git-blame shouldn't crash if run in an unmerged tree
Avoid scary errors about tagged trees/blobs during git-fetch
Fix directory scanner to correctly ignore files without d_type
Fix diffcore-break total breakage
Mathias Megyei (1):
Do not remove distributed configure script
Michael W. Olson (1):
Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example
Michele Ballabio (2):
git-reflog: document --verbose
git-archive: document --exec
Nicolas Pitre (1):
cherry-pick/revert: more compact user direction message
Patrick Welche (1):
Define NI_MAXSERV if not defined by operating system
Ralf Wildenhues (1):
gitk.txt: Fix markup.
Robert Schiele (1):
fixing output of non-fast-forward output of post-receive-email
Sergei Organov (1):
core-tutorial: Use new syntax for git-merge.
Shawn O. Pearce (17):
git-gui: Display message box when we cannot find git in $PATH
git-gui: Handle starting on mapped shares under Cygwin
git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs
git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk
git-gui: Don't crash when starting gitk from a browser session
Whip post 1.5.3.4 maintenance series into shape.
Correct typos in release notes for 1.5.3.5
Avoid 'expr index' on Mac OS X as it isn't supported
Document additional 1.5.3.5 fixes in release notes
Yet more 1.5.3.5 fixes mentioned in release notes
Avoid invoking diff drivers during git-stash
Further 1.5.3.5 fixes described in release notes
Paper bag fix diff invocation in 'git stash show'
git-gui: Correctly report failures from git-write-tree
git-gui: Handle progress bars from newer gits
git-gui: Don't display CR within console windows
Describe more 1.5.3.5 fixes in release notes
Simon Sasburg (1):
git-gui: Avoid using bold text in entire gui for some fonts
Steffen Prohaska (2):
git-gui: accept versions containing text annotations, like 1.5.3.mingw.1
attr: fix segfault in gitattributes parsing code
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: J. Bruce Fields @ 2007-10-31 22:38 UTC (permalink / raw)
To: Steven Grimm; +Cc: Johannes Schindelin, Sergei Organov, git
In-Reply-To: <4728FC5C.30709@midwinter.com>
On Wed, Oct 31, 2007 at 03:06:20PM -0700, Steven Grimm wrote:
> I've been using rebase just about every day for close to a year and it
> *still* annoys me when it happens. Especially the "Did you forget to git
> add?" part of the message. The thought that always goes through my head is,
> "No, Mr. Rebase, I did NOT forget to git add. I remembered to git add, then
> you were too stupid to do the right thing after that."
>
> Just happened to me this morning, in fact: I had a quick hack in place to
> work around a bug, the bug got fixed for real, and I rebased. In the
> process of conflict resolution I saw that my workaround wasn't needed any
> more and accepted the upstream version of that particular part of the file.
> Ran git-add on it, then rebase --continue, and boom, was accused of
> forgetting to run git-add.
>
> It is a minor annoyance and nowadays I just sigh a bit and run --skip
> instead, but it'd be nice if it didn't happen. I don't like having to care
> whether or not I happened to change other files in a particular commit
> after I resolve conflicts in one file in favor of the upstream version.
Yeah, I think a message saying "patch is now empty, skipping..." would
be sufficient to let the user know what's going on. This doesn't seem
so perilous to me that it's worth requiring a positive acknowledgement.
--b.
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: Daniel Barkalow @ 2007-10-31 22:35 UTC (permalink / raw)
To: Steven Grimm; +Cc: J. Bruce Fields, Johannes Schindelin, Sergei Organov, git
In-Reply-To: <4728FC5C.30709@midwinter.com>
On Wed, 31 Oct 2007, Steven Grimm wrote:
> J. Bruce Fields wrote:
> > I ran into the same confusion as the original poster when starting to
> > use rebase, so I suspect it's common.
> >
>
> I've been using rebase just about every day for close to a year and it *still*
> annoys me when it happens. Especially the "Did you forget to git add?" part of
> the message. The thought that always goes through my head is, "No, Mr. Rebase,
> I did NOT forget to git add. I remembered to git add, then you were too stupid
> to do the right thing after that."
>
> Just happened to me this morning, in fact: I had a quick hack in place to work
> around a bug, the bug got fixed for real, and I rebased. In the process of
> conflict resolution I saw that my workaround wasn't needed any more and
> accepted the upstream version of that particular part of the file. Ran git-add
> on it, then rebase --continue, and boom, was accused of forgetting to run
> git-add.
>
> It is a minor annoyance and nowadays I just sigh a bit and run --skip instead,
> but it'd be nice if it didn't happen. I don't like having to care whether or
> not I happened to change other files in a particular commit after I resolve
> conflicts in one file in favor of the upstream version.
I think it's worth requiring you to say --skip in order to acknowledge
that you won't have as many commits and you'll lose the commit message. On
the other hand, the message should probably suggest that you might want to
skip this commit instead of suggesting that you come up with some other
change to include in it.
Certainly, if "git diff" returns no changes, "git add" is a bad
suggestion, and it would be nicer to suggest something possibly correct.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Junio C Hamano @ 2007-10-31 22:31 UTC (permalink / raw)
To: Jeff King
Cc: Dmitry Potapov, Karl Hasselström, Björn Steinbrink,
Johannes.Schindelin, git
In-Reply-To: <20071031215625.GC14211@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... I had one concern that
> I was tracking down: is the author name encoding necessarily the same as
> the commit text encoding?
The user is screwing himself already if that is the case and
uses -s to format-patch, isn't he?
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Junio C Hamano @ 2007-10-31 22:29 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1193861145-20357-1-git-send-email-mh@glandium.org>
"type"? That's probably better than using "which", but sounds
quite wrong. Why not add Makefile target that the shell scripts
depend on to see if necessary tools are available and let the
builder know if they are not?
^ 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