* Re: [PATCH v2] new --dirty option for git describe
From: Jean Privat @ 2009-10-20 14:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
In-Reply-To: <dffdbd190910200727r30e161ffka0b3cf764be26cd8@mail.gmail.com>
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -9,6 +9,7 @@ git-describe - Show the most recent tag that is
> reachable from a commit
%#$@!&&@ !!!
I followed instructions from Documentation/SubmittingPatches about
sending patches trought gmail imap, it did not seem to work.
I will resend with git-send-email (and try on something else that
git@vger.kernel.org)
Sorry for that.
-J
^ permalink raw reply
* Re: Documentation video for svn-git
From: Wesley J. Landaker @ 2009-10-20 14:20 UTC (permalink / raw)
To: jamesmikedupont@googlemail.com; +Cc: git
In-Reply-To: <ee9cc730910192330i6c593143w5f35a7a1f66810a1@mail.gmail.com>
On Tuesday 20 October 2009 00:30:49 jamesmikedupont@googlemail.com wrote:
> 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
I'm definite fan free software text-to-speech software. (I know espeak when
I hear it!). But I have to ask: besides being a cool technology demo, what
is the use case for this? How is this better/different than, for instance,
just using a screen-reader on-the-fly?
^ permalink raw reply
* Re: Git rebase using "wrong" commit
From: Thomas Rast @ 2009-10-20 13:21 UTC (permalink / raw)
To: Philip Allison; +Cc: git, Thomas Adam
In-Reply-To: <1256037982.7122.31.camel@gridbug.soton.smoothwall.net>
Philip Allison wrote:
> Please find attached a working copy of the repository, just before any
> attempted rebase.
[...]
> 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.
Ok, so I gather the (simplified) history looks like
*------A (master)
\\__ \
\ \ \
B--M1--M2 (topic)
where A and B conflict, so M2 is nontrivial. B is the *second* parent
to M1, which I originally thought would affect the 'rebase -p', but it
doesn't; see below. (You're talking about bug/2, but the repository
shows bug/2 == master, so there are only two branches involved.)
> 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.
The inherent difficulty with doing a rebase here is, what about the
merges? By definition, git-rebase needs to somehow "rebuild" the
commits, as defined by the changes they do, on the new base.
There are several ways how merges can be rebased, and you tried some:
* Not at all; discard the merges. The result would be
*---A (master)
\
\
B' (topic)
B' will differ substantially from B because there will be a (rebase)
conflict. This is the normal mode of operation, as you noticed:
> "git rebase -i master" output (whilst on HEAD of integration/bug-fixes):
>
> -----
> pick b17a93c Fix file 1
>
> # Rebase cd8273f..9f79ca3 onto cd8273f
> -----
* Attempt to rebuild merges; this is the -p flag. Assume for a second
that you have a different history
*---A (master)
\
\
C---M2 (topic2)
/
*
where M2 is a merge with some other branch. 'git rebase -i -p
master topic2' will attempt to build
*---A (master)
\
\
C---M2 (topic2)
/
*
Going back to your scenario, this means building
*------A--. (master)
\ \ \
\ \ \
B-----M1--M2 (topic)
Now there appears to be some bug with rebase -p, because it insists
that there is no work at all to do (the buffer is just 'noop').
However, rebase -p is known to be somewhat ill-defined and broken.
I think that in this case, what actually happens is that the merge
from master to topic confuses the initialisation of $REWRITTEN in
# line 668
for c in $(git merge-base --all $HEAD $UPSTREAM)
do
echo $ONTO > "$REWRITTEN"/$c || die "blah"
done
because suddenly the merge-base is A, meaning that the later test
# line 712
for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)
do
if test -f "$REWRITTEN"/$p -a \( $p != $ONTO -o $sha1 = $first_after_upstream \)
fails for all commits except M2. So what's *actually* rewritten is
M2; but doing so is pointless in rebase's eyes, because it assumes
the topic will be based on master eventually, so merging master into
it is a no-op. Hence there is nothing to do.
> 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:
-m means something entirely different, namely that git-rebase should
use an (internal) merge instead of format-patch|am, which has some
advantages but a big speed disadvantage. This doesn't matter for
rebase -i as it never uses format-patch|am.
As for manually picking merge commits, that fails because you're just
trying to fool git-cherry-pick into doing something it can't.
> We have a specific branch (integration/bug-fixes) which is under
> continual rebase, shared amongst several developers.
[...]
> 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.
Note that there is no real reason to rebase continually unless you
want to kick out flawed topics or old versions of branches. For
example, git.git only rebases 'next' immediately after a release.
Furthermore, even if you go for the 'pu' model which is rebuilt all
the time, you can automate this with a script. There is one in the
'todo' branch of git.git, called PU.
(I myself just use a list of topics I want merged, and a simple 'git
merge $topic' loop.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] blame: make sure that the last line ends in an LF
From: Sverre Rabbelier @ 2009-10-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Johannes Schindelin
In-Reply-To: <7vbpk2sg6m.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Oct 20, 2009 at 02:00, Junio C Hamano <gitster@pobox.com> wrote:
> (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".
What about 'git blame -p', can we just go about changing the format like that?
For purpose of the discussion below let's assume we squash in the following:
-- <8 --
diff --git a/builtin-blame.c b/builtin-blame.c
index dd16b22..cf492a0 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1606,7 +1606,7 @@ static void emit_porcelain(struct scoreboard
*sb, struct blame_entry *ent)
}
if (sb->final_buf_size && cp[-1] != '\n')
- putchar('\n');
+ printf("\n\\ No newline at end of file\n");
}
static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
@@ -1672,7 +1672,7 @@ static void emit_other(struct scoreboard *sb,
struct blame_entry *ent, int opt)
}
if (sb->final_buf_size && cp[-1] != '\n')
- putchar('\n');
+ printf("\n\\ No newline at end of file\n");
}
static void output(struct scoreboard *sb, int option)
--
-- <8 --
> Does the code assign blame
> correctly around the last line of the original blob?
Yes, it does, when there is no trailing newline an extra "\ No newline
at end of file" is printed, but the last line is still attributed
correctly.
> What if an older
> version ended with an incomplete line and a later version changed the line
> (without adding the terminating LF)?
Nothing changes, the blame on that last line is attributed correctly
and the "\ No newline at end of file" is printed.
> What if a later version changed the
> line and added the terminating LF?
The trailing "\ No newline at end of file" is no longer printed and
the last line is correctly attributed to the commit that added the
trailing LF.
> What if a later version only added the
> terminating LF and did nothing else? Are these three cases handled
> correctly?
Same as above.
> After thinking issues like the above, I read the patch and I see it does
> not take neither approach. That makes me feel nervous.
Reading your reply I see that if you care about the presence (or
absence) of a trailing newline the current patch would be problematic,
as it makes it impossible to see in the blame output whether there was
a trailing newline or not.
> 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?
No, I think your concerns are valid, we should go with (2) and DTRT.
Does the updated patch address your concerns? If so I can send a new
version.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply related
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Erik Faye-Lund @ 2009-10-20 12:44 UTC (permalink / raw)
To: Ludvig Strigeus; +Cc: git
In-Reply-To: <loom.20091020T141138-782@post.gmane.org>
On Tue, Oct 20, 2009 at 2:20 PM, Ludvig Strigeus <ludde@spotify.com> wrote:
> unsigned long (as used by _byteswap_ulong) is 64 bits on x64, right? Then it
> doesn't make sense to use _byteswap_ulong to swap 32-bit quantities (assuming
> that's what bswap32 does) would it?
No, unsigned long is 32bit on x64 on Windows.
--->8---
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
printf("sizeof(void *) = %d\n", sizeof(void *));
printf("sizeof(unsigned long) = %d\n", sizeof(unsigned long));
return 0;
}
--->8---
sizeof(void *) = 8
sizeof(unsigned long) = 4
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Ludvig Strigeus @ 2009-10-20 12:20 UTC (permalink / raw)
To: git
In-Reply-To: <hbi4mt$tjt$1@ger.gmane.org>
Sebastian Schuberth <sschuberth <at> 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.
>
>
> +#elif defined(_MSC_VER) && (defined(_M_IX86) || defined(_M_X64))
> +
> +#include <stdlib.h>
> +
> +#define bswap32(x) _byteswap_ulong(x)
> +
> +#endif
unsigned long (as used by _byteswap_ulong) is 64 bits on x64, right? Then it
doesn't make sense to use _byteswap_ulong to swap 32-bit quantities (assuming
that's what bswap32 does) would it?
/Ludde
^ permalink raw reply
* 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
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