* Git rebase using "wrong" commit
From: Philip Allison @ 2009-10-20 11:26 UTC (permalink / raw)
To: git; +Cc: Thomas Adam, Philip Allison
[-- Attachment #1.1: Type: text/plain, Size: 3511 bytes --]
Hello all,
We have a specific branch (integration/bug-fixes) which is under
continual rebase, shared amongst several developers. The tracked
instances have "branch.integration/bug-fixes.rebase true" and
"branch.integration/bug-fixes.mergeoptions --no-ff" - this is working
well. Individual developers merge their topic branches (in this case
bug fixes) into integration/bug-fixes and push it out.
Occasionally, we want to release some bug fixes, but not others. IOW,
when integration/bug-fixes comes to be rebased onto master, we wish to
preserve some of the topic branch merges, but not others. This usually
works fine, but an issue has cropped up where there is a conflict
between two fixes, and only one of the two bug fixes has been released;
now, when we come to perform the rebase, it is not working as desired.
Output of "git log --first-parent master..integration/bug-fixes":
-----
commit 9f79ca3928d645435d1608e22297dacd2be94e3b
Merge: 2bc19f9 cd8273f
Author: Philip Allison <philip.allison@smoothwall.net>
Date: Tue Oct 20 10:11:06 2009 +0100
Merge branch 'bug/2' into integration/bug-fixes
* bug/2:
Unify format of files 1, 2 and 3
Conflicts:
file1
commit 2bc19f9af94e03e06fbe5a1034820c606d13c3d3
Merge: c785da2 b17a93c
Author: Philip Allison <philip.allison@smoothwall.net>
Date: Tue Oct 20 10:07:37 2009 +0100
Merge branch 'bug/1' into integration/bug-fixes
* bug/1:
Fix file 1
-----
bug/2 has, effectively, been merged into master; bug/1 has not; hence,
there is not (on master) any equivalent change to that which was made to
resolve the conflict.
"git rebase -i master" output (whilst on HEAD of integration/bug-fixes):
-----
pick b17a93c Fix file 1
# Rebase cd8273f..9f79ca3 onto cd8273f
-----
The trouble here is that b17a93c is the head of bug/1 - the rebase has
picked up the changes from that branch and is trying to apply them as a
fast-forward commit in the newly rebased integration/bug-fixes, instead
of trying to rebase the *merge* of bug/1 (i.e. 2bc19f9).
The "-m" and "-p" options to rebase don't seem to be helping. I have
tried getting rebase to "pick 2bc19f9" via -i, but that isn't working
either:
-----
fatal: Commit 2bc19f9af94e03e06fbe5a1034820c606d13c3d3 is a merge but no
-m option was given.
Could not apply 2bc19f9...
-----
Interestingly, rebase does *not* seem to be trying to recreate 9f79ca3
(or its second parent), which is the problem I was originally expecting
to run into.
At the moment I don't know where to go from here, short of manually
recreating the branch as I want it, which I am loathe to do. Ideas and
suggestions much appreciated.
Please find attached a working copy of the repository, just before any
attempted rebase.
Regards
--
Philip Allison
Senior Developer
SmoothWall Ltd
1 John Charles Way
Leeds LS12 6QA
United Kingdom
1 800 959 3760 (USA, Canada and North America)
0870 1 999 500 (United Kingdom)
+44 870 1 999 500 (All other countries)
SmoothWall is registered in England: 4298247
This email and any attachments transmitted with it are confidential
to the intended recipient(s) and may not be communicated to any
other person or published by any means without the permission of
SmoothWall Limited. Any opinions stated in this message are solely
those of the author. See: http://smoothwall.net/company/email.php
for the full text of this notice.
[-- Attachment #1.2: repo.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 15095 bytes --]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: ".dirty" suffix when building git from the source code
From: Santi Béjar @ 2009-10-20 12:06 UTC (permalink / raw)
To: bamakhrama; +Cc: Git
In-Reply-To: <40378e40910200459i14b06002k1b805936e39b5022@mail.gmail.com>
On Tue, Oct 20, 2009 at 1:59 PM, Mohamed Bamakhrama
<bamakhrama@gmail.com> wrote:
> Hi all,
>
> I have cloned the git repository and built the v1.6.4.4 tag. The
> compilation went OK and I got the tool up and running. However, when I
> generate patches, I see that the tool comments the patches with
> "1.6.4.4.dirty".
>
> My question is: what is the meaning of the ".dirty" suffix?
It says that the git source code was modified when git was compiled.
HTH,
Santi
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Matthieu Moy @ 2009-10-20 11:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Alex Riesen, Junio C Hamano, Johannes Sixt, Sergio Callegari, git
In-Reply-To: <alpine.DEB.1.00.0910201221250.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 20 Oct 2009, Alex Riesen wrote:
>
>> On Tue, Oct 20, 2009 at 08:45, Junio C Hamano <gitster@pobox.com> wrote:
>> > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> >>> 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
>>
>> --no-full works
>
> It works. Technically. For human users, though, --loose-objects-only
> (with a shortcut "--loose") would be better.
OTOH, the advantage of "--no-full" is that it's compatible with
existing Git versions. If I learn Git 1.6.6 with --no-full, and use it
in a script, then my stript works also with older Gits.
But anyway, I think very few people are actually interested in "git
--no-full" (or call it whatever you like), so I don't think this is
very important.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* ".dirty" suffix when building git from the source code
From: Mohamed Bamakhrama @ 2009-10-20 11:59 UTC (permalink / raw)
To: Git
Hi all,
I have cloned the git repository and built the v1.6.4.4 tag. The
compilation went OK and I got the tool up and running. However, when I
generate patches, I see that the tool comments the patches with
"1.6.4.4.dirty".
My question is: what is the meaning of the ".dirty" suffix?
Thanks in advance.
Best Regards,
Mohamed
^ permalink raw reply
* Re: Potentially dangerous behavior of git gc
From: Sergio @ 2009-10-20 11:40 UTC (permalink / raw)
To: git
In-Reply-To: <20091019112153.GX6115@genesis.frugalware.org>
Miklos Vajna <vmiklos <at> frugalware.org> writes:
>
> On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari
<sergio.callegari <at> gmail.com> wrote:
> > With this when the alternate info of A is finally updated, A is broken,
missing
> > many references and not having a head anymore.
> >
> > Would it be better to have git gc not to take dangerous actions on
potentially
> > problematic repos?
>
> Such repos are usually created using git clone -s. See the NOTE of the
> manpage under the -s option, probably you want to use git repack -a
> after git clone.
>
Thanks, unfortunately, that was not really my point. But I now see that I
cannot create a test case to reproduce my issue. Briefly what happened to
me is the following
1) Create repo A
2) Clone with -s A into B
3) Do some work in B, being happy of maintaining the alternate
4) At some point, move A elsewhere
5) Do a couple of things in B, including a git gc, before realizing that
moving A had created problems to B
6) Rush to make A reachable by B again by updating the info/alternates
file in B
7) Realize that in spite of 6) B is gone... no more ref/heads/master, git
thinks that this is a new empty repo.
And certainly the fault was of some of the "two things" done in 5). At the
beginning I thought that the blame was of git gc, but I see that I cannot
reproduce the situation at all with test cases.
So I will give up for now... I'll get back to it if I ever have a similar
problem. Once more, sorry for the noise.
Sergio
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Sitaram Chamarty @ 2009-10-20 11:24 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190943x51d48c09sdc50d941d643358d@mail.gmail.com>
On Mon, Oct 19, 2009 at 10:13 PM, Mohit Aron <mohit.aron@gmail.com> wrote:
>>
>> That was the main reason I wrote gitolite
>> (http://github.com/sitaramc/gitolite), though now it does a heck of a
>> lot more than just that.
>>
>
> That's great. You might want to consider making it a deb package
> that's available from one of the Ubuntu/Debian repositories. An apt
> search on Ubuntu 9.10 doesn't reveal it. I usually shy away from
> installing software on my machines that is not automatically managed.
There are a couple of answers to this:
(1) I'm not really a debian guy, and definitely not ubuntu. My distro
of choice for nearly 10 years has been Mandriva :-)
(2) gitolite's second reason for existence [after the one in this
thread] is the need to install something on machines where you do
*not* have root, can't create another user, etc etc. There was a
Solaris 9 on which I couldn't install python-setuptools, and so no
gitosis :-(
Regardless of all that, someone is working on it...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550817
I respect your inclination to shy away; I do the same for pretty much
everything except git itself and one or two others.
But if you don't mind looking through the documentation (browse it
directly on github; it'll render the markdown properly, though the
plain text is quite readable too), you may be able to better decide if
you want to use it despite this limitation.
Regards,
Sita
^ permalink raw reply
* [PATCH] import-tars: Add support for tarballs compressed with lzma, xz
From: Ingmar Vanhassel @ 2009-10-20 10:29 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Shawn O. Pearce, Peter Krefting,
Junio C Hamano, Ingmar Vanhassel
In-Reply-To: <alpine.DEB.1.00.0910201155260.4985@pacific.mpi-cbg.de>
Also handle the extensions .tlz and .txz, aliases for .tar.lzma and
.tar.xz respectively.
Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
---
contrib/fast-import/import-tars.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
> Nice! Maybe you want to mention in the commit message that it handles
> also .txz and .tlz, for convenience. (I was looking specifically for that
> support in the patch, fully prepared to suggest to add it...)
Right, thanks!
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: git fsck not identifying corrupted packs
From: Johannes Schindelin @ 2009-10-20 10:22 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Matthieu Moy, Johannes Sixt, Sergio Callegari,
git
In-Reply-To: <81b0412b0910200225g47220cc9wa2e82290a853c85d@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 698 bytes --]
Hi,
On Tue, 20 Oct 2009, Alex Riesen wrote:
> On Tue, Oct 20, 2009 at 08:45, Junio C Hamano <gitster@pobox.com> wrote:
> > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> >>> 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?
>
> --no-full works
It works. Technically. For human users, though, --loose-objects-only
(with a shortcut "--loose") would be better.
Disclaimer: this email was written by a bot and is valid without signature
^ permalink raw reply
* Re: [PATCH] import-tars: Add support for tarballs compressed with lzma, xz
From: Johannes Schindelin @ 2009-10-20 9:56 UTC (permalink / raw)
To: Ingmar Vanhassel; +Cc: git, Shawn O. Pearce, Peter Krefting, Junio C Hamano
In-Reply-To: <1256029177-22503-1-git-send-email-ingmar@exherbo.org>
Hi,
On Tue, 20 Oct 2009, Ingmar Vanhassel wrote:
> Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
Nice! Maybe you want to mention in the commit message that it handles
also .txz and .tlz, for convenience. (I was looking specifically for that
support in the patch, fully prepared to suggest to add it...)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Johannes Schindelin @ 2009-10-20 9:53 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Junio C Hamano, git, Marius Storm-Olsen, Johannes Sixt
In-Reply-To: <bdca99240910200156x48511478w9eaa2239eb8342b4@mail.gmail.com>
Hi,
On Tue, 20 Oct 2009, Sebastian Schuberth wrote:
> 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.
Apart from the fact that I do not have MSVC (and I don't want it, either),
there is another strong reason why I think Sebastian does not need ACKs or
SOBs on MSVC patches: he has plenty of experience as a maintainer of a
rather big (commercial) software that has to compile on Windows, MacOSX
and several Unix-type OSes (and it is known that Sebastian is a Windows
guy).
So I would trust Sebastian's patches (at least when it comes to MSVC)
without even reviewing them.
Ciao,
Dscho
^ permalink raw reply
* Re: Which dates 'git log --since= --after=' compare?
From: Daniel @ 2009-10-20 9:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091020083703.GA14740@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> 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
Thanks.
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Alex Riesen @ 2009-10-20 9:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Johannes Schindelin, Johannes Sixt,
Sergio Callegari, git
In-Reply-To: <7vfx9esgvt.fsf@alter.siamese.dyndns.org>
On Tue, Oct 20, 2009 at 08:45, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>> 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?
--no-full works
^ permalink raw reply
* [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
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