* [PATCH] Makefile: set PERL_PATH and SHELL_PATH unconditionally
From: Matt Kraai @ 2009-10-20 9:06 UTC (permalink / raw)
To: git, gitster; +Cc: Matt Kraai
In-Reply-To: <7vr5syshat.fsf@alter.siamese.dyndns.org>
Do not check whether PERL_PATH and SHELL_PATH are undefined before
setting their default values. This prevents them from being set via
environment variables.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
On Mon, Oct 19, 2009 at 11:36:26PM -0700, Junio C Hamano wrote:
> Matt Kraai <kraai@ftbfs.org> writes:
>
> > The top-level Makefile currently contains
> >
> >> ifndef SHELL_PATH
> >> SHELL_PATH = /bin/sh
> >> endif
> >> ifndef PERL_PATH
> >> PERL_PATH = /usr/bin/perl
> >> endif
> >
> > The checks are only necessary if these variables need to be overridden
> > by environment variables, not just via the make command line. Is this
> > the case?
>
> It may not have been the original intention, but the above would mean that
> some people may have learned to run "SHELL_PATH=/bin/ksh make" and
> changing it would break things for them, no?
Yes, that's what I was concerned about. This appears to be possible
for PERL_PATH on all platforms and for SHELL_PATH on platforms other
than SCO UnixWare, SunOS, and IRIX.
> I do not think changing them is bad per-se, but we would need to add extra
> warnings in the release note to explain this change, that's all. This
> would only affect people who build from the source (including distro
> people) so it is not really a big deal.
I hope this patch is OK.
Documentation/RelNotes-1.6.6.txt | 3 +++
Makefile | 8 ++------
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
index 5f1fecb..bfda14c 100644
--- a/Documentation/RelNotes-1.6.6.txt
+++ b/Documentation/RelNotes-1.6.6.txt
@@ -58,3 +58,6 @@ release, unless otherwise noted.
whitespace attribute). The 'trailing-space' whitespace error class has
become a short-hand to cover both of these and there is no behaviour
change for existing set-ups.
+
+ * PERL_PATH and SHELL_PATH may not be overridden using environment
+ variables during the build.
diff --git a/Makefile b/Makefile
index 42b7d60..5bac305 100644
--- a/Makefile
+++ b/Makefile
@@ -392,12 +392,8 @@ ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
OTHER_PROGRAMS = git$X
# Set paths to tools early so that they can be used for version tests.
-ifndef SHELL_PATH
- SHELL_PATH = /bin/sh
-endif
-ifndef PERL_PATH
- PERL_PATH = /usr/bin/perl
-endif
+SHELL_PATH = /bin/sh
+PERL_PATH = /usr/bin/perl
export PERL_PATH
--
1.6.5
^ permalink raw reply related
* Re: git gc and kernel.org
From: Mikael Magnusson @ 2009-10-20 9:08 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, ftpadmin
In-Reply-To: <4ADD6026.8070203@zytor.com>
2009/10/20 H. Peter Anvin <hpa@zytor.com>:
> We have run into two major problems with git on kernel.org. We have
> discussed workarounds, but I believe they are generally major problems which
> will affect other sites, and really need to be fixed upstream.
>
> 1) git receive-pack doesn't run git gc --auto.
>
> This cause repositories which people thought were being autopacked to not be
> so. This can be done via a hook, but that is way too painful for people to
> do -- in fact, it's hard enough just to get people to enable the post-update
> hook for http fetching.
>
> 1b) as per the above, a way to make "git update-server-info" at post-update
> time a configurable option rather than needing to be done via the hook would
> be very nice, since a configuration option can be enabled sitewide.
>
> 2) When pushing to a repository, it apparently doesn't honor new objects in
> alternate repositories. This causes massive unnecessary duplication.
>
> I believe these are major issues that need to be addressed. If we are
> *mistaken* on these, then we would appreciate being corrected.
I don't know how you create repos on kernel.org, but by default both
git init and git clone uses /usr/share/git-core/templates for the new
repo, for example I put a symbolic ref h -> HEAD there to save some
typing. You can enable whatever hooks you want there, but they would
only take effect for new repos.
--
Mikael Magnusson
^ permalink raw reply
* [PATCH] import-tars: Add support for tarballs compressed with lzma, xz
From: Ingmar Vanhassel @ 2009-10-20 8:59 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Peter Krefting, Junio C Hamano, Ingmar Vanhassel
Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
---
contrib/fast-import/import-tars.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
index 7001862..95438e1 100755
--- a/contrib/fast-import/import-tars.perl
+++ b/contrib/fast-import/import-tars.perl
@@ -20,7 +20,7 @@ use Getopt::Long;
my $metaext = '';
-die "usage: import-tars [--metainfo=extension] *.tar.{gz,bz2,Z}\n"
+die "usage: import-tars [--metainfo=extension] *.tar.{gz,bz2,lzma,xz,Z}\n"
unless GetOptions('metainfo=s' => \$metaext) && @ARGV;
my $branch_name = 'import-tars';
@@ -49,6 +49,9 @@ foreach my $tar_file (@ARGV)
} elsif ($tar_name =~ s/\.tar\.Z$//) {
open(I, '-|', 'uncompress', '-c', $tar_file)
or die "Unable to uncompress -c $tar_file: $!\n";
+ } elsif ($tar_name =~ s/\.(tar\.(lzma|xz)|(tlz|txz))$//) {
+ open(I, '-|', 'xz', '-dc', $tar_file)
+ or die "Unable to xz -dc $tar_file: $!\n";
} elsif ($tar_name =~ s/\.tar$//) {
open(I, $tar_file) or die "Unable to open $tar_file: $!\n";
} else {
--
1.6.5.1
^ permalink raw reply related
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Sebastian Schuberth @ 2009-10-20 8:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Marius Storm-Olsen, Johannes Sixt, Johannes Schindelin
In-Reply-To: <7vzl7mr1f5.fsf@alter.siamese.dyndns.org>
On Tue, Oct 20, 2009 at 09:04, Junio C Hamano <gitster@pobox.com> wrote:
>> When compiling with MSVC on x86-compatible, use an intrinsic for byte swapping.
>> In contrast to the GCC path, we do not prefer inline assembly here as it is not
>> supported for the x64 platform.
>>
>> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
>
> Unlike the other one this is not Acked by Marius, Dscho, or J6t; should I
> pick this up myself, or should I wait to be fed by one of msysgit people?
Well, in fact I am one of the msysgit poeple, although I mostly worked
on the installer until now. In general, I like my patches to be
reviewed, but this one is rather uncritical, I guess. So it's up to
you, Junio, I'm perfectly OK with waiting for an ACK.
--
Sebastian Schuberth
^ permalink raw reply
* Re: git gc and kernel.org
From: Johan Herland @ 2009-10-20 8:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, H. Peter Anvin, ftpadmin
In-Reply-To: <7veioyqzeo.fsf@alter.siamese.dyndns.org>
On Tuesday 20 October 2009, Junio C Hamano wrote:
> At one point, update-server-info used to compute a lot more than what we
> currently compute and it made some sense to oppose against it on
> performance ground.
>
> But these days it only lists the refs and packs and does nothing else;
> the performance impact should be immeasurable and it adds only two files
> to the repository. It cannot be a big deal, unless you oppose to http
> transport on a non-technical ground.
FYI, update-server-info takes ~0.7 seconds in a repo with one pack and
~50000 refs, so I guess it's acceptable to enable it by default, even in
those kinds of repos.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Which dates 'git log --since= --after=' compare?
From: Jeff King @ 2009-10-20 8:37 UTC (permalink / raw)
To: Daniel; +Cc: git
In-Reply-To: <4c067ee1.a34185.4adc390d.a980c@o2.pl>
On Mon, Oct 19, 2009 at 12:01:49PM +0200, Daniel wrote:
> I can see that 'git log --since= --after=' compares commit's dates,
> not author's dates.How can I limit commits by Author's date?
AFAIK, there is currently no way to do it with a simple option. In fact,
we don't even parse the author date when doing revision limiting.
So it would need a patch, but the "obvious" solution of just parsing and
storing the author date in a "struct commit" might not be acceptable; as
I recall, some performance tuning went into keeping the per-commit
memory footprint as small as possible, which had a noticeable speed
benefit (I'm not saying it couldn't be done, but care needs to be taken
in that regard).
If it's not something you need to do often, I'd consider something like:
git log --format='%H %at' |
perl -ane '
BEGIN {
use DateTime::Format::Natural;
$max_age = DateTime::Format::Natural->new->parse_datetime(
"last friday"
)->epoch;
}
print $F[0], "\n" if $F[1] < $max_age;
'
Of course that's awful to type, and it will be much slower than git
doing the revision limiting itself.
-Peff
^ permalink raw reply
* Re: git gc and kernel.org
From: H. Peter Anvin @ 2009-10-20 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, ftpadmin
In-Reply-To: <7veioyqzeo.fsf@alter.siamese.dyndns.org>
On 10/20/2009 04:48 PM, Junio C Hamano wrote:
> As to (1), I think it is reasonable to do some sort of "gc" in
> receive-pack, and while I recall that Linus was violently against the
> idea, I personally think it is reasonable to run update-server-info
> ourselves at the same time without needing the hook, even if the
> repository is never going to be served over dumb http [*1*]. At one
> point, update-server-info used to compute a lot more than what we
> currently compute and it made some sense to oppose against it on
> performance ground.
>
> But these days it only lists the refs and packs and does nothing else; the
> performance impact should be immeasurable and it adds only two files to
> the repository. It cannot be a big deal, unless you oppose to http
> transport on a non-technical ground.
I'm obviously happy with making it a non-default option; we can enable
it sitewide on kernel.org.
However, git update-server-info seems to take almost no time even in
very large repos.
-hpa
^ permalink raw reply
* Re: git gc and kernel.org
From: Junio C Hamano @ 2009-10-20 7:48 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, ftpadmin
In-Reply-To: <4ADD6026.8070203@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> We have run into two major problems with git on kernel.org. We have
> discussed workarounds, but I believe they are generally major problems
> which will affect other sites, and really need to be fixed upstream.
>
> 1) git receive-pack doesn't run git gc --auto.
>
> This cause repositories which people thought were being autopacked to
> not be so. This can be done via a hook, but that is way too painful
> for people to do -- in fact, it's hard enough just to get people to
> enable the post-update hook for http fetching.
>
> 1b) as per the above, a way to make "git update-server-info" at
> post-update time a configurable option rather than needing to be done
> via the hook would be very nice, since a configuration option can be
> enabled sitewide.
>
> 2) When pushing to a repository, it apparently doesn't honor new
> objects in alternate repositories. This causes massive unnecessary
> duplication.
>
> I believe these are major issues that need to be addressed. If we are
> *mistaken* on these, then we would appreciate being corrected.
I actually was wondering if (2) is still true after reading the message
from Wilcox. It should be a simple matter of testing, but I think this
issue was improved around the end of January this year with v1.6.1.2.
As to (1), I think it is reasonable to do some sort of "gc" in
receive-pack, and while I recall that Linus was violently against the
idea, I personally think it is reasonable to run update-server-info
ourselves at the same time without needing the hook, even if the
repository is never going to be served over dumb http [*1*]. At one
point, update-server-info used to compute a lot more than what we
currently compute and it made some sense to oppose against it on
performance ground.
But these days it only lists the refs and packs and does nothing else; the
performance impact should be immeasurable and it adds only two files to
the repository. It cannot be a big deal, unless you oppose to http
transport on a non-technical ground.
^ permalink raw reply
* Re: [PATCH] Documentation/git-gc.txt: change "references" to "reference"
From: Junio C Hamano @ 2009-10-20 7:23 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1256016145-21680-1-git-send-email-kraai@ftbfs.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Junio C Hamano @ 2009-10-20 7:04 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: git, Marius Storm-Olsen, Johannes Sixt, Johannes Schindelin
In-Reply-To: <hbi4mt$tjt$1@ger.gmane.org>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> When compiling with MSVC on x86-compatible, use an intrinsic for byte swapping.
> In contrast to the GCC path, we do not prefer inline assembly here as it is not
> supported for the x64 platform.
>
> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Unlike the other one this is not Acked by Marius, Dscho, or J6t; should I
pick this up myself, or should I wait to be fed by one of msysgit people?
> ---
> compat/bswap.h | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/compat/bswap.h b/compat/bswap.h
> index 5cc4acb..279e0b4 100644
> --- a/compat/bswap.h
> +++ b/compat/bswap.h
> @@ -28,6 +28,16 @@ static inline uint32_t default_swab32(uint32_t val)
> } \
> __res; })
>
> +#elif defined(_MSC_VER) && (defined(_M_IX86) || defined(_M_X64))
> +
> +#include <stdlib.h>
> +
> +#define bswap32(x) _byteswap_ulong(x)
> +
> +#endif
> +
> +#ifdef bswap32
> +
> #undef ntohl
> #undef htonl
> #define ntohl(x) bswap32(x)
> --
> 1.6.5.rc2.13.g1be2
^ permalink raw reply
* git gc and kernel.org
From: H. Peter Anvin @ 2009-10-20 7:00 UTC (permalink / raw)
To: Git Mailing List; +Cc: ftpadmin
We have run into two major problems with git on kernel.org. We have
discussed workarounds, but I believe they are generally major problems
which will affect other sites, and really need to be fixed upstream.
1) git receive-pack doesn't run git gc --auto.
This cause repositories which people thought were being autopacked to
not be so. This can be done via a hook, but that is way too painful for
people to do -- in fact, it's hard enough just to get people to enable
the post-update hook for http fetching.
1b) as per the above, a way to make "git update-server-info" at
post-update time a configurable option rather than needing to be done
via the hook would be very nice, since a configuration option can be
enabled sitewide.
2) When pushing to a repository, it apparently doesn't honor new objects
in alternate repositories. This causes massive unnecessary duplication.
I believe these are major issues that need to be addressed. If we are
*mistaken* on these, then we would appreciate being corrected.
Thanks,
-hpa
^ permalink raw reply
* Re: [PATCH] blame: make sure that the last line ends in an LF
From: Junio C Hamano @ 2009-10-20 7:00 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Johannes Schindelin
In-Reply-To: <1256007988-13321-1-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Currently the parsing is difficult when not all files have a newline
> at EOF, this patch ensures that even such files have a newline at the
> end of the blame output.
Thanks. This clearly shows that blame was somewhat sloppily written in
that it never considered to be fed anything but well formed text files.
My knee-jerk reaction to the issue is that there are two reasonable
approaches to the problem:
(1) Admit that the code is not prepared to take anything but well formed
text files. This will lead to adding the necessary LF after reading
a blob and if it does not end with LF. After all, I do not trust the
code (iow, "me") if it is not prepared to take a blob with incomplete
line to handle the internal comparison between blobs with incomplete
lines.
(2) Do the right thing, by coming up with a notation to show that the
final line is incomplete, perhaps similar to "\No newline ..."
notation used by "diff".
To put the last sentence of (1) differently, does the code assign blame
correctly around the last line of the original blob? What if an older
version ended with an incomplete line and a later version changed the line
(without adding the terminating LF)? What if a later version changed the
line and added the terminating LF? What if a later version only added the
terminating LF and did nothing else? Are these three cases handled
correctly?
After thinking issues like the above, I read the patch and I see it does
not take neither approach. That makes me feel nervous.
By tweaking only the output routine you _might_ be getting correct output,
but even then it looks to me like the end result is working correctly not
by design but by accident. IOW, the patch may be better than nothing, but
somehow it just feels like it is papering over the real issue than being a
proper fix.
Or am I worrying too much?
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
> CC: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> Patch by Dscho, commit message by me. Apologies to Dscho for
> taking so long to send it :).
>
> builtin-blame.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-blame.c b/builtin-blame.c
> index 7512773..dd16b22 100644
> --- a/builtin-blame.c
> +++ b/builtin-blame.c
> @@ -1604,6 +1604,9 @@ static void emit_porcelain(struct scoreboard *sb, struct blame_entry *ent)
> } while (ch != '\n' &&
> cp < sb->final_buf + sb->final_buf_size);
> }
> +
> + if (sb->final_buf_size && cp[-1] != '\n')
> + putchar('\n');
> }
>
> static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
> @@ -1667,6 +1670,9 @@ static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
> } while (ch != '\n' &&
> cp < sb->final_buf + sb->final_buf_size);
> }
> +
> + if (sb->final_buf_size && cp[-1] != '\n')
> + putchar('\n');
> }
>
> static void output(struct scoreboard *sb, int option)
> --
> 1.6.5.1.123.ge01f7
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Junio C Hamano @ 2009-10-20 6:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Johannes Sixt, Sergio Callegari, git
In-Reply-To: <vpqy6n6shri.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Linus and other git developers from the early days [...]
>
> Thanks for the historical background.
>
>> It probably makes sense to ship 1.7.0 with a version of "fsck" in which
>> "--full" is the default; it would still accept "--full" but it would be a
>> no-op.
>
> +1
>
>> It probably is also a good idea to add a "--loose" option that does what
>> "fsck" currently does without "--full". It is a good name
>
> +1 too.
Actually, I changed my mind. I do not think this so big that we need to
wait for a major version bump. Why not shoot for 1.6.6?
^ permalink raw reply
* Re: Extra checks for PERL_PATH and SHELL_PATH?
From: Junio C Hamano @ 2009-10-20 6:36 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <20091020035051.GA3237@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> The top-level Makefile currently contains
>
>> ifndef SHELL_PATH
>> SHELL_PATH = /bin/sh
>> endif
>> ifndef PERL_PATH
>> PERL_PATH = /usr/bin/perl
>> endif
>
> The checks are only necessary if these variables need to be overridden
> by environment variables, not just via the make command line. Is this
> the case?
It may not have been the original intention, but the above would mean that
some people may have learned to run "SHELL_PATH=/bin/ksh make" and
changing it would break things for them, no?
I do not think changing them is bad per-se, but we would need to add extra
warnings in the release note to explain this change, that's all. This
would only affect people who build from the source (including distro
people) so it is not really a big deal.
^ permalink raw reply
* Re: git-svn: add support for merges during 'git svn fetch'
From: Junio C Hamano @ 2009-10-20 6:32 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1256006523-5493-1-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> This series adds support for converting SVN merges - in the two
> popular formats, SVK and SVN 1.5+, into git parents.
Nice ;-)
^ permalink raw reply
* Re: [PATCH] am: allow some defaults to be specified via git-config
From: Junio C Hamano @ 2009-10-20 6:30 UTC (permalink / raw)
To: Sam Vilain; +Cc: Wesley J. Landaker, git, Nigel McNie
In-Reply-To: <4ADD241F.9060004@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> Wesley J. Landaker wrote:
>> On Thursday 15 October 2009 17:50:27 Sam Vilain wrote:
>>> +am.*::
>>> + Specify defaults for linkgit:git-am[1]. Currently, the three
>>> + boolean options, 'sign', 'utf8' and 'keep' may be specified.
>>> +
>>
>> The 'git am' option is 'signoff', not 'sign'. Shouldn't the command option
>> and config option names match?
>
> Thanks for pointing that out. Yes, it should be.
Wouldn't this patch make issues like $gmane/130744 even worse, unless you
add some disabling code to rebase?
^ permalink raw reply
* Documentation video for svn-git
From: jamesmikedupont @ 2009-10-20 6:30 UTC (permalink / raw)
To: git
I have created a computer reading of Sam's svn-git text :
http://www.archive.org/details/SvnGitVideo
It runs 1.5 hours.
I can also do other texts, also the source is checked in to create
them yourselves.
https://code.launchpad.net/~jamesmikedupont/introspectorreader/wikipedia-strategy
mike
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Matthieu Moy @ 2009-10-20 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, Sergio Callegari, git
In-Reply-To: <7v7hur1a0h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus and other git developers from the early days [...]
Thanks for the historical background.
> It probably makes sense to ship 1.7.0 with a version of "fsck" in which
> "--full" is the default; it would still accept "--full" but it would be a
> no-op.
+1
> It probably is also a good idea to add a "--loose" option that does what
> "fsck" currently does without "--full". It is a good name
+1 too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Matthieu Moy @ 2009-10-20 6:24 UTC (permalink / raw)
To: Wesley J. Landaker; +Cc: git, Sergio Callegari, Johannes Sixt, Junio C Hamano
In-Reply-To: <200910191307.56989.wjl@icecavern.net>
"Wesley J. Landaker" <wjl@icecavern.net> writes:
> Until I read this thread, I didn't realize you needed --full to check
> objects in packs.
Same here.
> - OPT_BOOLEAN(0, "full", &check_full, "also consider alternate objects"),
> + OPT_BOOLEAN(0, "full", &check_full, "also consider packs and alternate objects"),
IMHO, something like this should be applied to "maint", this is kind
of a serious bug indeed. Just check the "alternate" thing, according
to Junio:
Junio C Hamano <gitster@pobox.com> writes:
> Side note. I think the help description of --full option is wrong (or
> at least stale). We always look at alternate object store these days
> since e15ef66 (fsck: check loose objects from alternate object stores
> by default, 2009-01-30). It probably should read "check packed
> objects fully" or something.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC PATCH] git-gui: Allow staging multiple lines at once
From: Johannes Sixt @ 2009-10-20 6:11 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <20091019195456.GA11121@unpythonic.net>
Jeff Epler schrieb:
> When applying less than a full hunk, it's still often desirable to apply
> a number of consecutive lines.
>
> This change makes it possible to sweep out a range of lines in the diff view
> with the left mouse button, then right click and "Stage Lines For Commit".
>
> The selected lines may span multiple hunks.
Superb! Will test.
-- Hannes
^ permalink raw reply
* [PATCH] Documentation/git-gc.txt: change "references" to "reference"
From: Matt Kraai @ 2009-10-20 5:22 UTC (permalink / raw)
To: git, gitster; +Cc: Matt Kraai
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
Documentation/git-gc.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 1f6df6a..4cd9cdf 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -120,7 +120,7 @@ Notes
particular, it will keep not only objects referenced by your current set
of branches and tags, but also objects referenced by the index, remote
tracking branches, refs saved by 'git-filter-branch' in
-refs/original/, or reflogs (which may references commits in branches
+refs/original/, or reflogs (which may reference commits in branches
that were later amended or rewound).
If you are expecting some objects to be collected and they aren't, check
--
1.6.5
^ permalink raw reply related
* Extra checks for PERL_PATH and SHELL_PATH?
From: Matt Kraai @ 2009-10-20 3:50 UTC (permalink / raw)
To: git
Hi,
The top-level Makefile currently contains
> ifndef SHELL_PATH
> SHELL_PATH = /bin/sh
> endif
> ifndef PERL_PATH
> PERL_PATH = /usr/bin/perl
> endif
The checks are only necessary if these variables need to be overridden
by environment variables, not just via the make command line. Is this
the case?
--
Matt Kraai http://ftbfs.org/
^ permalink raw reply
* [PATCH] blame: make sure that the last line ends in an LF
From: Sverre Rabbelier @ 2009-10-20 3:06 UTC (permalink / raw)
To: Git List, Junio C Hamano; +Cc: Johannes Schindelin, Sverre Rabbelier
From: Johannes Schindelin <johannes.schindelin@gmx.de>
This is convenient when parsing multiple the blame of multiple files,
for example:
git ls-files -z --exclude-standard -- "*.[ch]" |
xargs --null -n 1 git blame -p > output
and then analyzing the 'output' file using a seperate script.
Currently the parsing is difficult when not all files have a newline
at EOF, this patch ensures that even such files have a newline at the
end of the blame output.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
CC: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Patch by Dscho, commit message by me. Apologies to Dscho for
taking so long to send it :).
builtin-blame.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 7512773..dd16b22 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1604,6 +1604,9 @@ static void emit_porcelain(struct scoreboard *sb, struct blame_entry *ent)
} while (ch != '\n' &&
cp < sb->final_buf + sb->final_buf_size);
}
+
+ if (sb->final_buf_size && cp[-1] != '\n')
+ putchar('\n');
}
static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
@@ -1667,6 +1670,9 @@ static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
} while (ch != '\n' &&
cp < sb->final_buf + sb->final_buf_size);
}
+
+ if (sb->final_buf_size && cp[-1] != '\n')
+ putchar('\n');
}
static void output(struct scoreboard *sb, int option)
--
1.6.5.1.123.ge01f7
^ permalink raw reply related
* Re: git-svn: add support for merges during 'git svn fetch'
From: Sam Vilain @ 2009-10-20 2:46 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1256006523-5493-1-git-send-email-sam.vilain@catalyst.net.nz>
Sorry Eric forgot to pass --cc to send-email, I finally got around to
this ;-)
Sam.
Sam Vilain wrote:
> This series adds support for converting SVN merges - in the two
> popular formats, SVK and SVN 1.5+, into git parents.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] am: allow some defaults to be specified via git-config
From: Sam Vilain @ 2009-10-20 2:44 UTC (permalink / raw)
To: Wesley J. Landaker; +Cc: git, Nigel McNie
In-Reply-To: <200910191149.13698.wjl@icecavern.net>
Wesley J. Landaker wrote:
> On Thursday 15 October 2009 17:50:27 Sam Vilain wrote:
>> +am.*::
>> + Specify defaults for linkgit:git-am[1]. Currently, the three
>> + boolean options, 'sign', 'utf8' and 'keep' may be specified.
>> +
>
> The 'git am' option is 'signoff', not 'sign'. Shouldn't the command option
> and config option names match?
Thanks for pointing that out. Yes, it should be.
--
Sam Vilain, Perl Hacker, Catalyst IT (NZ) Ltd.
phone: +64 4 499 2267 PGP ID: 0x66B25843
^ 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